I'm evaluating Snowmix under Ubuntu 13.10 and am working through the examples.
The supplied demos using a file source work as expected except that Snowcub becomes unresponsive immediately. Otherwise the video feeds and overlays play without error.
Now, I am trying to change the input source from the provided LES_TDS_launch.mp4 to /dev/video0.
I am using the basic demo configuration and trying to get the feed from my web came to appear in feed #1.
In another post I saw that it was suggested to simply copy input2feed and change the SRC line to:
This yields the following error:
WARNING: erroneous pipeline: No element named "decoder" - omitting link
I can change the SRC line to:
SRC='v4l2src device=/dev/video0 ! $decodebin name=decoder '
which does not generate errors. The webcam light turns on and the timer in Feed #1 in output2screen starts running however it displays completely black.
I have verified the web cam works using the Ubuntu 'cheese' program and have verified that I have the correct device file /dev/video0.
I suspect it's the decoder but, being new to this, I do not yet know how the decoding works. Any pointers would be greatly appreciated. Thank you.
You seem to have CSS turned off.
Please don't fill out this field.
Yes Snowcub can become unresponsive if the expectecd settings of Snowmix are not as expected. Next version will improve on this although Snowcub is more a test and a prove of concept rather than an applicatione thought to be used by anyone. Though admittedly, Snowcub can be good for many things.
Regarding the decoder, then you script is detecting audio setup in Snowmix and tries to run the pipeline including audio. So either change your script to select the non audio pipeline, or remove the audio feed settings in Snowmix or change your pipeline to include audio with something like this:
SRC="alsasrc device=YOURDEVICE name=decoder v4l2src device=/dev/video0 "
That way the pipeline including audio can find a path named encoder with audio in it. Basically you just define SRC to emulate what comes out of a decoder.
You may have to set 'do-timestamp=true' for either alsasrc or v4l2src or both. You may have to set 'sync=true' for either shmsink or fdsink or both.
If it is still black, please post both your complete ini file and your complete script you are using to feed it. Also your output script if you are not using one of the scripts supplied with Snowmix. Then I'll take a look at it. Please note that /dev/video0 is often the laptop built-in camera if it has one. If it has, then an external camera might become /dev/video1. Probably not the problem, but thought I'd mention it.
let me know how it goes.
My bad. It turns out on the machine that has a webcam on it even the demo using the file sources does not work so my problem lies elsewhere. Thank you for responding so promptly.
The latest update to Ubuntu 14.04 LTS breaks Snowmix on my desktop machine. The basic_feeds, text_tutorial, etc worked but now after the update the videos will play for a few seconds then just display the dead frames.
The audio plays. But I do get this message from one of the terminal windows:
WARNING: from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2791): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage:
There may be a timestamping problem, or this computer is too slow.
This is using Snowmix 0.4.3 under Ubuntu 14.04 LTS on a Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz.
Could you list specifically what combinations that does not work? Which ini files with which scripts?
What version of GStreamer are you using ?
Some GStreamer version 1.x are slower than 0.10, especially if you are inputting several feeds. Some input pipelines consume twice or tripple as much CPU with some GStreamer version 1.x.
If possible, use GStreamer 1.3.2 or 1.3.3. Or at least 1.2.4. Or go back to use GStreamer 0.10 until you can use the version 1.4 to be released later this summer. You can uncomment the following line in scripts/gstreamer-settings
and change it to
to force using the gstreamer 0.10 version.
GStreamer 1.x also require considerably larger shmsize compared to version 0.10. In general you need at least a shmsize of
So doing something like
SHMSIZE='shm-size='`echo "$feed_width * $feed_height * 4 * 14"|bc`
assuming the feed_width and feed_height is set in your script.
Let me know how it goes.
I am literally just running the "demo" script and choosing option 1 without any modifications.
I'm using GStreamer 1.2.4.
I installed gstreamer0.10 and uncommented the line you suggested.
The basic_feeds demo just shows me the dead images.
The text_tutorial displays the text overlay on the dead images but does not play the video.
Before one of the auto-launched terminal windows disappeared I noticed this error:
Video feed geometry : 1024 x 576
Video control socket : /tmp/feed4-control-pipe
Video and audio feed id : 4 4
Failed to get rate or channels from running snowmix
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin2:decoder/GstQTDemux:qtdemux0: GStreamer encountered a general stream error.
Additional debug info:
qtdemux.c(3891): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstDecodeBin2:decoder/GstQTDemux:qtdemux0:
streaming stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Interestingly, reverting to gstreamer-1.2.4 and increasing the SHMSIZE as you suggest causes two of the video streams in the basic_feeds demo to play for a few seconds before reverting to the dead image.
A further note. interestingly increasing the SHMSIZE in input2feed dramatically allows two of the feeds to play for about 10 seconds when using gstreamer-1.2.4
Assuming you are running demo case 1 (basic_feeds) ?
How much CPU is idle when the videos are still playing ?
What is dramtically in size ?
How much shm do you have left (use the df -k)
Yes, demo case 1, basic_feed.
To make error messages easier to see I am running the commands by hand
With a single instance of input2feed running and looking at top while the video is still playing idle bounces between 0 and 6% which I'm guessing is pointing at a problem. Before I this latest update to ubuntu it definitely felt like things were running quicker so I'm guessing something changed in gstreamer.
There seems to be plenty of shared memory:
none 1669276 241592 1427684 15% /run/shm
I had upped the SHMSIZE to 80megs and that lets the video run for about 10 seconds.
Using gstreamer0.10 I am unable to get the video to play at all.
Thank you for taking the time to help me diagnose this issue. It's sounding to me like it's not an issue with snowmix at all but instead of gstreamer.
I am trying gstreamer 1.3.3, per your recommendation above. I'm having to build it since there's no Ubuntu package for it apparently.
I seem to be missing a plugin. Does this error message tell you which plugin I'm missing when trying to run the basic_feeds demo?
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decoder: Your GStreamer installation is missing a plug-in.
Most likely you are missing the faad plugin although the avdec_aac should in theory work. You need the filesrc, the mp4 demuxer, the H.264 decoder, the AAC decoder and the queues, the audio and video converts and the shmsink.
On the display side you need the shmsrc, the audio and video converts, the video sink (ximagesink or xvimagesink or something else) and the audio sink (alsasink or pulsesink or something else).
By the way, please start a new thread in the forum when the subject change. That way other readers can navigate the forum more easy.
or maybe is there a list of gstreamer plugins that the basic_feeds demo needs?
Does it work for you now?
Sign up for the SourceForge newsletter: