I'm planning on connecting a camera to a Raspberry Pi and streaming video over 4G internet to control a quad copter. I will be using ffmpeg to stream the video, so far it looks like you need to use ffserver to do this. The problem is most 4G providers (I use AT&T) block all ports from hosting. Would something like FreedomPop (http://www.freedompop.com) work? Can I stream with ffmpeg as the client? What kind of latency can I expect?
Use rtmp or rtsp uni cast protocols for the lowest latency.
You could do ffmpeg server but may find something like wowza on amazon easier.
At best your latency will be a few seconds.
I have used freedom pop with my raspberry pi and a ddns address to connect to without problems.
Related
Hi everyone，most of time I had seen the method that convert ip camera source(rtsp) to http(hls)，but no one try convert hls to rtsp。I have hls test url：
https://multiplatform-f.akamaihd.net/i/multi/will/bunny/big_buck_bunny_,640x360_400,640x360_700,640x360_1000,950x540_1500,.f4v.csmil/master.m3u8
and Use the command to convert hls to rtsp:
ffmpeg -i https://multiplatform-f.akamaihd.net/i/multi/will/bunny/big_buck_bunny_,640x360_400,640x360_700,640x360_1000,950x540_1500,.f4v.csmil/master.m3u8 -f rtsp rtsp://localhost:8554/test
but not work,can someone help me?Thank you very much!
You need a live streaming server (like Wowza SE) to serve the live stream to other clients (players).
Also when publishing the live stream to the streaming server some authentication parameters are required, like rtsp://user:password#server:[post]/app/stream .
You can check the WordPress - Broadcast Live Video plugin, that handles various protocols, streaming methods and FFmpeg transcoding (if you have the necessary streaming server).
I have a use case where I need to restream an RTSP URL.
For all the below cases, Live555 is built locally by cloning the source.
For all the below cases, required ports are opened for RTSP in respective servers.
First I set up a file to be streamed using Live555MediaServer. This is in an AWS instance (AWS1).
./Live555MediaServer ashi.webm gives
rtsp://public_IP_of_instance:8554/ashi.web
I check whether an incoming stream is working or not, by trying to play it in VLC player. This incoming stream is working fine and playing well on VLC.
Now, to restream, I tried Live555ProxyServer. Now incoming stream from AWS1 is restreamed to another URL by running Live555ProxyServer on my Mac.
./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web gives,
rtsp://localhost:8554/ProxyStream
This URL is also playable in VLC.
Now I setup another AWS instance (AWS2) and run ProxyServer on it, listening to AWS1.
That is,
./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web gives,
rtsp://public_IP_of_instance_two:8554/ProxyStream
This URL is not playable.
I tried using -t flag for TCP instead of UDP. I tried checking the incoming RTSP stream with ffprobe and the stream is showing all the required details.
What could be the possible reason? What is the missing piece in this pipeline? Do we've great industry-grade open source RTSP servers?
EDIT:
I don't know what is exactly happened, but using VLC as the client to check the stream was the problem. I moved to ffmpeg and tried to write it to a file using
ffmpeg -i rtsp://public_IP_of_instance_two:8554/proxyStream -acodec copy -vcodec copy abc.webm
So the stream from ProxyServer is fine.
The lead to the change of client was the repeated warning from live555ProxyServer about outdated firmware explained here.
I'm currently using VLC Version 3.0.3 Vetinari (Intel 64bit) in Mac which is the latest version. Maybe VLC is using an old version of Live555 internally.
I have a RTSP server that provides access to a multicast stream. I can play it fine in VLC and various other players, however in ffmpeg / ffplay I get no data back.
After investigation this seems to be caused by the RTSP SETUP listing only unicast as a transport method.
If I use:
ffplay -rtsp_transport udp_multicast rtsp://<blah>
then it works fine.
How does ffmpeg decide which transport methods to put into its SETUP call? Is it perhaps some part of the SDP returned by the DESCRIBE call? Ideally I'd like to find a way to allow ffplay to play the multicast stream without the need to force the transport mode.
Problem Scenario:
I am trying to capture multiple multicast cameras on a network with FFmpeg. Upon receiving the streams, I find that each FFmpeg instance running is receiving and decoding the packets destined for the other instances. This causes the video of each instance to flicker between the correct image and the images of all the other cameras. Each camera uses the same destination UDP port and I believe this is the reason its happening.
Example
Process 1
ffmpeg -rtsp_transport udp_multicast -i "rtsp://192.168.1.1/stream1m" test1.mp4
Process 2
ffmpeg -rtsp_transport udp_multicast -i "rtsp://192.168.1.2/stream1m" test2.mp4
Expected Output
Each MP4 contains only one, non-interrupted stream
Actual Output
As described above
I've trawled through FFmpeg's docs, as well as extensive 'googling' however I can only see a way to filter incoming packets when using an rtp:// or udp:// input. This isn't possible in this application as I want to use RTSP for the SDP it provides.
Any help is greatly appreciated!
I got this to work using different multicast IPs and ports. The trick is the ports - they have to be different on the stream side, even if the IPs are different.
This seems to be a problem with ffmpeg.
I'm very new with ffmpeg. Consider the following case:
I have several onvif ip camera connected to the network with an IIS server inside it. I'd like to allow client to streaming to any of ip camera inside the network but it must through the IIS server.
So basically each of ip camera will stream to IIS server in single stream and IIS server will re-distribute to many client who request it. My question is how to setup iis server to works with this scenario? And an example of ffmpeg command line to read from rtsp ip camera and send it the iis server which will re-distribute it to client.
You can use HTTP live streaming for this scenario, either HLS or DASH. HTTP streaming adds some latency so you need to do a bit of research on how to tweak the encoding parameters for low-latency.
The basic idea is that you need to segment the incoming stream and make those segments and playlist/manifest available via your existing web server infrastructure.
Example for FFmpeg and HLS:
ffmpeg -i rtsp://input_stream.sdp -c:v libx264 -r 25 -g 25 -c:a libfdk_aac -hls_time 1 -hls_list_size 4 -hls_wrap 8 /path/to/webroot/live/playlist.m3u8
On the client you will then use the URL http://domain.com/live/playlist.m3u8. HLS in not supported natively on all devices so get a web player like JWplayer or clappr. The client needs 3 segments to start the playback.
FFmpeg HLS
For DASH the idea is similar but you also need to use MP4Box.