[FFmpeg-devel] [RFC/PATCH]Interlaced lossless

Peter B. pb at das-werkstatt.com
Mon Jan 28 16:50:12 CET 2013

Quoting Tim Nicholson <nichot20 at yahoo.com>:

> On 26/01/13 12:05, Peter B. wrote:
>> Which commandline argument is used to tell lossless codecs like  
>> FFv1 or Huffyuv whether the material is to be considered  
>> progressive or interlaced - and where is it stored: in the  
>> container or the codec - or both?
> '-top' can be used as both an input an output option to set interlace
> flags. Some codecs embed this information in the stream. For others,
> e.g. rawvideo there is no place for it there so it has to be in the
> container. This is why the quicktime spec mandates providing this
> information in a moov atom.

I'll try using "-top". Thanks for the hint.
It is indeed a good question if, for example, FFv1 is storing  
interlaced flags in the stream or requires to codec to do so?

> For lossless codecs I'm not sure that the codec will work any
> differently between interlace and progressive, you just nee to ensure
> that the final output is flagged correctly.

The good thing about lossless is, that the bits will be preserved.  
However, I do suspect that, depending on the encoding algorithm,  
different compression ratios might be achieved if the material is  
encoded differently, depending on whether the source was interlaced or  

For example, usually codecs looove adjacent areas with similar colors,  
right? Even lossless ones (I hope I'm not talking bullshit here).
So, if the encoder encodes fields (for interlaced) rather than frames,  
there would be more similar-colored pixels adjacent to each other than  
if encoded progressively.
Same goes for progressive material: If encoded field-wise, you might  
lose compression possibly gained by adjacent similar-colored  

But that's just my personal knowhow of encoding. So if I'm completely  
wrong, please tell me so I can get a better understanding.

Thanks and regards,
Peter B.

More information about the ffmpeg-devel mailing list