Path: ...!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Alf92 <alf921@gmail.com>
Newsgroups: fr.comp.os.linux.configuration
Subject: Re: ffmpeg UHD vers HD
Date: Wed, 17 May 2023 00:30:56 +0200
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <u41072$3k1so$1@dont-email.me>
References: <u3tvkk$34l5$1@news> <u3v469$3ggl$1@news> <6463b4be$0$31526$426a34cc@news.free.fr> <u40k2t$42jm$1@news> <6463d9b0$0$3066$426a34cc@news.free.fr> <u40vd4$53sj$1@news>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 16 May 2023 22:30:58 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="df297b044ec42ee2d002a741f62ae83b";
	logging-data="3803032"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QjXipDdoXDsFLuKsm1gDq"
Cancel-Lock: sha1:qypwhmUQ2lyiiDrg6vd9pTl8kjg=
X-Newsreader: MesNews/1.08.06.00
Bytes: 2545

Christophe PEREZ (le 17/05/2023 à 00:17:08) :
> Le 16 May 2023 19:29:52 GMT, Nicolas George a écrit :

>> x265 est plus récent, donc plus puissant mais au prix de plus de besoins
>> de calculs.
>
> Oui, j'ai bien compris ça.
>
>> Attention, l'échelle de CRF n'est pas la même pour x264 et x265.
>
> Je m'en suis rendu compte après.
>
>> Accessoirement, le CRF est local, indépendant de la résolution, donc on
>> a intérêt à choisir une valeur plus élevée quand la résolution est plus
>> grande.
>
> Là, ça me dépasse...
>
>>> ce qui démontre au moins que diviser la résolution par 4 en passant de
>>> 3840x1600 à 1920x800 n'affecte que peu la taille du fichier, et j'avoue
>>> que je ne m'y attendais pas.
>> 
>> C'est en fait assez logique, puisque tu ne vois pas les différences de
>> quelques pixels. Tu verrais une différence si tu descendais le CRF
>> jusqu'à discerner des détails à l'échelle du pixel.
>
> Ok, merci.
> Et tu serais en mesure de me conseiller un CRF à utiliser dans mon cas ? 
> autour de 23 ? plus ? En fait, la question se résume à : à quel niveau je 
> pourrais voir une différence ?

très difficile de voir une différence entre deux valeurs proches.
le mieux -comme déjà dit- c'est de fixer un bitrate raisonnable et non
se baser un indice ou coef de qualité, et voir si ça te convient.
je t'ai donné les valeurs (et la ligne de commande ffmpeg).

si tu veux faire des tests sur un bout de video, tu peux le faire avec
ffmpeg en incuant des paramètres de bornage de temps dans la LdC.