[FFmpeg-devel] Bugreport: PAFF crashes ffplay, more info than older report, appendix

[Michael Niedermayer]

Hi

On Thu, May 03, 2007 at 01:31:10PM -0600, Loren Merritt wrote:
> On Thu, 3 May 2007, Michael Niedermayer wrote:
> > On Thu, May 03, 2007 at 03:05:46PM +0200, Thorsten Jordan wrote:
> >>
> >> With h264 decoding PAFF material the decoder recognizes bottom fields
> >> (h264.c, line 4665) and this leads to an increase of the buffer pointer
> >> by wrap (mpegvideo.c, line 1620). This leads to a line-off-by-one error
> >> in draw_edges_mmx or draw_edges_c. This leads either to heap corruption
> >> or to a segfault when running ffmpeg with memory checkers like efence or
> >> DUMA.
> >>
> >> I do not know if draw_edges is valid for bottom fields or what goes
> >> wrong here and further research seems much more time demanding. I hope
> >> this info helps you for fixing this.
> >
> > well i dont know the rules for h.264 field pictures and out of picture
> > sample repeation (i would have to check the h.264 spec) but i guess
> > that they almost certainly will repeat even and odd independant of each
> > other, that is draw_edges of each field seperately
> > if true images will have to be allocated to be large enough for the amount
> > of repeation done (repeating less is possible too)
> 
> draw_edges is simply incompatible with h.264 interlacing. The repetition 
> algorithm is determined by whether the frame or block being predicted 
> is interlaced, not by whether the reference frame is interlaced. Thus the 
> same reference frame can be accessed both ways, and no matter what 
> draw_edges does it will be wrong. My implementation of mbaff always uses 
> emu_edge for the top and bottom edges.

then the vertical part of draw edeges can be skiped for MBAFF/PAFF h.264
which would safe a tiny amount of cpu time too ...

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20070503/434a8928/attachment.pgp>