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

[Tim Nicholson]

On 26/01/13 12:05, Peter B. wrote:
> On 01/26/2013 05:49 AM, Carl Eugen Hoyos wrote:
>> Attached patch fixes ticket #2190 for me (if using mov which supports saving 
>> interlace information like yuv4mpeg).
>> It duplicates some code across decoders, this may indicate that it is not 
>> entirely correct - please advise!
> 

I'm slightly confused by this.
You seem to be using the wrapper interlace information contained in a
mov (avctx->field_order) to force the decoding of certain codecs that
have no embedded interlace information when they are wrapped in a mov.

However ticket #2190 seems to be to do with decoding raw yuv and putting
it into a mov wrapper. (i.e. going the other way)

When I am trying to do this, since the source material has no proper
interlace (or any other metadata) flagging I simply use:-

ffmpeg -top -pix_fmt uyvy422 -s 720x576 -i in_file.yuv -c:v copy -vtag
2vuy out.mov

(the -vtag is probably now redundant but worked around a regression)

Sorry if I have misunderstood, my brain seems to be working in first
gear today...


> This reminds me of a question I've been having on my mind for a long time.
> The code in your patch says:
> 
> /*we have interlaced material flagged in container */
> 
> 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.

> 
> (For lossy I've been using "-flags +ilme+ildct" [1], but according to FFmpeg's documentation, "ilme" is for MPEG-2/4 only [2] and "ildct" applies to DCT [3], which isn't used in e.g. FFv1 or Huffyuv)
> 

You need to tell the codec how you want it to handle the material., i.e
-flags +ilme+ildct for appropriate codecs, but you also need to make
sure the container flags are correct using -top.

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.

> @Michael:
> I also presume that the compression ratio is affected if e.g. interlaced is encoded progressively - and vice versa.
> Is there a way for me to compare this?
> 
> [..]
-- 
Tim