Streaming video sourse using http and GStreamer

0
votes

I have a problem with streaming videosource over HTTP using gstreamer. Windows OS.

Send command (server side) looks like:

gst-launch-1.0 -v filesrc location=d:/TestVideos/costarica.mp4 ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=192.168.1.162 port=6001

And command on client side:

gst-launch-1.0 -v tcpclientsrc host=192.168.1.162 port=6001 ! gdpdepay ! rtph264depay ! h264parse ! decodebin ! autovideosink sync=false

Pipeline is starting, but I can't see opened display window on my screen. It would be great if anyone have solution. Thank you.

1
httpvideovideo-streaminggstreamer
There is not HTTP involved in this example. Also using gdppay and rtppay is kind of redundant. Either you want a RTP stream or a GDP stream. If you only want to receive via GStreamer remove RTP altogether. h264parse also has a config-interval property - if you dont set this too rtppay may never get a single SPS/PPS it could insert.. – Florian Zwoch
Thanks for reply! I removed rtph264pay config-interval=1 pt=96 and gdppay and it's not working. What kind of gst options I need to stream over http mp4 file? Rtp over udp works great. – JDo
Well removing RTP and GDP is not a good option - then you don't have any real format that is nice for network transmission. You should decide on either of those.. not both or none. But you need SPS and PPS transmitted explicitly inband (as MP4 transmits this data out of band) – Florian Zwoch
So what about this string - location=d:/TestVideos/costarica.mp4 ! decodebin ! x264enc ! rtph264pay config-interval=1 ! tcpserversink host=192.168.1.162 port=9001 on the server side. But I also can't recieve mediadata. – JDo
Hmm you are right - maybe that's why you used GDP in the first pipeline. RTP is supposed to be send over UDP. This helps identifying packets sizes which is not the case in TCP - because it is considered a continuous stream. So maybe the original pipeline works if you add config-interval=-1 to the h264parse? – Florian Zwoch

1 Answers

0
votes

The h264 codec will not display the video when it cannot reconstruct the video from received packets. Since you are using, TCP, the chances of losing packets are less. But there might be a latency introduced due to retries by TCP. I suggest the following :

Insert an element videorate that can limit the rate at which video is transferred. Also use queue at the receiver side, to accomodate for latency.