[FFmpeg-devel] RFC: flag rawvideo input as interlaced
michaelni at gmx.at
Mon May 16 21:55:16 CEST 2011
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
> 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.
>>>>> 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'
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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel