After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 364139 - [ffdec_h264] regression: artefacts with 'climates' quicktime trailer
[ffdec_h264] regression: artefacts with 'climates' quicktime trailer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal blocker
: 0.10.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 479777 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-10-22 10:10 UTC by Filip Palm
Modified: 2007-09-24 12:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Shows the corruption on the Climates trailer. (96.65 KB, image/png)
2006-10-22 10:13 UTC, Filip Palm
  Details
patch for this bug (595 bytes, patch)
2007-01-26 17:31 UTC, Yves Lefebvre
committed Details | Review

Description Filip Palm 2006-10-22 10:10:42 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.
Comment 1 Filip Palm 2006-10-22 10:13:13 UTC
Created attachment 75186 [details]
Shows the corruption on the Climates trailer.
Comment 2 Tim-Philipp Müller 2006-10-23 11:55:57 UTC
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.

Comment 3 Wim Taymans 2006-10-26 08:40:32 UTC
I assume you meant width of 480, which is fine. xine des it wrong, vlc does it right.
Comment 4 Tim-Philipp Müller 2006-10-26 09:11:55 UTC
> I assume you meant width of 480, which is fine.

Indeed, I got confused, sorry for the noise.


Comment 5 Wim Taymans 2006-10-27 16:23:07 UTC
also, this is a regression from the latest release, where it works fine.
Comment 6 Tim-Philipp Müller 2006-12-11 12:49:04 UTC
Shouldn't this be a blocker? (if not, please change back)
Comment 7 Jan Schmidt 2006-12-11 14:25:46 UTC
Is the corruption still present? 

I don't have it here with the pre-release.
Comment 8 Filip Palm 2006-12-11 22:16:31 UTC
The corruption is still present on my setup. 

I just compiled latest Gstreamer stuff from CVS and it didn't help.
Comment 9 Jan Schmidt 2006-12-11 22:25:59 UTC
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.
Comment 10 Filip Palm 2007-01-01 16:31:56 UTC
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)
Comment 11 Tim-Philipp Müller 2007-01-01 18:13:24 UTC
Sadly, it's still there for me.
Comment 12 Yves Lefebvre 2007-01-26 17:31:36 UTC
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.
Comment 13 Wim Taymans 2007-04-12 10:56:43 UTC
        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...
Comment 14 Tim-Philipp Müller 2007-09-24 12:25:57 UTC
*** Bug 479777 has been marked as a duplicate of this bug. ***