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 700324 - playbin hangs trying to play 4K video, and hangs again on interrupt
playbin hangs trying to play 4K video, and hangs again on interrupt
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.0.7
Other Linux
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-05-14 18:22 UTC by Stirling Westrup
Modified: 2013-05-17 06:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
Backtraces of all threads when playbin is hung. (24.01 KB, text/plain)
2013-05-15 20:51 UTC, Stirling Westrup
Details

Description Stirling Westrup 2013-05-14 18:22:18 UTC
I'm using the latest git build of GStreamer as of May 13. I have attempted to use the exact same command line as below to play other 4K videos, without any problems.

However, I recently downloaded the 4K version of the Open source animation 'Sintel'. Its huge, but a bittorrent can be found here: http://thepiratebay.sx/search/sintel+4k/0/99/0

When I tried to view the video in my gstreamer application (which internally uses decodebin), I got an error:

Error: matroskademux0: GStreamer encountered a general stream error. (matroska-demux.c(4562): gst_matroska_demux_loop (): /GstPipeline:pipeline/GstBin:reader/GstDecodeBin:decoder/GstMatroskaDemux:matroskademux0:

As this appeared to be a negotiation failure inside decodebin, I decided to see how playbin would handle the same file:

DISPLAY=:2 gst-launch-1.0 playbin uri=file:~/Videos/4K/Sintel-4K.mkv

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

And it sat there like that for several minutes until I hit ^C:

^Chandling interrupt.
Interrupt: Stopping pipeline ...
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...

And at that point it hung again and I had to manually kill the process to stop it.

I should mention that I've also run across the problem in my own application of attempting to set a pipeline to NULL to perform a clean exit after an error only to have it hang. This is the simplest case I've yet found where one can demonstrate that issue.


I should
Comment 1 Sebastian Dröge (slomo) 2013-05-15 07:40:05 UTC
Can you get backtraces of all threads with gdb when it hangs?
Comment 2 Tim-Philipp Müller 2013-05-15 10:08:48 UTC
That file plays "fine" for me in principle, at least with playbin video-sink=ximagesink. Without that it picks xvimagesink, which just doesn't output anything, though it creates the window, with lots of ERRORS that it couldn't map the frame. Probably too big.
Comment 3 Stirling Westrup 2013-05-15 20:51:13 UTC
Created attachment 244355 [details]
Backtraces of all threads when playbin is hung.

Well, I don't get any error messages at all when trying the command line I specified. However I can confirm that adding video-sink=ximagesink works and I get a beautifully playing video.

I'm attaching a log of backtraces. It looks like all threads are either waiting on a condition, or a lock...
Comment 4 Sebastian Dröge (slomo) 2013-05-16 07:47:02 UTC
I believe this is fixed by

commit 74a31a02fc6b2d6cba91765e6bc62525fa9bffb5
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Wed May 15 13:38:32 2013 +0200

    playbin: Fix deadlock caused by lock order inversion
    
    First the source group lock, then the elements list lock.


Can you test that?

http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=74a31a02fc6b2d6cba91765e6bc62525fa9bffb5
Comment 5 Stirling Westrup 2013-05-16 15:35:08 UTC
Yes, that fixed it. With that commit, my playbin pipeline runs without issue.