[Ffmpeg-devel] Interlaced decoding internals?

[Baptiste Coudurier]

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.


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