hi I am trying to visualize a music file in gstreamer using the following command:
gst-launch filesrc location=file.mp3 ! decodebin ! audioconvert !
tee name=myT myT. ! queue ! autoaudiosink myT. ! queue ! goom !
colorspace ! autovideosink
But I get this error : "There may be a timestamping problem, or this computer is too slow."
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
WARNING: from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstDshowVideoSink:autovideosink0-actual-sink-dshowvideo: A lot of buffers are being dropped.
Additional debug info:
..\Source\gstreamer\libs\gst\base\gstbasesink.c(2572): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstDshowVideoSink:autovideosink0-actual-sink-dshowvideo:
There may be a timestamping problem, or this computer is too slow.
ERROR: from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0
Assuming this is something to do with the thread, I tried the following command:
gst-launch filesrc location=file.mp3 ! decodebin ! audioconvert ! tee name=myT
{ ! queue ! autoaudiosink } { tee. ! queue ! goom ! colorspace ! autovideosink }
But then it gives the folloiwng link error:
** (gst-launch-0.10:5308): WARNING **: Trying to connect elements that don't share a common ancestor: tee and queue1
0:00:00.125000000 5308 003342F0 ERROR GST_PIPELINE grammar.tab.c:656:gst_parse_perform_link: could not link tee to queue1
WARNING: erroneous pipeline: could not link tee to queue1
Can anyone tell what is wrong? Thanks
I cannot give you an exact answer because i don't have windows installed.
For debugging this use your first pipeline (in linux works). Use parameter -v with gst-launch and put element identity just before autovideosink. This will print buffer information that passes through element identity, look for anything strange.
Also you could try to use directdrawsink instead of autovideosink. Another test that i will do is to generate the audio with audiotestsrc.
Remember that if you find a bug you can open a bug report in gnome bugzilla so GStreamer developers are aware that there is a problem. Even you could fix it yourself and send a patch.
For There may be a timestamping problem, or this computer is too slow. Error Try sync=false like
`gst-launch filesrc location=file.mp3 ! decodebin ! audioconvert ! tee name=myT myT. ! queue ! autoaudiosink myT. ! queue ! goom ! colorspace ! autovideosink sync=false`
or you may have to try at both sink ends of the Tee like
`gst-launch filesrc location=file.mp3 ! decodebin ! audioconvert ! tee name=myT myT. ! queue ! autoaudiosink sync=false myT. ! queue ! goom ! colorspace ! autovideosink sync=false`
I also observed that if you replace autovideosink with xvimagesink or ximagesink the timestamping problem apparently seems to be solved.
Related
I am currently trying to use gstreamer to record a duplicate of my PC output but I am struggling to find a pipeline that works.
The requirements I am trying to meet are:
decklinkvideo & decklinkaudio in
encode into h264 via my recording machines built in gpu (vaapih264enc)
output to an avi container.
The closest I have come so far is the following pipeline:
GST_DEBUG=3,decklink:5 gst-launch-1.0 -e decklinkvideosrc mode=1080p60 ! queue ! videoconvert ! vaapipostproc ! vaapih264enc tune=low-power ! h264parse ! queue ! mux. qtmux name=mux ! filesink location=/home/user/video_a.avi
However, this results in a video which is green and red only and the scale is way off.output video frame
Any advice or help would be greatly appreciated.
I managed to fix this issue with the following pipeline:
GST_DEBUG=3,decklink:5 gst-launch-1.0 -e decklinkvideosrc ! queue ! videoconvert ! vaapih264enc ! h264parse ! queue ! mux. decklinkaudiosrc ! queue ! audioconvert ! lamemp3enc ! mux. qtmux name=mux ! filesink location=test.avi
It seems that the vaapih264enc does not support I420 format when using the free drivers which the kernel pre-installs. Therefore, you could fix this issue with the below pipeline. Here we are converting the I420 into NV12.
GST_DEBUG=3,decklink:5 gst-launch-1.0 -e decklinkvideosrc mode=1080p60 ! queue ! videoconvert ! video/x-raw,format=NV12 ! vaapih264enc tune=low-power ! h264parse ! queue ! mux. qtmux name=mux ! filesink location=test.avi
You can also fix this by installing the non-free va drivers with:
sudo apt-get install intel-media-va-driver-non-free
Then run the below command to check they have been installed correct. The non-free driver unlocks high-power mode for the vaapih264enc and support for I420 format.
sudo vainfo
If you did install the non-free driver then the following pipeline should work for you with vaapih264enc running in high powered mode.
GST_DEBUG=3,decklink:5 gst-launch-1.0 -e decklinkvideosrc mode=1080p60 ! queue ! videoconvert ! vaapih264enc ! h264parse ! queue ! mux. decklinkaudiosrc ! queue ! audioconvert ! lamemp3enc ! mux. qtmux name=mux ! filesink location=test.avi
I have a gstreamer pipeline that streams using :
v4l2src ! x264enc ! rtph264pay pt=96 ! udpsink host=ip port=8554
And this pipeline that receives this stream :
/ queue ! avdec_h264 ! appsink
udpsrc ! capsfilter ! rtpjitterbuffer ! rtph264depay ! tee !
\ queue ! h264parse ! mp4mux ! filesink
Simplified receiver pipeline without the tee is :
gst-launch-1.0 udpsrc port=8080 caps="lots-of-caps" ! rtpjitterbuffer ! rtph264depay ! h264parse ! mp4mux ! filesink location=/home/rish/Desktop/recorded.264 -e
Question :
Is there a way to save the H264 encoded stream received from udpsrc without having to re-encode it? How do I correctly close the filesink?
What I've tried so far : The discussion from this thread suggests the pipeline I've tried above but file is still corrupt. (not correctly closed).
This question asks a similar question. However I do not want to decode and re-encode. Another answer in the thread suggests using matroskamux element instead of mp4mux. This works, but I'd rather prefer using mp4mux (no particular reason, but I'd like to know why matroskamux works and mp4mux doesn't).
Your pipeline is already muxing without re-encoding, there is no encoder on your pipeline. h264parse is just a parser.
you've already got an answer on how to close the stream here: Sending EoS to filesink while removing branch from tee
gst-launch-1.0 filesrc location=subtitleseng.srt ! subparse ! overlay. filesrc location=video.mp4 ! qtdemux ! queue ! theoradec ! ffmpegcolorspace ! subtitleoverlay name=overlay ! xvimagesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPipeline:pipeline0/GstSubtitleOverlay:overlay: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.
Additional debug info:
gstsubtitleoverlay.c(799): _pad_blocked_cb (): /GstPipeline:pipeline0/GstSubtitleOverlay:overlay:
Subtitle sink is blocked but we have no subtitle caps
ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: GStreamer encountered a general stream error.
Additional debug info:
qtdemux.c(3891): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0:
streaming stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
I even tried
gst-launch-1.0 filesrc location=/subtitleseng.srt ! subparse ! input-selector ! sub. filesrc location=video.mp4 ! decodebin ! input-selector ! streamsynchronizer name=sub ! subtitleoverlay name=sub ! xvimagesink
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc1: Resource not found.
Additional debug info:
gstfilesrc.c(508): gst_file_src_start (): /GstPipeline:pipeline0/GstFileSrc:filesrc1:
No such file "home/usr/Downloads/video.mp4"
Setting pipeline to NULL ...
Freeing pipeline ...
Giving this error even if the file is present.
please help me solve this or directions that would help me do the same
Its working for me like this - and I indeed see the subtitles:
gst-launch-1.0 filesrc location=cartoon.mp4 ! decodebin ! video/x-raw ! videoconvert ! subtitleoverlay name=over ! autovideosink filesrc location=subs.srt ! subparse ! over.
The trick was in videoconvert before subtitleoverlay..
HTH
Okey I have a problem Iam wrote this pipeline :
gst-launch-1.0 -e location=rtsp://ip/url ! decodebin ! tee name=split split. ! queue ! autovideosink split. ! queue ! x264enc tune=zerolatency ! mp4mux ! filesink location = test.mp4
But what bothers me is filesink.After I stop pipeline I get corrupted file I know problem is that mp4mux doesn't recive on eos message and he can't finalize file but I don't know how can I solve that problem .Could somebody help me with this ?
Okey I found a solution I added sync = false after every sink element and everything is ok now
I'm having a problem trying to record audio+video from my webcam to a file. If I use videotestsrc and autoaudiosrc I get everything right (read as in I get a file with audio recorded from the webcam's mic, and test-video image), but as soon as I replace videotestsrc with v4l2src (or autovideosrc) I get Error starting streaming on device '/dev/video0'.
The command I'm using:
gst-launch-0.10 videotestsrc ! queue ! ffmpegcolorspace! theoraenc ! queue ! oggmux name=mux autoaudiosrc ! queue ! audioconvert ! vorbisenc ! queue ! mux. mux. ! queue ! filesink location = test.ogg
Why is that happening? What am I doing wrong?
EDIT:
In fact, something as simple as
gst-launch-0.10 autovideosrc ! autovideosink autoaudiosrc ! autoaudiosink
is failing with the same error (Error starting streaming on device '/dev/video0')
Replacing autovideosrc with videotestsrc gives me test image + real audio.
Replacing autoauidosrc with audiotestsrc gives me real image + test audio.
I'm starting to think that this is some kind of limitation of my webcam. Is that possible?
EDIT:
GST_DEBUG=2 log here: http://pastie.org/4755009
EDIT 2:
GST_DEBUG="v4l2*:5" (gstreamer 0.10): http://pastie.org/4810519
GST_DEBUG="v4l2*:5" (gstreamer 1.0): http://pastie.org/4810502
Please do a
gst-launch-1.0 v4l2src ! videoscale ! videoconvert ! autovideosink
Does that run? If not repeat as
GST_DEBUG="v4l2*:5" GST_DEBUG_NO_COLOR=1 gst-launch 2>debug.log ...
and check the log for errors. You also might want to run v4l-info (install v4l-conf under debian/ubuntu) and report what formats your camera supports.