GNOME Bugzilla – Bug 688183
Matroskademux misbehaving inside uridecodebin
Last modified: 2012-11-13 12:17:12 UTC
I am written a small test app to try to mix 2 video streams and 2 audio streams stored in a matroska file. I think the code is correct now, but I am getting an error from matroskademux: matroska-demux.c(4562): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecoder/GstDecodeBin:decodebin0/GstMatroskaDemux:matroskademux0: stream stopped, reason not-negotiated Since this is happening inside uridecodebin I don't think it is something I am doign wrong. Will be adding test app and test input file
Created attachment 228789 [details] Simple python test application
> Since this is happening inside uridecodebin I don't think it is something I am > doign wrong. That does not follow. It likely happens outside of uridecodebin, it's just that matroskademux reports the error, since it's the element driving the pipeline. Create a GST_DEBUG=*:6 log, dump it to file, then: grep -B20 not-negotiated dbg.log It's probably that the inputs to adder or videomixer are not compatible, it's annoying/needs some work to get that right.
Test file: http://www.linuxrising.org/misc/test.mkv Ok, generated log and will attach it, but based on comment I guess this is the problem: 0:00:00.466766986 17760 0x7fdcbc055680 ERROR videomixer videomixer2.c:320:gst_videomixer2_pad_sink_setcaps:<videomixer2-0:sink_1> Caps not compatible with other pads' caps
Created attachment 228790 [details] gst_debug log
Added some debug prints, caps seems ok to me. incoming caps are video/x-raw, format=(string)I420, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, chroma-site=(string)jpeg, colorimetry=(string)2:4:5:0, framerate=(fraction)30/1 videomix caps are video/x-raw, format=(string){ I420, YV12, YUY2, UYVY, AYUV, RGBx, BGRx, xRGB, xBGR, RGBA, BGRA, ARGB, ABGR, RGB, BGR, Y41B, Y42B, YVYU, Y444, v210, v216, NV12, NV21, GRAY8, GRAY16_BE, GRAY16_LE, v308, RGB16, BGR16, RGB15, BGR15, UYVP, A420, RGB8P, YUV9, YVU9, IYU1, ARGB64, AYUV64, r210, I420_10LE, I420_10BE, I422_10LE, I422_10BE }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ] Will update app with this new version gathering this information.
Created attachment 228793 [details] Updated test app
Closing, turned out to be a bug in my code
Ok, after further testing it seems my fix only worked by chance. Could still be a problem with my code, but error message I get doesn't make sense to me. Will attach new log and current verson of test app. Log seems to give following error: 0:00:00.339625961 ^[[336m19955^[[00m 0x7fadd8055680 ^[[36mINFO ^[[00m ^[[00m videomixer videomixer2.c:398:gst_videomixer2_pad_sink_acceptcaps:<videomixer2-0:sink_2>^[[00m not accepted caps video/x-raw, format=(string)I420, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, chroma-site=(string)jpeg, colorimetry=(string)2:4:5:0, framerate=(fraction)30/1
Created attachment 228803 [details] New log file
Created attachment 228804 [details] Newest test app version
> gst_videomixer2_pad_sink_acceptcaps:<videomixer2-0:sink_2>^[[00m > not accepted caps video/x-raw, format=(string)I420, width=(int)320, > height=(int)240, pixel-aspect-ratio=(fraction)1/1, > interlace-mode=(string)progressive, chroma-site=(string)jpeg, > colorimetry=(string)2:4:5:0, framerate=(fraction)30/1 Ok, those those are the caps it did not want to accept. Now, what are the caps it did accept on the other sink pad(s)? (sink_0 and/or sink_1 presumably)
Sorry, turns out I was just placing my audio/video converter the wrong place.
FYI, https://bugzilla.gnome.org/show_bug.cgi?id=684237
Thanks Nicolas, I was about to open this bug again as things seemed to work/not work quite randomly. I will follow your bug instead now. *** This bug has been marked as a duplicate of bug 684237 ***