[Ffmpeg-devel] Interlaced decoding internals?

[Michael Niedermayer]

Hi

On Tue, Feb 06, 2007 at 02:19:09PM +0100, Reimar Doeffinger wrote:
> Hello,
> 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:
> > >> Michael Niedermayer wrote:
> > >>> 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.
> 
> Maybe this would be a good point to suggest again a flags option for the
> decode function, both TOP_FIELD_FIRST, PALETTE and other indications
> could be put there.
> Though I admit it will probably lead to some entanglement between lavf
> and lavc if not done carefully...

iam glad we agree here, this is very sensitive stuff and its very easy to
create a huge mess, the very first step is to understand what really is
needed then we must think of how to do that in a way which allows
all the currently working use cases like remuxing without decoder and
remuxing between the same container and different containers ...

for the palette case it seems like a palette flag in AVPacket will be
needed and AVPacket will have to be passed as argument to avcodec_decode_video

for TOP_FIELD_FIRST it seems the situation is not fully understood,
i doubt that the flag is needed for decoding mjpeg at all


> Or even if that is not a good solution, there should be at least some
> way to pass special data/options to a decoder.

there is extradata and the packets themselfs any other general flag
passing will completely break remuxing between formats which have a
unequal set of such flags

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/f637a538/attachment.pgp>