I'm really running out of ideas. Here is my problem: I need to stream on demand mp4 (H264) through the network. I'm new with gstreamer and after lot of tries with versions > 1.0 I decided to use 0.10 because seems to be most promising so far.
Command below works perfect ( I see window with my movie )
gst-launch filesrc location=/home/zuko/sintel_trailer-368p.mp4 ! decodebin2 name=dec ! queue ! ffmpegcolorspace ! autovideosink dec. ! queue ! audioconvert ! audioresample ! autoaudiosink
Now I'm trying to build TCP stream using commands (so far on localhost only):
Server side:
gst-launch filesrc location=/home/zuko/sintel_trailer-368p.mp4 ! decodebin2 name=dec ! tcpserversink host=127.0.0.1 port=5000
Client side:
gst-launch tcpclientsrc host=127.0.0.1 port=5000 ! decodebin2 name=dec ! queue ! ffmpegcolorspace ! autovideosink dec. ! queue ! audioconvert ! audioresample ! autoaudiosink
But response from the "client side" command is following:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin2:dec/GstTypeFindElement:typefind: Could not determine type of stream.
Additional debug info:
gsttypefindelement.c(813): gst_type_find_element_chain_do_typefinding (): /GstPipeline:pipeline0/GstDecodeBin2:dec/GstTypeFindElement:typefind
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
What is missing, or what I'm doing wrong?
I'm testing on: VirtualBox 4.3.12 with Ubuntu 14.04, kernel 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Full error with (GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:3 ) attached here:
https://app.box.com/s/4ntyk6am2ibg0pohtg9h
First off, using 0.10 is an absolutely bad idea, you should really stick to 1.0, for which you will have community support.
Second, to your problem itself, you are trying to stream the decoded stream over the network ("decodebin2 ! tcpserversink") and to decode it again on the other side ("tcpclientsrc ! decodebin2"). Not only is it very wrong with respect to bandwidth usage, it also straight up won't work.
I'll advise you to have a look at the rtp plugins provided by gstreamer.
Using gstreamer 1.0 the server side can share h264 streams with:
gst-launch-1.0 filesrc location="C:\\Videos\\videotestsrc.avi" ! decodebin ! x264enc ! mpegtsmux ! queue ! tcpserversink host=127.0.0.1 port=8080
While the client side receives with:
gst-launch-1.0 tcpclientsrc host=127.0.0.1 port=8080 ! decodebin ! videoconvert ! autovideosink sync=false
Alternatively, the client could be simulated with VLC through:
Media >> Open Network Stream >> tcp://127.0.0.1:8080 >> Play
Related
I have a third party application that reads data from a thermal camera and generates a RTP stream to a given UDP source. I am trying to wrap this RTP into a RTSP stream but I am running into problems...
The third party application basically runs gstreamer with this command
appsrc format=GST_FORMAT_TIME is-live=true block=true caps=video/x-raw,width=640,height=480,format=GRAY8,clock-rate=90000,framerate=10/1 ! openjpegenc ! rtpj2kpay ! udpsink host=127.0.0.1 port=3000
Using the command below I can visualize the stream on my machine
gst-launch-1.0 udpsrc port=3000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG2000, sampling=(string)GRAYSCALE, width=(int)640, height=(int)480, payload=(int)96" ! queue ! rtpj2kdepay ! openjpegdec ! videoconvert ! xvimagesink
However when trying to use the default RTP to RTSP application example using https://github.com/freedesktop/gstreamer-gst-rtsp-server/blob/master/examples/test-launch.c to just forward it with a RTSP container the connection fails with VLC. Command below:
./rtp-src-to-rtsp '( udpsrc port=3000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG2000, sampling=(string)GRAYSCALE, width=(int)640, height=(int)480, payload=(int)96" ! queue ! rtpj2kdepay ! rtpj2kpay )'
Any light on what I am doing wrong? VLC gives only a non-descriptive error
live555 error: Nothing to play for rtsp://{IP}:{PORT}/test
It might be a lack of support of J2K in VLC (I'm using revision 3.0.8-0).
Simulating your source with:
gst-launch-1.0 videotestsrc ! video/x-raw,width=640,height=480,framerate=10/1,format=GRAY8 ! openjpegenc ! rtpj2kpay ! udpsink host=127.0.0.1 port=3000
and relaying as RSTP with:
./test-launch "udpsrc port=3000 auto-multicast=0 ! application/x-rtp,encoding-name=JPEG2000,sampling=GRAYSCALE ! queue ! rtpj2kdepay ! image/x-jpc ! jpeg2000parse ! rtpj2kpay name=pay0 "
works on Linux with X using:
gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/test ! application/x-rtp, encoding-name=JPEG2000,sampling=GRAYSCALE ! rtpj2kdepay ! jpeg2000parse ! openjpegdec ! videoconvert ! xvimagesink -v
Though, I haven't been able to receive with VLC, nor able to make a correct J2K/RTP SDP for VLC nor ffmpeg. Someone better skilled may further advise.
I am trying to stream video using TCP. Following is the server pipeline:
gst-launch filesrc location=<movie>.mkv ! decodebin ! ffenc_mpeg4 bitrate=5000000 ! rtpmp4vpay mtu=1400 pt=96 ssrc=0 timestamp-offset=0 seqnum-offset=0 send-config=true ! tcpserversink host=0.0.0.0 port=5000
And the client pipeline is:
gst-launch tcpclientsrc host=192.168.1.93 port=5000 ! capsfilter caps="application/x-rtp, media=(string)video, clock-rate=(int)2147483647, encoding-name=(string)MP4V-ES, profile-level-id=(string)1, config=(string)000001b001000001b58913000001000000012000c48d88007d0a041e1463000001b24c61766335322e3132332e30, payload=(int)96, ssrc=(uint)298758266, clock-base=(uint)3097828288, seqnum-base=(uint)63478" ! rtpmp4vdepay ! ffdec_mpeg4 ! autovideosink
I had to include a capsfilter between tcpclientsrc and rtpmp4vdepay. This does not seem to be required if I use the udpsrc however. (I cant seem to get the multicast based streaming to work through my BT router). When started the client starts to play the video, but it is garbage and I can see following warning in the client side.
WARNING: from element /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0: Could not decode stream.
Additional debug info:
gstbasertpdepayload.c(387): gst_base_rtp_depayload_chain (): /GstPipeline:pipeline0/GstRtpMP4VDepay:rtpmp4vdepay0:
Received invalid RTP payload, dropping
This warning is emitted continuously.
What am I doing wrong here?
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.
Here is what I'm trying:
gst-launch -v udpsrc port=1234 ! fakesink dump=1
I test with:
gst-launch -v audiotestsrc ! udpsink host=127.0.0.1 port=1234
And everything works fine, I can see the packages arriving from the audiotestsrc
Now lets test with the webcam source:
gst-launch -v v4l2src device=/dev/video0 ! queue ! videoscale method=1 ! "video/x-raw-yuv,width=320,height=240" ! queue ! videorate ! "video/x-raw-yuv,framerate=(fraction)15/1" ! queue ! udpsink host=127.0.0.1 port=1234
And nothing happens, no package appears in the dump.
Here is a logdump of what verbose shows in the server.
Does anyone have a clue on this?
Try these (You may have to install gstreamer-ugly plugins for this one)
UDP streaming from Webcam (stream over the network)
gst-launch v4l2src device=/dev/video0 ! 'video/x-raw-yuv,width=640,height=480' ! x264enc pass=qual quantizer=20 tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 port=1234
UDP Streaming received from webcam (receive over the network)
gst-launch udpsrc port=1234 ! "application/x-rtp, payload=127" ! rtph264depay ! ffdec_h264 ! xvimagesink sync=false
Update
To determine the payload at the streaming end simply use verbose option with gst-launch -v ...
Maybe packets are too large for udp? They are limited to 64K. Try resizing frames to really small size to check if this is the reason. If so, you may be interested in some compression and payloaders/depayloaders (gst-inspect | grep pay).
gstreamer1-1.16.0-1.fc30
gst-launch-1.0 -v filesrc location=/.../.../.../sample-mp4-file.mp4 ! qtdemux ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink port=8888 host=127.0.0.1
https://en.wikipedia.org/wiki/RTP_audio_video_profile
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.