[MEncoder-users] Tuning hqdn3d

[James Hastings-Trew]

Nicolas George wrote:
> Le nonidi 29 floréal, an CCXVII, James Hastings-Trew a écrit :
>   
>> If file size is of no concern, then why compress the video at all? Maximal 
>> quality will be acheived with a lossless codec such as ffvhuff. Your 
>>     
>
> You missed the "and no more" bit, and thus are burning an obvious straw man.
>
> You can complain about "unpredictable file size" all you want, you know as
> well as me that for a reasonably-sized movie (for example), x264 will
> achieve a very good visual quality with a file at about 1 Go or 2 Go,
> sometimes a little more, but it will never be huge, never 10 Go for example.
>
> Now, what do I want when I encode something. I want to be able to take my
> movies on holidays with me. Therefore, I want:
>
> 1. A good visual quality. Not lossless, but enough so that the artifacts do
>    not distract me when I watch it.
>
> 2. A good usage of my disk space. Which means the smallest file possible
>    under the quality condition.
>
>   
So, you want what anyone would reasonably want - decent quality at a 
decent size. So, you want to compress the video to save file space, but 
not so much as to hurt quality. Your proposed approach is to compress 
the video with a constant quality (CRF). You pick a CRF value that you 
hope will give you quality you can live with, while hoping that the file 
isn't too big (and yes, depending on resolution, the size can be well 
over 2Gb in size - most feature films encoded at 1280 x 720, for example 
can be well over 6Gb in size if you are going for quality). You can do 
that in one pass.

However, you have to know that this isn't optimal - you certainly will 
be spending bits you don't need to on scenes that don't need them, and 
not spending bits on scenes that do. The only way to have the bits 
distributed optimally, all other things being equal, is a 2-pass encode 
because the encoder needs knowledge of the whole movie to be able to 
make those decisions. In doing one pass with a high CRF - you are not 
getting the best quality file you could, for the smallest file size you 
can live with.

If you don't want a gigantic file, and you don't want to spend a lot of 
time on the encode, then a CRF encode is probably "good enough". If, on 
the other hand quality and file size really do matter, then you need to 
pick a bitrate that you can live with (file size, file system, and 
playback device bandwidth determine this), an encoder complexity you can 
live with (generally playback device CPU bandwidth determines this), and 
then do a two pass encode using those parameters. This will ensure that 
all the bits you can afford are spent on getting you the best possible 
quality.
> Target bitrate is definitely not the way to go: you can whine all you want
> that it is not possible to predict the size of a constant-quality encoding,
> but the reverse is also true: you can not predict the quality of a
> target-bitrate encoding either. That makes 1-1, ball to the center.
>   
Not really. The encoder is not going to spend bits it doesn't need to. I 
can ask for a bitrate of 12000 but if the movie only needs 6000 to get 
the job done with the encoder features I've requested, then that's all 
that is going to get used. And a two pass encode ensures that exactly 
only the bits I need to spend for the quality I want are going to get 
used up. A 1 pass CRF is a fast compromise. It's great if you are in a 
hurry. Everything is a trade-off - surely you understand that you are 
trading speed for something - filesize or quality, or both, right? 
Nothing is free. You can have Quality, Speed, and Small File Size 
(Compression) - but you can only pick two.

>> experiment of a couple of days ago was unrealistic, and you know it. 
>>     
>
> What does it have unrealistic? It was done quickly on a single small sample
> with a single viewer, but the methodology was blameless. And at the very
> least, it proves that the claim that constant-bitrate would be better at
> half the bitrate was just laughable.
>
>   

>     I tried with some full-HD content: first x264 crf=1, then 2-pass x264
>     bitrate=42. Without any surprise, the first looked infinitely better.


Very realistic and reasonable (rolls eyes). Try the encodes with crf=18 
and then 2-pass with bitrate=6000. That would be a more even comparison.

> But you are right, that is not what the question is. The question is:
>
> 1. Constant-quality encoding at an arbitrary quality to get file A.
>
> 2. 2-pass target bitrate encoding to get file B with the same size as file A.
>
> -> Which is better, file A or file B?
>   
File B will be better. That's what we've unsuccessfully been trying to 
tell you.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4089 (20090519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com