[FFmpeg-devel] RFC: flag rawvideo input as interlaced

[Mark Himsley]

On 16/05/11 15:22, Michael Niedermayer wrote:
> On Mon, May 16, 2011 at 11:45:15AM +0100, Mark Himsley wrote:
>> On 16/05/2011 00:10, Michael Niedermayer wrote:
>>> On Mon, May 16, 2011 at 12:08:24AM +0200, Stefano Sabatini wrote:
>>>> On date Sunday 2011-05-15 19:47:26 +0100, Mark Himsley encoded:
[...]
>>>>
>>>>> If that is a reasonable idea, AVFormatParameters would be the structure
>>>>> to extend.
>>>>
>>>> AVFormatParameters is deprecated and we should get rid of it.
>>
>> Without it, I don't see how ffmpeg.c can pass the width, height, pix_fmt
>> etc etc to raw decoders. There is even a comment that says that
>> AVFormatParameters is "Only used in raw format right now".
>
> there are many options that are passed to the decoders, like for
> example idct type.
>
> Please elaborate on where the problem is

The problem is my ignorance.

I want to flag a rawvideo input file as interlaced and of a specific 
field order.

I therefore think that the appropriate way to do that is to set the 
command line parameter "-top [0|1]" before an input file of format rawvideo.

Therefore I want to get the value of the variable top_field_first from 
ffmpeg.c into demuxer/decoder. As Stefano pointed out, value of 
top_field_first is not used anywhere except for in 
ffmpeg.c:do_video_out(), so putting it into AVFormatParameters to be 
passed to the demuxer/decoder seemed the logical thing to do.

>>>> Instead,
>>>> we could use demuxers/decoders private options when it makes
>>>> sense. I'm not yet sure where the option should be set (if in the
>>>> demuxer or in the decoder), Michael?
>>>
>>> I dont think theres a single perfect awnser here
>>>
>>> demuxer private options would make it only available for one demuxer
>>> there can be rawvideo in many containers.
>>
>> I have assumed that containers other than rawvideo can flag their
>> streams as interlaced already.
>
> i dont think many can do that currently.
>
>
> also a writing into coded_frame of a decoder from a demuxer is very
> hasckish. there could be no decoder at all or 2 decoders.
> These might be unlikely enough for it to work out in practice but
> its not a pretty way to solve it

Ok, I understand that. My excuse is that I was just following how 
libavformat/yuv4mpeg.c:yuv4_read_header() and 
libavdevice/v4l2.c:v4l2_read_header() both do it.

As I said, my ignorance is preventing me from seeing a less 'hackish' 
solution.

-- 
Mark