GNOME Bugzilla – Bug 748619
"decodebin ! encodebin" woes
Last modified: 2015-04-30 11:36:26 UTC
Created attachment 302546 [details] debug log up to access violation Testing this generic and trivial pipeline : gst_parse_launch ("filesrc name=src ! decodebin name=dec ! encodebin name=enc ! filesink name=sink", &error); I set the "location" property files for src & sink and I set "profile" for encodebin. The profile has valid video & audio caps for encoding : - container cap is "application/ogg" - video cap is "video/x-theora" - audio cap is "audio/x-vorbis" Result: The pipeline plays thru correctly, but the resulting file has only video, no audio. Thinking that the problem was unconnected pads, I added a "pad-added" signal-handler to decodebin. Result: The encoding process continues for as long as I have patience to wait, never finishing. In the two calls to the signal-handler, gst_pad_link() fails with error codes GST_PAD_LINK_WAS_LINKED and GST_PAD_LINK_NOFORMAT,so it's of not much use anyway. I abolished the "pad-added" signal-handler and tried the following two pipelines : filesrc name=src ! decodebin name=dec ! encodebin name=enc ! filesink name=sink dec.audio_00 ! enc. and filesrc name=src ! decodebin name=dec ! encodebin name=enc ! filesink name=sink dec.audio_% ! enc. Results: Sometimes encoding works, generating only video. If I then close/unref all objects and try again, I usually get an error that aborts my program and which looks as if abort() was called. Most often I get on first use a memory-violation exception : First-chance exception in myexe.exe (LIBGSTREAMER-1.0-0.DLL): 0xC0000005: Access Violation. I attach the debug log for the exception. However, my main problem is how to get "decodebin ! encodebin" working. Any advice?
That decodebin ! encodebin only encodes one stream is expected behaviour, that's just how the pipeline syntax works. You have to explicitly link each stream, which also requires knowledge about how many streams there are, so realistically you want to write some code (python, C, whatever) that handles that dynamically. As for the crash (access violation), we would need a stack trace from a debugger to see where it crashed exactly.
I did write code in C to handle multiple streams via the "pad-added" signal on decodebin, only gst_pad_link() fails as described above. My handler is the same as in examples found in the GStreamer sources & manual. For a meaningful stack trace from a debugger, I would need at least .pdb symbol files for the release DLLs (might be a good idea to always include them in the release for bug-reports). More precise would be a Windows debug version of the release if available from somewhere. Recompiling the sources on my side would require instructions for setting up the compile environment.
Well, the error codes tell you where to look I think. WAS_LINKED is hard to argue with (perhaps because you left a ! in there?), and NO_FORMAT means you didn't request the right pad to link to or there's no matching pad. encodebin has action signals to request pads. You may want to look at the application 'transmageddon' which does something like this too. This decodebin / encodebin seems more like a support issue to me, so perhaps we should take that to the gstreamer-devel mailing list instead. --- The ready-made binaries do ship with debugging symbols, they're just not compatible with the MSVC debugger. That's because we use mingw to generate those binaries and it can't output MS-compatible debugging symbols (because the format of those is not public and hasn't been reverse-engineered yet afaik). You can debug using gdb. We know it's a very suboptimal situation for MSVC users, but that's how it is, until someone fixes it one way or another. (I think the llvm folks are working on PDB support.)
The pad part is already on gstreamer-devel, where there was no response : http://lists.freedesktop.org/archives/gstreamer-devel/2015-April/052632.html Any pointers on debugging the crash?
Run your application or gst-launch in gdb from a terminal and then look at the stack trace with 'bt'. Alternatively, if you can provide us with a way to reproduce it (gst-launch command line to run with input file, or some such), then please file a new bug abuot it and attach information how to reproduce it there, then we can investigate, thanks!