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 694230 - quicktime videos have decoding issues in gst-1.x
quicktime videos have decoding issues in gst-1.x
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
1.0.5
Other Linux
: Normal normal
: 1.0.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-02-20 01:12 UTC by Doug McMahon
Modified: 2013-02-25 10:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
requested log (41.86 KB, text/plain)
2013-02-20 23:54 UTC, Doug McMahon
Details
requested dpkg info (3.24 KB, text/plain)
2013-02-20 23:56 UTC, Doug McMahon
Details

Description Doug McMahon 2013-02-20 01:12:59 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
Comment 1 Doug McMahon 2013-02-20 01:30:00 UTC
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
Comment 2 Tim-Philipp Müller 2013-02-20 09:27:39 UTC
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
Comment 3 Doug McMahon 2013-02-20 14:34:17 UTC
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
Comment 4 Tim-Philipp Müller 2013-02-20 23:32:35 UTC
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*'

?
Comment 5 Tim-Philipp Müller 2013-02-20 23:47:05 UTC
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).
Comment 6 Doug McMahon 2013-02-20 23:54:57 UTC
Created attachment 236996 [details]
requested log
Comment 7 Doug McMahon 2013-02-20 23:56:24 UTC
Created attachment 236997 [details]
requested dpkg info
Comment 8 Tim-Philipp Müller 2013-02-21 09:32:15 UTC
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.
Comment 9 Tim-Philipp Müller 2013-02-21 09:33:42 UTC
(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.)
Comment 10 Doug McMahon 2013-02-21 14:21:18 UTC
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.
Comment 11 Tim-Philipp Müller 2013-02-21 14:43:44 UTC
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?
Comment 12 Doug McMahon 2013-02-21 15:22:10 UTC
Excellent - the ^ gst command plays the vid back without issue
Comment 13 Doug McMahon 2013-02-23 16:30:47 UTC
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
Comment 14 Tim-Philipp Müller 2013-02-23 16:54:42 UTC
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?)
Comment 15 Tim-Philipp Müller 2013-02-23 16:56:10 UTC
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
Comment 16 Doug McMahon 2013-02-23 17:19:16 UTC
>- #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
Comment 17 Doug McMahon 2013-02-23 17:20:35 UTC
> 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
Comment 18 Tim-Philipp Müller 2013-02-23 17:39:33 UTC
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).
Comment 19 Doug McMahon 2013-02-23 20:51:07 UTC
> 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
Comment 20 Tim-Philipp Müller 2013-02-25 10:46:05 UTC
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