[Ffmpeg-devel] Interlaced decoding internals?

Baptiste Coudurier baptiste.coudurier
Fri Mar 2 13:29:03 CET 2007


Michael Niedermayer wrote:
> Hi
> 
> On Wed, Feb 28, 2007 at 11:16:34AM +0100, Baptiste Coudurier wrote:
>> Hi
>>
>> Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Tue, Feb 27, 2007 at 11:45:08AM +0100, Baptiste Coudurier wrote:
>>>> Hi
>>>>
>>>> Baptiste Coudurier wrote:
>>>>> Hi
>>>>>
>>>>> Michael Niedermayer wrote:
>>>>>> Hi
>>>>>>
>>>>>> On Sun, Feb 11, 2007 at 01:58:12PM +0100, Baptiste Coudurier wrote:
>>>>>>> Baptiste Coudurier wrote:
>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> On Tue, Feb 06, 2007 at 01:31:04PM +0100, Baptiste Coudurier wrote:
>>>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>>>> On Tue, Feb 06, 2007 at 11:08:20AM +0100, Baptiste Coudurier wrote:
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Feb 05, 2007 at 08:31:41PM +0200, Kostya wrote:
>>>>>>>>>>>>>> I'm working on adding interlaced frame support for VC-1 and
>>>>>>>>>>>>>> has some question regarding AVCodecContext internals:
>>>>>>>>>>>>>> What do avctx->interlaced_frame, avctx->top_field_first
>>>>>>>>>>>>>> and avctx->repeat_pict affect if set by decoder?
>>>>>>>>>>>>> they are not in AVCodecContext but AVFrame
>>>>>>>>>>>>> they affect display, top_field_first affects the order in which
>>>>>>>>>>>>> fields are shown, interlaced_frame affects if the frame is shown
>>>>>>>>>>>>> as frame or as 2 fields at 2 seperate times (assuming the player
>>>>>>>>>>>>> applictaion cares about the at all of course ...)
>>>>>>>>>>>> You'll laugh, what can I do if the interlaced info is in the container ?
>>>>>>>>>>>> I have some mjpeg a bottom field first, and info is in "fiel" atom.
>>>>>>>>>>>> I'll fix decoder, but I need a way to supply that info.
>>>>>>>>>>>> What do you prefer ? Adding a field to avctx ? 
>>>>>>>>>>> avctx is problematic as top-field-first can change between frames in
>>>>>>>>>>> MPEG so with decoder delay and multiple threads its the perfect recipe
>>>>>>>>>>> for troubble
>>>>>>>>>>> adding top-field-first to AVStream seems like the better solution,
>>>>>>>>>>> that way the demuxer can export it without interfering with the codec
>>>>>>>>>>> the same may (or may not ...) be a good idea for width/height, so
>>>>>>>>>>> the width and height for mpeg4/h263 in mov could be dealt with nicer
>>>>>>>>>>> maybe ...
>>>>>>>>>> So, then I need to set picture->top_field_first before passing it to the
>>>>>>>>>> decoder.
>>>>>>>>>>
>>>>>>>>>> Attached patch is working, but IMHO is ugly.
>>>>>>>>> yes this doesnt look good, i thought the container top field first was
>>>>>>>>> just for display if its needed for decoding then it must be passed through
>>>>>>>>> extradata that of course assumes that there is not enough information in
>>>>>>>>> the jpeg stream itself to decode it correctly (which i have some doubt about
>>>>>>>>> also we could choose simply not to support these jpegs)
>>>>>>>> I need to reread specs, AFAIK jpeg does not support interlacing,
>>>>>>>> mjpeg in mov/avi, specify total width/height in container, and field
>>>>>>>> height in bitstream.
>>>>>>>>
>>>>>>>> I would like to support them, bottom field is almost everytime used in NTSC.
>>>>>>>>
>>>>>>>>> also the changes to mjpeg.c contain cosmetics and ive a bad feeling about
>>>>>>>>> them (they arent breaking all interlaced non mov mjpeg or?)
>>>>>>>> Currently interlacing is detected by checking bitstream height against
>>>>>>>> height set before decoding (from container) and then assume interlaced
>>>>>>>> content and always use top field first (which is wrong IMHO)
>>>>>>>>
>>>>>>>> I'll use mov "fiel" atom then, buf if someone store bottom field first
>>>>>>>> in avi... who knows.
>>>>>>>>
>>>>>>> Ping ?
>>>>>> upload sample videos with top and botom field first 
>>>>>>
>>>>> here it is:
>>>>> mjpeg_top.mov, mjpeg_bottom.mov on mplayerhq.
>>>> Michael, did you have some time to check this issue ?
>>> no sorry, far too much to do, this one is rather low priority, and i 
>>> didnt see a clean solution for it :(
>> Ok, well it is a bit high priority for me, as it does not decode files
>> correctly :/
>>
>> What don't you like in extradata patch ?
> 
> well apply it

Thanks, done.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312




More information about the ffmpeg-devel mailing list