GNOME Bugzilla – Bug 364139
[ffdec_h264] regression: artefacts with 'climates' quicktime trailer
Last modified: 2007-09-24 12:25:57 UTC
When watching trailers at www.apple.com/trailers i get corruption on the left side of the videos. Trailer example: http://images.apple.com/movies/independent/climates/climates_h480.mov Other information: Gstreamer-CVS, Gst-plugin-*-CVS and Gst-ffmpeg-CVS.
Created attachment 75186 [details] Shows the corruption on the Climates trailer.
Probably a gst-ffmpeg problem, possibly related to the 'uneven' width of 260 (which is not a multiple of 8 or 16). Moving there for now.
I assume you meant width of 480, which is fine. xine des it wrong, vlc does it right.
> I assume you meant width of 480, which is fine. Indeed, I got confused, sorry for the noise.
also, this is a regression from the latest release, where it works fine.
Shouldn't this be a blocker? (if not, please change back)
Is the corruption still present? I don't have it here with the pre-release.
The corruption is still present on my setup. I just compiled latest Gstreamer stuff from CVS and it didn't help.
Then I guess it's in the updated ffmpeg snapshot, which has seen a fair bit of h264 updates. Apparently there are further changes in current svn, but I'm not willing to update to a new snapshot and go through all that testing across all formats until after this release. If we can cook a patch to update just the h264 decoder to latest ffmpeg svn though, that'd work.
Made a clean new install of Edgy this weekend and installed all Gstreamer CVS stuff and this regression is gone now. Just wanted you to know that. Keep up the good work and happy new year. :o)
Sadly, it's still there for me.
Created attachment 81279 [details] [review] patch for this bug I found a possible fix. While debugging this I had a source that cause a green spot at frame #3 when using gst-ffmpeg. I didn't see this if I use ffmpeg from svn. I started to compare various things between the 2. It was not easy since, for example, uvlinesize was not even the same (gst-ffmpeg use 88 and ffmpeg was using 104 for the same input file). After a while, I found that there was a major difference in dest_cr at the end of function mc_dir_part (h264.c). There was some 0's that appear in gst-ffmpeg at the "edge" of the dest_cr buffer and not in ffmpeg. I was able to manually fix or create the problem by pasting good or bad value in the two apps. Now, the harder part : I finally found that src_cr got some 0's about 100 iteration earlier of mc_dir_part. Those are the cause of the dest_cr buffer corruption later on. What puzzle me at this point was that ffmpeg too had the same things in it's src_cr buffer. However, it's src_cr somehow got magically corrected a bit later. The reason and fix I found is not to use CODEC_FLAG_EMU_EDGE: drawing the edge (in mpegvideo.c:MPV_frame_end) seems to clean the 0's that appear in the src_cr buffer. This is what ffmpeg does by default. It seems to fix the issue on gst-ffmpeg with the test I performed. The only things that bugs me is the comment that was there in gstffmpegdec.c /* do *not* draw edges */ This seems to implied that drawing the edges is bad. My patch only does it for H264 decoding.
Patch by: Yves Lefebvre <ivanohe at abacom dot com> * ext/ffmpeg/gstffmpegdec.c: (gst_ffmpegdec_setcaps): Draw edges for h264. Fixes #364139. Set the error resilience flag just in case...
*** Bug 479777 has been marked as a duplicate of this bug. ***