[FFmpeg-devel] [PATCH] Enable PAFF decoding

[Michael Niedermayer]

Hi

On Thu, Oct 11, 2007 at 10:43:55AM +1000, Neil Brown wrote:
> On Wednesday October 10, heydowns at borg.com wrote:
> > On Wed, 10 Oct 2007, Neil Brown wrote:
> > [...]
> > > 3 issues:
> > > 
> > > 1/ The first few frames are in the wrong order.
> > > 
> > > The first 3 field-pairs in my files are:
> > >   I+P  (poc 0 and 1)
> > >   B+B  (poc -4 and -3)
> > >   B+B  (poc -2 and -1)
> > > 
> > > I'm getting the first pair out first, then the second decodes
> > > imperfectly.  I haven't figured out why yet.  The same thing doesn't
> > > happen when you cross an IDR frame, so there must be something
> > > "special" about the very start.
> > 
> > Do your files start with IDR?
> > 
> 
> Yes.
>  ./ffplay -debug 256 00002.mts 2> /tmp/trace
> 
> Yields
> 
> FFplay version SVN-r10700, Copyright (c) 2003-2007 Fabrice Bellard, et al.
>   configuration: --enable-gpl
>   libavutil version: 49.5.0
>   libavcodec version: 51.45.0
>   libavformat version: 51.14.0
>   built on Oct 10 2007 17:03:09, gcc: 4.2.1 (Debian 4.2.1-6)
> [h264 @ 0xa638a0]NAL 9 at 4/69 length 1
> [h264 @ 0xa638a0]NAL 7 at 10/69 length 50
> [h264 @ 0xa638a0]NAL 8 at 65/69 length 3
> [h264 @ 0xa638a0]NAL 9 at 4/126719 length 1
> [h264 @ 0xa638a0]NAL 7 at 10/126719 length 50
> [h264 @ 0xa638a0]NAL 8 at 65/126719 length 3
> [h264 @ 0xa638a0]NAL 6 at 73/126719 length 16
> [h264 @ 0xa638a0]NAL 6 at 94/126719 length 104
> [h264 @ 0xa638a0]NAL 6 at 210/126719 length 25
> [h264 @ 0xa638a0]NAL 6 at 240/126719 length 12
> [h264 @ 0xa638a0]NAL 6 at 258/126719 length 4
> [h264 @ 0xa638a0]NAL 5 at 267/126719 length 126451
> [h264 @ 0xa638a0]NAL 9 at 4/69 length 1
> [h264 @ 0xa638a0]NAL 7 at 10/69 length 50
> [h264 @ 0xa638a0]NAL 8 at 65/69 length 3
> [h264 @ 0xa638a0]NAL 9 at 4/71692 length 1
> [h264 @ 0xa638a0]NAL 8 at 10/71692 length 3
> [h264 @ 0xa638a0]NAL 6 at 18/71692 length 12
> [h264 @ 0xa638a0]NAL 1 at 36/71692 length 71655
> ....
> 
> The "NAL 5" is - I believe - the first field and is IDR.
> 
> I looked a bit more deeply, and seems that the first decoded frame is
> being output twice.  It is output as the first presented frame, and
> then again at the proper place in the presentation order (though now
> everything is offset by one frame).  Looking at the code in
> decode_frame, the first frame will always be output, which is clearly
> wrong.  But it's not clear to me how best to fix it.  Maybe this?

no, this is no fix, its a VERY ugly workaround, you dont even touch the
code which is causing the behavior you just detect one buggy case and set a
random correct variable to a incorrect value
so your patch make the code even more buggy ...
the bugs just no (partially?) cancel each other out


> 
> It still leaves the first (presented) frame badly decoded though.
> There is a "double-vision" effect, as though the second field is being
> decoded with reference to the first (decoded) frame instead of the
> first field in the same frame.... does that make sense?

no, the first (IDR) frame should be decoded correctly, the "next" B frames
are prior to IDR in display order and cannot and should not be displayed 

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071012/7e2bb19a/attachment.pgp>