[Ffmpeg-devel] Interlaced decoding internals?

[Baptiste Coudurier]

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 ?

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