[MEncoder-users] Backup policies

[James Hastings-Trew]

infernix wrote:
> This is what I thought first, but 
> http://forum.doom9.org/showthread.php?p=996195#post996195 and countless 
> CRF18 x264 encodes later, I'm only using 2pass if i need to squeeze 
> something in a specific filesize :) 
>   
Maybe I don't have all the facts and I am sure someone here will correct 
me if I am wrong, but whoever is making the claim in that thread that a 
2nd pass doesn't need to look any further ahead than 20 frames doesn't 
understand how the bits are allocated on the second pass. If I have a 
piece of video and the first half consists of a low motion scene of 
people talking to each other over a table in a kitchen, and the other 
half consists of people chasing around in a forest, and these two scenes 
are more than 20 frames apart from each other, how in the world is a 20 
frame lookahead going to know that the bits need to be spent mostly in 
the second half, and not so much in the first half? Constant bitrate 
will end up with bits being wasted in the low motion scene, or not 
enough bits going into the high motion scene. Constant quality has it's 
own set of problems - you cannot predict the size of the file you are 
creating, which DOES become a problem for devices using certain file 
systems (FAT 16, FAT 32, etc).

If your answer for 2 pass encoding is constant quality factor, you run 
into another problem -- bitrate control. There are a lot of devices that 
are rate limited, and when encoding for them you cannot exceed the 
maximum rate they can pull data from storage, decode it and display it. 
(Neuros OSD, Mvix, Apple TV, PSP, iPod, Zune, etc). So, you need some 
kind of rate control other than quality factor, and the only real way of 
achieving this is with two pass encode - pass one, find out where the 
bits need to be spent, pass 2 - encode the video.