[gstreamer-bugs] [Bug 364139] [ffdec_h264] regression: artefacts with 'climates' quicktime trailer
bugzilla-daemon at bugzilla.gnome.org
Fri Jan 26 09:33:21 PST 2007
Do not reply to this via email (we are currently unable to handle email
responses and they get discarded). You can add comments to this bug at
GStreamer | gst-ffmpeg | Ver: HEAD CVS
------- Comment #12 from Yves Lefebvre 2007-01-26 17:31 UTC -------
Created an attachment (id=81279)
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
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
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
More information about the Gstreamer-bugs