I need to connect to gstreamer multicast udp stream with WebRTC. I do not need any security, but web browsers require them. The connection is made only in local network, so no ICE, STUN or TURN servers are required. What is minimum possible configuration to connect from browser's WebRTC to any rtp video stream?
I have this gstreamer pipelin (if it'd help):
gst-launch-1.0 nvarguscamerasrc ! nvvidconv ! omxh264enc ! 'video/x-h264, stream-format=(string)byte-stream' ! h264parse ! rtph264pay mtu=1400 config-interval=1 pt=96 ! udpsink host=239.127.1.21 multicast-iface=192.168.137.83 port=5000
And this SDP file which works with VLC to play the stream:
v=0
o=- 1 0 IN IP4 192.168.137.1
s=-
c=IN IP4 239.127.1.21
t=0 0
a=sendonly
m=video 5000 RTP/AVP 96
a=sendonly
a=rtpmap:96 H264/90000
If I use the SDP in a browser, of course there is problem that I don't set some ICE stuff, but i really don't need them and I have no idea on how to generate them. I would rather ignore whole ICE thing and just tell browser to use some different sort of security if it is possible.
So how can I play the stream in a browser?
Thanks.
Even if you need simplest WebRTC configuration - you will need full implementation. I.e. some signaling protocol, and ICE candidate negotiation, and streams encryption. The only difference - you will always use local ICE candidates, without use STUN or TURN - it's still possible.
And I think you will have to use webrtcbin.
Related
I am using a simple RTSP server based on Ullaakut/RTSPAllTheThings, built on the top of GStreamer. It is configured to read video from the file and serve over RTSP.
The server works in general but if the viewer (that consumes the RTSP stream) is late to connect, the server gradually allocates somewhat 3 Gb of RAM, using about 50 % of CPU resources over all this time. As soon as this limit is reached, CPU usage drops to zero and there is no further memory increase. However I must stop this growth at 1 Gb or even earlier, 3 Gb is way too much.
The pipeline that the server reports on startup is:
( appsrc name=mysrc ! decodebin ! timeoverlay halignment=left valignment=top shaded-background=true font-desc="Sans 10" ! clockoverlay halignment=right valignment=top shaded-background=true font-desc="Sans 10" ! videorate ! video/x-raw,framerate=12/1 ! capsfilter ! queue ! x264enc speed-preset=superfast ! rtph264pay name=pay0 pt=96 )
I tried to add max-size-bytes=512000000 after the queue that I would believe should limit the spike to 512m but no effect before 3.3 Gb are allocated anyway. My file input is set up as here. I have set the frame rate with RTSP_FRAMERATE property. There are no any other alterations that I think should affect anything.
I need to serve 32 streams from the server. With current setup this would need 128 Gb of RAM or about!
I have switched into VLC streamer that does not have these issues. Maybe GStreamer is great somewhere else, it looks much more configurable. Anyway, VLC works for me and does not have addressed issues.
How can we capture packets of a remote system without installing wincap on the remote systems ? Is it possible to capture the packets ?
Yes if you're in the same L2 segment. Check wonderful and detailed tutorial from wireshark.
I'm using FFmpeg in my iOS application to read an RTSP (over UDP) stream. VLC offers some media information -> statistics about the stream that is being played. The number of Video Frames lost is what I'm interested in.
My question: is there a way to get these statistics (frames lost) with FFmpeg while reading from an UDP stream?
Thanks.
RTCP is used to collect statistics. Check if ffmpeg libs provide some API to access RTCP information
I have an incoming RTP stream on one computer (called, "server1") connected to another computer (called, "client1") over a LAN. However, the Ethernet header (MACDA/MACSA), IPv4 header (IPDA/IPSA), and UDP header (dstport/srcport) for all of the packets belong to another network and different computers. Furthermore, the client computer did not request or initiate the stream. It is "just there"! :)
I am not interested in controlling (stopping, starting, track jumping, etc.) the stream. I just want to see and hear it in a VLC client.
I have complete control over the packets, so that I can change all of the header info as it leaves the server.
How can I modify the packets, so that VLC will play them? I can point VLC at my server, and I can mangle the packets, so they appear to have been sourced by the server and destined for the client. But, I do not know the destination port opened by VLC on the client. What am I missing?
Thanks!
I may not have the best answer, but here's a little something that might help...
"I was trying vlc player and I says, Sdp required, cannot play rtp with dynamic payload type. Is it possible to play rtp with dynamic payload type by other player, or somehow create sdp protocol using libjitsi. Thanks a lot."
Reply:
"You need an SDP description.
I found on stackoverflow a minimal SDP description. Minimum SDP for making a H264 RTP stream?.
You can try to replace the IP address, port number and payload type by the ones you’re using, maybe that’ll work."
To explain what I would like to get, here's an example.
Let's say, we have a PC with one NIC. It has single IP address 172.16.0.1.
Using VLC, we start a udp stream to 172.16.0.1:1234, then launch another copy of VLC and connect to udp://#172.16.0.1:1234. Now we'll see our video streaming.
If you run sniffer, you will see packets from 172.16.0.1:some_random_port to 172.16.0.1:1234 on loopback. There's no trafic on our NIC.
What I want to do is to stream and receive udp in the same computer, like VLC does it. But the main problem is that pcap can only pcap_open() a real device, it can't work with loopback.
Is it possible to solve that problem?
P.S. I'm using Windows and WinPcap, unlike Linux version, it can send packets.
If you just want to send and receive UDP packets, I would suggest just using regular Winsock sockets, just as you'd use regular sockets on UN*X; using WinPcap requires that you re-implement IP and UDP, and won't let you send to another socket on the same machine under Windows (or on at least some versions of UN*X, either).
If you want to watch the traffic you're sending, unfortunately WinPcap won't help, as it relies on packets being sent out and received from NDIS (its driver plugs into NDIS), and that doesn't happen for packets sent from one socket on a machine to another socket on the same machine.
(Note, BTW, that libpcap can send packets on Linux and *BSD and Mac OS X and Solaris and Digital/Tru64 UNIX, for example, and has been able to do so for several years; older versions of libpcap didn't support it, but the versions available for the past few years can. However, as per my first paragraph, it would not make sense to use libpcap to send and receive regular UDP packets on those OSes, just as it makes no sense to use WinPcap for that purpose on Windows.)