GNOME Bugzilla – Bug 734963
totem from git master does not play certain video files
Last modified: 2014-09-01 11:29:20 UTC
totem from Fedora packages plays all my video files. totem from git master plays most of my video files, but doesn't play extremely specific old avi files. So I did some testing, by that I mean I reverted random commits that I thought to be related, built totem again, tried to play the video, and if it didn't fix the problem I reset my local copy to the real (upstream) git head, and repeat the process (ie. the lazy way of doing git bisect) until I found that reverting this commit fixed the issue: https://git.gnome.org/browse/totem/commit/?id=7763f75e05901e739bfbce81b7b07182f88b560c Now, this might be a gstreamer bug. gstreamer in Fedora 21 is 1.4.0, which is newer than the version of gstreamer needed for this feature to work. I have no idea why it's not working. Tips on how to debug this further would be appreciated.
Does removing the: g_object_set (bvw->priv->play, "audio-filter", bvw->priv->audio_pitchcontrol, NULL); call fix it for you?
Yes, that fixes it.
That looks like a GStreamer bug then. Which versions of the various GStreamer 1.x packages do you have?
gstreamer1-plugins-ugly-1.2.4-1.fc21.x86_64 gstreamer1-plugins-base-1.4.0-2.fc21.i686 gstreamer1-debuginfo-1.4.0-2.fc21.x86_64 gstreamer1-plugins-bad-free-extras-1.4.0-1.fc21.x86_64 gstreamer1-plugins-base-1.4.0-2.fc21.x86_64 gstreamer1-libav-1.2.4-1.fc21.x86_64 gstreamer1-vaapi-0.5.9-1.fc21.x86_64 gstreamer1-plugins-good-extras-1.4.0-1.fc21.x86_64 gstreamer1-plugins-base-devel-1.4.0-2.fc21.x86_64 libnice-gstreamer1-0.1.4-3.fc21.x86_64 gstreamer1-devel-1.4.0-2.fc21.x86_64 gstreamer1-1.4.0-2.fc21.i686 gstreamer1-1.4.0-2.fc21.x86_64 gstreamer1-plugins-bad-free-1.4.0-1.fc21.x86_64 gstreamer1-plugins-good-1.4.0-1.fc21.x86_64 gstreamer1-plugins-base-debuginfo-1.4.0-2.fc21.x86_64 python-gstreamer1-1.2.1-5.fc21.x86_64 gstreamer1-plugins-bad-freeworld-1.2.4-1.fc21.x86_64 gstreamer1-vaapi-debuginfo-0.5.9-1.fc21.x86_64
When you say "doesn't play" - how does it fail? Do you get an error message? If yes, which one? Does this fail as well? $ gst-launch-1.0 playbin uri=file:///path/to/foo.avi audio-filter=scaletempo If yes, could you run $ GST_DEBUG=*:6 gst-launch-1.0 playbin uri=file:///path/to/foo.avi audio-filter=scaletempo 2>dbg.log $ xz -9 dbg.log and attach the log here? (Or maybe make one such sample file available, that would be even easier for us) Also note that you're mixing different versions of packages, e.g. ugly, libav and bad-freeworld are still at 1.2.4.
Created attachment 284954 [details] affected video file I waited for a while for the plugins to get in sync in the repos before testing this, so I won't waste your time. Now that they are in sync again it seems that gst-launch fails on these files with or without scaletempo with a lot of "GStreamer-CRITICAL" errors, while "patched" totem (ie. removing the audio-filter line) can play them just fine and non-patched (ie. git master) totem can't play them at all. I attached the first 1MB of one of the affected files. Trying to play it with gst-launch results in these (gst-launch doesn't play it, it just freezes): (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_caps_is_empty: assertion 'GST_IS_CAPS (caps)' failed (gst-launch-1.0:1300): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed Trying to play the entire file results in the errors above followed by this error message: ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstAviDemux:avidemux0: Internal data stream error. Additional debug info: gstavidemux.c(5678): gst_avi_demux_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstAviDemux:avidemux0: streaming stopped, reason not-negotiated ERROR: pipeline doesn't want to preroll.
The file plays just fine here with 1.4.1 and git master. Can you get a backtrace with G_DEBUG=fatal_warnings?
Probably a duplicate of bug #735748 ?
(In reply to comment #8) > Probably a duplicate of bug #735748 ? Yep, as removing the audio filter fixes it. *** This bug has been marked as a duplicate of bug 735748 ***