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

[Michael Niedermayer]

On Mon, May 16, 2011 at 05:55:13PM +0100, Mark Himsley wrote:
> 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.

Ive implemented it locally, will push in a moment.
Please review my changes and comments welcome.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110516/e110df1d/attachment.asc>