GNOME Bugzilla – Bug 712290
GES cannot unmux raw video streams
Last modified: 2014-11-01 08:35:21 UTC
Created attachment 259799 [details] Python example of loading the video file I generated following files: gst-launch-1.0 videotestsrc num-buffers=100 ! videoconvert ! matroskamux ! filesink location=raw.mkv gst-launch-1.0 videotestsrc num-buffers=100 ! videoconvert ! qtmux ! filesink location=raw.mov gst-launch-1.0 videotestsrc num-buffers=100 ! videoconvert ! avimux ! filesink location=raw.avi They all contain raw video streams and are playable by Totem / gst-play. GES cannot link the pipeline due to demuxing errors: MKV (GError('GStreamer encountered a general stream error.',), 'matroska-demux.c(4672): gst_matroska_demux_loop (): /GESPipeline:gespipeline0/GESTimeline:gestimeline0/GESVideoTrack:gesvideotrack0/GnlComposition:gnlcomposition1/GnlSource:gnlsource0/GstBin:videosrcbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin3/GstMatroskaDemux:matroskademux1:\nstream stopped, reason not-negotiated') AVI (GError('Internal data stream error.',), 'gstavidemux.c(5383): gst_avi_demux_loop (): /GESPipeline:gespipeline0/GESTimeline:gestimeline0/GESVideoTrack:gesvideotrack0/GnlComposition:gnlcomposition1/GnlSource:gnlsource0/GstBin:videosrcbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin3/GstAviDemux:avidemux1:\nstreaming stopped, reason not-negotiated') MOV Segmentation fault (core dumped)
+ Trace 232768
(I will provide a full backtrace soon, since I don't have debug symbols)
Backtrace of the quicktime crash with debug symbols (the crash occured with python)
+ Trace 232769
Patch from https://bugzilla.gnome.org/show_bug.cgi?id=712328 should fix the issue for matroska.
(In reply to comment #1) > Backtrace of the quicktime crash with debug symbols (the crash occured with > python) > > > That looks like a bug in the blending code... which is pretty insteresting as we should clearly not be blending in this simple case.
And https://bugzilla.gnome.org/show_bug.cgi?id=712343 for avi
(In reply to comment #3) > (In reply to comment #1) > > Backtrace of the quicktime crash with debug symbols (the crash occured with > > python) > > > > > > > > That looks like a bug in the blending code... which is pretty insteresting as > we should clearly not be blending in this simple case. Actually: https://bugzilla.gnome.org/show_bug.cgi?id=712401
I don't understand the dependency on all these other bugs. Does GES look at the content of the CODEC tags for anything?
I can confirm that the patch on -base fixes the AVI issue and the patch on -good fixes the mkv issue.
(In reply to comment #6) > I don't understand the dependency on all these other bugs. > > Does GES look at the content of the CODEC tags for anything? I just opened bugs for the actual issues that this bugs is about so we do not end up having pathes for specific issues in here. And I made this bug depend on those specific issues as it is more easy to follow this way (at least for me), and that bug can be closed when those 3 specific bugs are finally closed. Isn't it the right way to do that?
I may have misunderstood what those patches do. I thought they mainly use the pbutils stuff for the codec tags, but it's the using-GstVideoInfo thing that fixes stuff here, is it?
(In reply to comment #9) > I may have misunderstood what those patches do. I thought they mainly use the > pbutils stuff for the codec tags, but it's the using-GstVideoInfo thing that > fixes stuff here, is it? Right the main point of those patches is to make use of the GstVideoInfo API to create raw video caps, and this is the part that fixes the issues described here.
Ok so I just retested it on master and it works.