[Ffmpeg-devel] Interlaced decoding internals?

[Michael Niedermayer]

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)

also the changes to mjpeg.c contain cosmetics and ive a bad feeling about
them (they arent breaking all interlaced non mov mjpeg or?)


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070206/7bea75e6/attachment.pgp>