[Ffmpeg-devel] Interlaced decoding internals?

[Michael Niedermayer]

Hi

On Wed, Feb 28, 2007 at 11:16:34AM +0100, Baptiste Coudurier wrote:
> Hi
> 
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Tue, Feb 27, 2007 at 11:45:08AM +0100, Baptiste Coudurier wrote:
> >> Hi
> >>
> >> Baptiste Coudurier wrote:
> >>> 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.
> >> Michael, did you have some time to check this issue ?
> > 
> > no sorry, far too much to do, this one is rather low priority, and i 
> > didnt see a clean solution for it :(
> 
> Ok, well it is a bit high priority for me, as it does not decode files
> correctly :/
> 
> What don't you like in extradata patch ?

well apply it

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/20070302/a2c32958/attachment.pgp>