GNOME Bugzilla – Bug 568686
appsrc caps aren't getting set correctly
Last modified: 2009-06-17 13:18:05 UTC
The log from : gst-launch-0.10 --gst-debug-level=3 --gst-debug-no-color appsrc is-live=true caps=audio/x-raw-int,rate=44100,channels=2,width=16 ! volume ! alsasink 2> /tmp/log which I'll attach to that bug, shows : 0:00:00.090367840 8967 0x9bf4050 INFO GST_PIPELINE ./grammar.y:478:gs t_parse_perform_link: linking appsrc0:(any) to volume0:(any) (0/0) with caps "(N ULL)" which is not normal, since I explicitly set caps! This I think is the reason why my audio output code in ekiga doesn't work (worse: crashes), as reported on the mailing-list recently.
Created attachment 126993 [details] The log of the command I mention in comment #1 I'm using the package gstreamer0.10-plugins-base 0.10.21.3-1 from debian experimental, in case that matters.
Those caps are not complete. You need something like : audio/x-raw-int,rate=44100,channels=2,width=16,depth=16,signed=true,endianness=1234
Uh... so when they're not complete, they just get ignored? Notice that the following : gst-launch-0.10 --gst-debug-level=3 --gst-debug-no-color appsrc is-live=true caps=audio/x-raw-int,rate=44100,channels=2,depth=16,width=16,signed=true,endianness=1234 ! volume ! alsasink 2>/tmp/log doesn't show more caps used...
> Uh... so when they're not complete, they just get ignored? I think they should be rejected by the downstream element, with a GST_FLOW_NOT_NEGOTIATED being returned to appsrc, which in turn will then post a 'internal flow error' message on the bus. > Notice that the following : > gst-launch-0.10 --gst-debug-level=3 --gst-debug-no-color appsrc is-live=true > caps=audio/x-raw-int,rate=44100,channels=2,depth=16,width=16,signed=true,endianness=1234 > ! volume ! alsasink 2>/tmp/log > > doesn't show more caps used... That's because no buffers get pushed when you use this in gst-launch (try with is-live=false and you'll see that it doesn't even preroll).
The following at least links appsrc to capsfilter with the right caps : gst-launch-0.10 --gst-debug-level=3 --gst-debug-no-color appsrc is-live=true ! audio/x-raw-int,rate=44100,channels=2,depth=16,width=16,signed=true,endianness=1234 ! volume ! alsasink 2>/tmp/log But the caps aren't used anymore when connecting the other elements :-/ Notice that modifying my ekiga code to do likewise makes the crash go away... and some buffers go through (not all of them though).
> Notice that modifying my ekiga code to do likewise makes the crash go away... It shouldn't crash, that's a bug. Please provide a full stack trace with debugging symbols.
Created attachment 127037 [details] Log of the crash This is the log from the crash I had when I used caps= and not a capsfilter element ; it's triggered by a failed assertion : I'm pushing buffer in the pipeline...
Please attach or make available a full *:5 log *:3 logs are usually not very useful.
Created attachment 127072 [details] The --gst-debug-level=5 log of the crash Oh, sorry -- no problem, it's pretty easy to reproduce!
Is the second log better?
the width property is not set on the appsrc caps.
Created attachment 127244 [details] The gst-debug-level=5 log of NULL caps though they were given Sigh... next try -- it doesn't crash anymore, but it's still linking ekiga_src to ekiga_volume with NULL caps -- which seems wrong. Notice that having wrong caps doesn't explain why it was crashing : if they were invalid, they should have triggered error messages, not stopped the program on a failed assertion.
I don't see an error except some strange behaviour: A whole bunch of buffers are pushed into appsrc (255780 bytes) but before those buffers are played by the audiosink, the pipeline is set to NULL again. I don't know why anyone would do that, what's going on here?
The behaviour is simple : - the pipeline gets created ; - the data is pushed through chunk by chunks ; - the pipeline gets disposed of. Of course, if the pipeline didn't consume the data, that would explain why I don't get any sound! (notice that video input works like this -- using appsink of course -- but works)