GNOME Bugzilla – Bug 694230
quicktime videos have decoding issues in gst-1.x
Last modified: 2013-02-25 10:47:20 UTC
The amount of degradation can range from occasional/slight to almost continuous. This is seen both online thru browser plugin & with same vid's played locally with all gstreamer players like Videos(totem), banshee, ect. Also the same is seen thru gst-launch on local files. 2 example url's, first is slight, starts around 25 sec's in. 2nd is pretty much as soon as the vid starts. http://www.nasa.gov/multimedia/hd/HDGalleryCollection_archive_1.html (the Arthur Christmas vid http://trailers.apple.com/trailers/marvel/ironman3/ (trailer1 For your convenience will attach cut clips from above links for local use/checking
I guess I can't attach... If need be placed 2 here http://ubuntuone.com/4bd7JPSNiLurTHThxdVCQa http://ubuntuone.com/4kcbiBduEkgcljjTQC6xd8 You should be able to wget them, the 1st is Arthur ( left as a.mov), the 2nd is Ironman3, had to put in a .mp4 container or totem would reject. Otherwise identical to orig. If unavailable for some reason & desired I'll put up on launchpad in a bug report
What exact versions of GStreamer and plugins are you using, and what for decoders? Could you also describe the issues little - is it the audio or the video or both? Both clips play fine for me (tested with latest releases as packaged on debian sid, playing back from local file). 308ec9e193872741502698aaab1304ba 694230-NASA_Arthur_Christmas.mov 287ee9f65e14f7d22ea3250891f51d7f 694230-ironman3-tlr1-m4mb0_h1080p.mov 979c569537c5a94cc09b5b4539e7f29d 694230-ironman3-tlr1-m4mb0_h480p.mov
using gstreamer1.0 (1.0.5-1ubuntu1) on 13.04 but same is seen with all 1.x versions starting with gstreamer1.0 (1.0.0-1) & can be seen in quantal 12.10 using the gnome3 ppa packages. The audio is fine, have also tried with the gst pulseaudio plugin removed. Seen by quite a number of 12.10 (ppa) & 13.04 users. As mentioned some vids are ok, some with intermittent, some completely Hard to describe so did some captures of Videos playing the 2 sample files, didn't include the audio in the captures http://ubuntuone.com/4aQ9oHxDji6Zh9aV4dPImI http://ubuntuone.com/1lZLGjWIhR50q4aU3HIlHt Noting that all is fine if I use Videos 3.4.3 & gst-0.10.x in both 12.10 & 13.04
Could you attach the output of: $ gst-launch-1.0 -v playbin uri=file:///path/to/ironmantrailer.mov | tee gst-launch.log ? Could you also provide the output of: $ dpkg -l '*gst*1.0*' ?
I'm testing with 1.0.5 versions of all packages as in debian sid btw. I noticed that the gnome3 ppa only has gst-plugins-bad 1.0.2 (?), which means it is missing some h264 codec parser fixes (I don't know if those matter for this or not, but it's possible).
Created attachment 236996 [details] requested log
Created attachment 236997 [details] requested dpkg info
Could you check if installing gstreamer1.0-plugins-bad fixes it? In particular the h264parse element should be installed and gst-inspect-1.0 h264parse should show some output.
(Though the h264parse element should not be needed for mp4 files, just trying to figure out what's missing or different from your setup to other peoples', because this works just fine in general afaik.)
I'd removed the bad plugin just prior to filing this bug to see if h264parse was somehow involved, so no, having it installed doesn't make any difference. (This weekend I'll try on different hardware & maybe a different distro or 2 to see how they fare.
I think I found the cause. It's an issue with the mult-threaded h264 decoding in libav. This shows the issue for me in the 1.0 branch (using the internal libav 0.8.5 snapshot of gst-libav): gst-launch-1.0 filesrc location=ironman3-tlr1-m4mb0_h1080p.mov ! qtdemux ! avdec_h264 max-threads=2 ! xvimagesink This does not: gst-launch-1.0 filesrc location=ironman3-tlr1-m4mb0_h1080p.mov ! qtdemux ! avdec_h264 max-threads=1 ! xvimagesink I suspect the libavcodec my gstreamer1.0-libav is using doesn't have this issue (or it has been disabled there). Can you confirm that the second pipeline fixes the issue for you too?
Excellent - the ^ gst command plays the vid back without issue
A few things to note- may not matter On same install (13.04/raring), gst-launch-0.10 filesrc location='/home/doug/ironman3-tlr1-m4mb0_h720p.mov' ! qtdemux ! ffdec_h264 max-threads=2 ! xvimagesink or max-threads=0 (auto), works fine with all vids. If I take 1.0.5 source, build with the source's internal libav, replace the .so with my built one there is a marked improvement, though still some issue The Arthur.mov now plays back fine, the ironman, better but flawed With libgstlibav.so from the internal libav source all the displayed frames in ironman are now correct. However there seems to some sort of delay?? at times of some frames that causes a ghost like flashing, hard to describe but quite obvious
What I'm most interested in is this: if you do - #define DEFAULT_MAX_THREADS 0 + #define DEFAULT_MAX_THREADS 1 in gstavviddec.c, are all the problems gone, or do some remain? I don't mind limiting the threads as a fix, we have done that in the past too (in 0.10) because of issues in libav/ffmpeg. (Maybe the 0.10 version pulls in a different libavcodecs version?)
Also interesting would be to know whether the issue still exists with gst-libav from git master (which is using a different/newer major libav version). For me it all works fine with master. If you do feel adventurous, you can test that using an uninstalled setup: http://gstreamer.freedesktop.org/wiki/UninstalledSetup
>- #define DEFAULT_MAX_THREADS 0 + #define DEFAULT_MAX_THREADS 1 Yes, that works fine, all issues are gone (package built using system libav As far as 0.10 - I believe it uses the same libav shared libs as 1.0 though the default for the 0.10 element is max-threads 1 (when using the previous posted gst-launch-0.10 blah/blah command with 0 or 2 is it really using multi-thread?, if so it works fine in 0.10
> Also interesting would be to know whether the issue still exists with gst-libav from git master Will give that a go later today/night
I believe there is another (or a) difference in 1.x compared to 0.10: in 1.x we set thread_type=FF_THREAD_SLICE (i.e. multiple threads decode the same picture if the way it was encoded allows that), in 0.10 the thread type might default to FF_THREAD_FRAME (not checked if that is the case, just guessing). Bug #678086 might also be relevant (though about 0.10).
> Also interesting would be to know whether the issue still exists with gst-libav Built git clones of gstreamer, plugins-base, good & libav to /opt/gstreamer Running gst-launch-1.0 ect. from there on the ironman vid & all is well, renders fine. Plugin Details: Name libav Description All libav codecs and formats (local snapshot) Filename /opt/gstreamer/lib/gstreamer-1.0/libgstlibav.so Version 1.1.0.1
Thanks a lot for your help and patience. I've pushed this to the 1.0 branch now: commit 879052472841d584e0aad21ac220131b586c1de5 Author: Tim-Philipp Müller <tim@centricular.net> Date: Mon Feb 25 10:38:09 2013 +0000 avviddec: fix H.264 decoding errors by disabling multi-threaded decoding Multi-threaded decoding does not work properly with the older libav 0.8 version included in this gst-libav series, so just disable multi-threaded decoding again entirely for now. (We could also switch from FF_THREAD_SLICE to FF_THREAD_FRAME, but that may have other side-effects and just disabling it seems safest for now). This works properly in git master with more recent libav 0.9.x versions. Adventurous users may still re-enable this functionality by setting the GST_AVVIDDEC_MAX_THREADS environment variable to 'auto' or the max. number of threads desired. https://bugzilla.gnome.org/show_bug.cgi?id=694230