Force FFmpeg output only TCP as RTSP proxy - ffmpeg

There are lot of topics around about RTSP and FFmpeg, but in none of them I have found how to force FFmpeg outputing a TCP RTSP instead of default UDP.
I know how to force the input to TCP, with -rtsp_transport tcp option, but I cannot find how to force the output.
Someone solved suggesting to use avformat_write_header(ofmt_ctx, &options); but did not say nothing mode about that, and this is too generic info.
Thanks a lot for help!
I am using this string, it connect to first source by TCP, but FFmpeg is not opening a TCP listenng port. It does open 4 UDP ports with different values (far from what I have specified for tcp), anyway I have tried to connect to them too with VLC, but no one works.
ffmpeg -re -i rtsp://adminassord#rtsp.source:554/live.sdp -rtsp_transport tcp -f rtsp -rtsp_transport tcp rtsp:/192.168.0.100:50041/

I've solved it using https://github.com/aler9/rtsp-simple-server
in the end you may get a TCP stream from the rtsp://serverIP:port/proxied
it seems there are no ways to tell ffmpeg to stream on TCP only

Related

ffmpeg, send camera mjpeg stream over TCP

I am using a Zavio F-210A camera, and I am able to get its video properly via
http://192.168.X.X/video.mjpg
also, if I use ffmpeg command
ffplay -i "http://192.168.X.X/video.mjpg"
I am able to get the video stream. However, what I would like to to is to create a TCP/UDP socket with same content to another different IP address (lets say 192.168.X.Y). I have tried with
ffmpeg -i "http://192.168.2.91/video.mjpg" -c copy -f mpjpeg "tcp://127.0.0.1:1234?listen"
and when opening with
ffplay tcp://127.0.0.1:1234
It gets one single frame and then it shuts down saying
[mpjpeg # 0x55c36ad25900] Unexpected Content-Type : audio/basic
http://192.168.X.X/video.mjpg: Invalid data found when processing input
my two questions are:
How do I get the stream via ffmpeg and not a single frame with error?
How could I send it to a different IP address?
Thank you

Using ffserver to do UDP multicast streaming

Here's the deal. I'm working with IPTV hardware and I need to output a bunch of demo streams. These are MPEG2 transport stream that need to be straight up UDP Multicast streams. I have an ffmpeg command that works great:
ffmpeg -re -i /Volumes/Data/DemoVideos/GRAILrpsp.ts -acodec copy -vcodec copy -f mpegts udp://239.192.1.82:12000[ttl=1,buffer_size=2097157]
What I would like to do is convert this into an ffserver config file instead of having to start a whole bunch of ffmpeg streams and then figuring out how to get them to loop. I'm sure I can do it with the right scripting but what a pain, isn't that what ffserver is for? But I can't find any documentation on doing UDP streaming using ffserver. You can set a multicast address and port but it goes to RTP which this hardware isn't designed for. Any help would be greatly appreciated.
At the time of this post, according to the ffserver Documentation it doesn't support MPEG-TS directly in UDP:
ffserver receives prerecorded files or FFM streams from some ffmpeginstance as input, then streams them over RTP/RTSP/HTTP.

Setting up rtsp stream on Windows

I am trying to set up an rtsp stream that can be accessed from an application. I have been experimenting with ffmpeg to realize that. I have succeded as far as I was able to stream from ffmpeg to ffplay but I could not load the stream in vlc for example. Here are the calls that I did from two different shells on the same machine:
ffmpeg.exe -y -loop 1 -r 24 -i test_1.jpg -vcodec libx264 -tune stillimage -f rtsp rtsp://127.0.0.1:1234/stream.sdp
ffplay.exe -rtsp_flags listen rtsp://127.0.0.1:1234/stream.sdp
Can anybody explain to me what I would have to do to load the stream as a network stream using vlc? Any help is appreciated.
I have done this before and I'm not sure what was wrong with rtsp output of ffmpeg. But what i can say right now is please consider using Live555 library if you have any streaming scenario. cause the ffmpeg code (for rtp muxer) is not good and it is buggy. ffmpeg has another solution for streaming server which is called ffserver which prepare ffmpeg pipe for vlc or another third-party application. and that's bad written and buggy too (libav group -another fork of libav* libraries) never used ffserver code and in not sure if they have any plan to consider ffserver as their solution. they have ffplay(avplay), ffmpeg(avconv) and ffprobe but not ffserver.
If you want to use Live555 which really easy, you have to just go to their website (www.live555.com) download the source code and build MediaServer application (It is in 'MediaServer' folder). if you read the code's documentation, I'm sure you will have not any problem.It's a basic rtsp server to stream any (supported) accessible file on your HDD via rtsp url of your server.
if you have any problem with code just comment here, so I can help you more with live555.

ffmpeg restream rtsp to mjpeg

I have a few IP cameras that stream 720 X264 video over rtsp. The streams are really unreliable when viewing on Android. They also fail if more then 2 connections are made.
I have a ubuntu server that I can use to connect and restream as mjpeg or something else. There are tons of different commands out there but they all seem to involve transcoding the video.
How can I simply restream the live rtsp feed as a mjpeg without doing anything to the video itself? Theres no audio so no worries there.
It seems that recently I did something similar. I have added following section to the /etc/ffserver.conf file:
<Feed monitoring1.ffm>
File /tmp/monitoring1.ffm
FileMaxSize 50M
ACL allow 127.0.0.1
</Feed>
<Stream monitoring1.mjpg>
Feed monitoring1.ffm
Format mpjpeg
VideoCodec mjpeg
VideoFrameRate 22
VideoBufferSize 80
VideoSize 720x264
NoAudio
</Stream>
After that started server with command:
ffserver
and run streaming with command:
ffmpeg -i "rtsp://<ip_camera>:554/user=admin&password=&channel=1&stream=0.sdp" http://localhost:8090/monitoring1.ffm
Tune the ip camera url for your purposes. Now you can access the mjpeg stream by accessing following address with your browser/player:
http://localhost:8090/monitoring1.mjpg
Works fine for me and hope it solves your problem.

Video streaming fails over rtp protocol

Video streaming between Unix Server (ffmpeg) and Windows client (vlc) completed without errors.
Server side:
ffmpeg -f v4l2 -r 25 -i /dev/video0 http://192.168.1.114:27018/feed1.ffm
Client side:
vlc player: Media -> Open Network Stream: http://192.168.1.114:27018/test.swf
However, video streaming has approximately 10 s. delay. For this reason, I tried using rtp instead http, but without result. Specifically, on server side I run:
ffmpeg -f v4l2 -r 25 -i /dev/video0 rtp://192.168.1.114:27018/feed1.ffm
After the stream begun, on client side I typed: rtp://#:27018 but it doesn't respond.
What I am missing? Is there any other way I could avoid delay?
Short (incomplete) solution for the problem with the RTP stream:
Setup FFMPEG with the command line:
ffmpeg -f v4l2 -r 25 -i /dev/video0 rtp://<client_ip>:<client_port>
where <client_ip> and <client_port> need to be replaced with the client's IP address and port number, respectively.
Description of the problem with the RTP stream and the solution:
Generally, when setting up an HTTP server (in this case, namely HTTP multimedia server), on the server's side, the local port and the local IP address that the server needs to listen on are specified. So when you set up FFMPEG to stream on http://192.168.1.114:27018/, it probably means that FFMPEG (the server) will listen on its one interface that has the IP 192.168.1.114 and on the port 27018. Then the client needs to connect to http://192.168.1.114:27018 to get the streams.
However, when setting up an RTP FFMPEG server, the client address(es) and port(s) are specified on the server's side, meaning (inaccurately) that the server sends the packets to the desired addresses and the clients need to listen on their ports if they want the available streams. So the FFMPEG server needs to be setup with the URL rtp://<client_ip>:<client_port> and not the URL rtp://<server_ip>:<server_port>, for the <client_ip> to be able to access the stream on his local port <client_port>.
For more info on the FFMPEG's RTP URL format and a starting point for some intriguing concepts in RTP streaming (like multicasting), visit here.

Resources