[FFmpeg-devel] MPEG decoding on the iPhone is buggy

[Yoni Levy]

Disclaimer: I've posted a mail regarding this issue to ffmpeg-user a few
hours ago (
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2009-September/022179.html)
The reasons I'm re-posting here are: 1) I got a lot more specific with the
problem and 2) Given (1), I've been told this listing is more appropriate.

I've written a mock-up iPhone application that uses the latest ffmpeg (SVN
version) in conjunction with ffmpeg4iphone patches to play video from a file
on the iPhone device.
When I play an MPEG encoded file, the results I get look something like
this:

http://img2.imageshack.us/img2/3325/frame477.png
http://img8.imageshack.us/img8/290/frame726.png
http://img2.imageshack.us/img2/7680/frame863.png

Dumping RGB values from the resulted RGB24 frame buffers, I notice the
following pattern (which caused the green/purple effect):

RGBRGBRGBRGBRGBRGBRGB
0X00X00X00X00X00X00X0..... (only green for a while) .... then
X0YX0YX0YX0YX0YX0YX0Y..... (no green for a while) ...
0X00X0.... etc.

This bug is only occuring when decoding MPEG videos (h264 and real media for
example, work fine) and someone suggested it is a result of ARM
optimizations (I believe these were applied by the ffmpeg4iphone patches but
I'm not sure). Anyhow, a bug has been reported to the ffmpeg4iphone project
regarding this a few months ago, but hasn't been resolved yet. The
discussion can be found here:
http://code.google.com/p/ffmpeg4iphone/issues/detail?id=9 (it starts off a
bit unrelated with talk about the move from img_convert to sws_scale).

To my understanding nobody is currently working on a fix for that, which is
a shame because ffmpeg4iphone is now only half a solution.
Can anyone here suggest a solution, or get me closer to the bug itself?

P.S I found a post<http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-February/007899.html>in
this listing describing this purple/green effect and its relation to
MPEG, which might relate to this subject:

> This is not the same as in mpeg*, where there is an additional factor
> arguing for smaller GOPs: DCT drift. The mpeg4 standard recommends no more
>
> than about 100 P-frames (actually they give a specific number, I don't
> know where they got it from), and mpeg2 recommends 12-18 frames, or 4-6
> P-frames. As long as you use the same implementation of DCT in both the
>
> encode and decoder, the length doesn't matter. But if they differ (and
> many mpeg2 codecs are pretty sloppy about this), then you get accumulated
> error. (For some reason, the most common symptom I've seen of this is
>
> horizontal green and purple stripes.)
>
> --Loren Merritt
>
>
Thanks in advance,
Yoni Levy