GNOME Bugzilla – Bug 661909
Remuxing gravity.mpeg doesn't work
Last modified: 2011-12-02 11:07:16 UTC
Trying to remux gravity.mpg: http://gstreamer.freedesktop.org/media/large/gravity.mpg with Transmageddon, but it fails no matter on remuxing the video. The file contains MPEG-1 video, so my guess is that the new parsers have trouble with it.
Created attachment 199122 [details] GST_DEBUG log
The issue appears to be with the mpeg version field, which some elements specify as [1, 2] and others as {1, 2}. The equivalence is lost of the comparison function, which only understands scalar to list equivalence. Adding range/list and range/scalar equivalence seems a bit hairy but not hard to do, though I'm not sure if that would not have unwanted side effects.
And another bug that might be fixed by the patch I'm marking as a dependency (that's if my hunch above was correct).
Hi Vincent, Still having trouble remuxing, don't remember what I originally got, but I am getting this one the console now.
+ Trace 229023
src_pad.link(sinkpad)
GStreamer encountered a general stream error. gstbasesrc.c(2621): gst_base_src_loop (): /GstPipeline:TranscodingPipeline/GstURIDecodeBin:uridecoder/GstFileSrc:source: streaming task paused, reason not-linked (-1)
Just tried transmageddon and your file. The caps error is now gone, but I'm still getting that not-linked error too, so it looks like there were two separate issues indeed. I'll look into it.
What a WTF ride :D So, it took me a while to realize that no demuxer was plugged by decodebin2, because there are two pipelines: a first one for discovery, and a second one for transcoding, and grepping for "creating element" showed everyhting I expected. Still, it was plugging in a MPEG video pipeline all fine, hiding that demuxer's absence. In the end, it turns out the bug was in transmageddon :p For whatever reasons, a muxed MPEG stream has a media type of "video/mpeg, systream=(true)", while the video inside has "video/mpeg, systemstream=(false)". On the second (transcoding) pipeline, transmageddon choses to set the caps property to the contained codecs, to prevent decoders from being plugged. However, it choses to remove all fields from the video media type, which gets rid of "systemstream=false", and ends up matching "systemstream=true". So autoplugging stopped just before plugging the demuxer, as caps were deemed final. The following patch (disabling the code which removes fields from the video codec media type) fixes the issue, but I guess you may want to replace this with something that special cases systemstream, as whetever issue caused you to do this would likely show up again. I tested by remuxing to Matroska. The remuxed output looks chuggy, but that's another issue. diff --git a/src/transmageddon.py b/src/transmageddon.py index 51dfb5f..d61de41 100644 --- a/src/transmageddon.py +++ b/src/transmageddon.py @@ -706,7 +706,7 @@ class TransmageddonUI: textdata=gst.Caps.to_string(self.vsourcecaps) sep= ',' minitext = textdata.split(sep, 1)[0] - videocodec = minitext + videocodec = textdata #minitext self.outputdirectory=self.videodirectory else: self.outputdirectory=self.audiodirectory
Verified, I was working around another issue and caused this. Thnx for fixing this :)