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

[Michael Niedermayer]

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:
>>>> Moved from FFmpeg-user:
>>>>
>>>> On 14/05/2011 18:46, Stefano Sabatini wrote:
>>>>> On date Saturday 2011-05-14 18:20:02 +0100, Mark Himsley encoded:
>>>>>> On 14/05/2011 10:26, Stefano Sabatini wrote:
>>>>>>> On date Thursday 2011-05-12 17:07:09 +0100, Mark Himsley encoded:
>>>>>>> [...]
>>>>>>>> Anyway...
>>>>>>>>
>>>>>>>> What I need is a way to flag rawvideo media when its used as an
>>>>>>>> input into ffmpeg. Anyone?
>>>>>>>
>>>>>>> Mark, did you try with -top?
>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>> Yes. Sorry, I should have said that -top was my first guess, but your
>>>>>> showinfo filter says the rawvideo file is flagged as progressive when I
>>>>>> have -top 1 in the input files settings.
>>>>>
>>>>> Yes, check ffmpeg.c:do_video_out, top_field_first is used for setting
>>>>> the field type *just before encoding*.
>>>>>
>>>>> I wonder what could be a better approach, maybe we could implement a
>>>>> setprops filter for changing the properties of the video in the
>>>>> filterchain, and drop -top from ffmpeg.c.
>>>>>
>>>>> What do you think of this idea?
>>>>
>>>> Your 'setprops' filter idea would work, but I feel it would be better to
>>>> be able to flag the input file correctly in the first place.
>>>>
>>>> Imagine having one input file and outputting it to multiple output files
>>>> (I'm thinking of an example where you are reading from an input pipe and
>>>> outputting to MPEG2 and DV at the same time). You'd have to include the
>>>> 'setprops' filter at the start of both output files filter chains. Where
>>>> as, if you could supply the -top command against a rawvideo input you'd
>>>> only need to supply the parameter once.
>>>>
>>>> I might just be rambling inanely, but in
>>>> libavcodec\rawdec.c:raw_decode(), interlaced_frame and top_field_first
>>>> are set in the AVFrame 'frame' (the second parameter to raw_decode())
>>>> variable by copying from the AVFrame contained in AVCodecContext.
>>>>
>>>> It looks like the only place
>>>> AVCodecContext->coded_frame->interlaced_frame and
>>>> AVCodecContext->coded_frame->top_field_first are currently set is in
>>>> libavdevice\v4l2.c:v4l2_read_packet().
>>>>
>>>> So perhaps it might be good to also set those parameters in
>>>> libavformat\rawvideocodec.c:rawvideo_read_packet().
>>>>
>>>> This, at least, flags rawvideo as tff:
>>>
>>>
>>>> diff --git a/libavformat/rawvideodec.c b/libavformat/rawvideodec.c
>>>> index 127119f..9bdf950 100644
>>>> --- a/libavformat/rawvideodec.c
>>>> +++ b/libavformat/rawvideodec.c
>>>> @@ -39,6 +39,12 @@ static int rawvideo_read_packet(AVFormatContext *s,
>>>> AVPacket *pkt)
>>>>      pkt->dts= pkt->pos / packet_size;
>>>>
>>>>      pkt->stream_index = 0;
>>>> +
>>>> +    if (s->streams[0]->codec->coded_frame) {
>>>> +        s->streams[0]->codec->coded_frame->interlaced_frame = 1;
>>>> +        s->streams[0]->codec->coded_frame->top_field_first = 1;
>>>> +    }
>>>> +
>>>>      if (ret < 0)
>>>>          return ret;
>>>>      return 0;
>>>
>>>> I do not yet understand is how to get the correct value from variable
>>>> top_field_first in ffmpeg.c into that section of code.
>>>> ffmpeg.c:opt_input_file() looks like a good place to start.
>>>>
>>>> Perhaps, if the input file format is rawvideo and top_field_first is not
>>>> -1 a field could be set and top_field_first set to -1.
>>>>
>>>
>>>> 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


>
>>> 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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- 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/1e13bfe7/attachment.asc>