[Ffmpeg-devel] Interlaced decoding internals?

[Baptiste Coudurier]

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.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjpeg_bottom_field.patch
Type: text/x-diff
Size: 3129 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070206/e424d46e/attachment.patch>