GNOME Bugzilla – Bug 626501
Caps property of gnlfilesource works incorrectly
Last modified: 2010-08-10 07:39:21 UTC
Suppose, I'd like to cut a fragment from a video clip and save it to a new file of the same format, and make it as quick as possible. Or, suppose I have another task - cut several pieces of one file and merge them to a file of the same format (to cut out commercials from a saved TV show). That said, I don't want to recode the file. I create a pipeline, a gnlcomposition object, and two fakesinks and put them to the pipeline. I plan to replace fakesinks with the muxer and filesink. I've also set a pad-added handler. Then I've create several gnlfilesources, set their properties and put them to the gnlcomposition. Among others, I also set the caps properties of the gnlfilesources to "video/mpeg,parsed=true,systemstream=false;audio/mpeg,parsed=true" Then I've put the pipeline to playing. My pad-added handler is never got called. However, it's called when I don't set caps on gnlfilesources. Studying sources of the GNonLin shows that it uses uridecodebin. Studying the output of "gst-inspect uridecodebin" shows that is has "caps" property, which tells it when to stop decoding. Probably, this feature is going to be used in gnlfilesource. However, there is no code in GNonlin sources, setting this property for internal uridecodebin. Dumping the pipeline to the dot file also shows that internal uridecodebin has "video/raw-blah-blah-blah;audio/raw-blah-blah-blah" caps. Adding a small function, setting caps in the internal uridecodebin, at least, partially addresses this bug.
Fixed in gnonlin git commit 930505400466d072b9c5cc7aee6ce7ba503c62fe Author: Edward Hervey <bilboed@bilboed.com> Date: Fri Mar 19 10:36:42 2010 +0100 GnlURISource: Set the GnlObject caps on uridecodebin. This allows getting non-raw streams.