I'm trying to stream with RTP and the client says that there is allot of packet drops.
Server pipeline:
gst-launch videotestsrc ! x264enc ! rtph264pay ! udpsink host=192.168.1.16 port=5000
Client pipeline:
gst-launch udpsrc uri=udp://192.168.1.16:5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)\"Z01AFeygoP2AiAAAAwALuaygAHixbLA\\=\\,aOvssg\\=\\=\", payload=(int)96, ssrc=(uint)1645090291, clock-base=(uint)1778021115, seqnum-base=(uint)28353" ! rtph264depay ! queue ! ffdec_h264 ! autovideosink
I can see the video on the client, but very slowly with a lot of packet drops. The error on the client side:
from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage:
A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2875): 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
If someone could tell me what am I doing wrong here, that would be great!
Instead of using "autovideosink" try "xvimagesink sync=false".
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.
Let's say I've got a simple RTP video server:
ximagesrc ! video/x-raw,framerate=30/1 ! videoscale ! videoconvert ! x264enc tune=zerolatency bitrate=500 speed-preset=slow ! rtph264pay ! udpsink host=127.0.0.1 port=5000
And I'm receiving it just fine:
udpsrc port=5000 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! decodebin ! videoconvert ! autovideosink
But if my server was sending H265 (or any other format), I'd have to use another pipeline. Considering there are a ton of possible formats, that is definitely something I'd like to avoid. Is there any way to get my video decoded from any format?
No. RTP streams are supposed to be initiated by SDP and RTSP control protocols which will tell you what kind of stream you are dealing with. If you want self describing media, perhaps try looking at MPEG-TS instead.
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 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
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