UDP IPTV to RTSP proxy is a lightweight GNU/Linux daemon which, being installed on a LAN router, provides on-demand access to UDP multicast streams via RTSP and unicast RTP protocols.
Since version 0.2 the conventional HTTP "continuous download" streaming method is supported.
The server itself does not support streaming of any files, it only can receive incoming multicast streams and retransmit them to interested clients.
The main purpose of the software is to provide simple IPTV service to small office or home ethernet and/or Wi-Fi LANs where upgrading network to handle multicast correctly is not an option.
The software is not intended to handle large scale installations and service clients you don't trust (like public Internet).
You can get the latest development version from SVN repository. Please note that this is a development version and as a free bonus you can expect more bugs than usually.
Releases considered stable are in Downloads section.
Run server with
$ ./iptv2rtsp-proxy -f -s <YOUR_IP> -l <LISTEN_PORT>
$ ./iptv2rtsp-proxy -f -s 192.168.10.10 -l 5555
Connect by opening an url in your media player:
There are essentially no signaling between server and client, almost no control over TCP behavior, all this makes error handling and recovery extremely difficult.
If server detects that it can not send data to the client in more or less reliable way, the connection will be closed.
The server has fixed-sized buffer for streamed data, this buffer will overflow quickly if client can not receive (or decode) data. Overflowed buffer can make streaming data severely damaged, thus preventing client to decode it, making the issue yet worse leaving no chance to recover.
Some clients handle network continuous downloads as files, this is wrong. See http://en.wikipedia.org/wiki/Push%E2%80%93pull_strategy for details.
In short: server sends data by servers' clock, there's no way to change this. Correct behavior for client would be to receive and process all data same moment it's available. Alternative to this is receiving data by clients' clock. Without proper synchronization (and there're usually none) it is possible socket buffers to overflow (if send rate is higher than receive or stream is damaged) effectively stalling all transmission for this client.
The software currently implements only a very limited subset of features described in these documents:
The goal is not to implement these completely, only parts that are required by popular software to function properly.
RTSP protocol supports PAUSE requests, but this server supposed to work with "live" streams only and does not have any PVR functionality. While it's possible to "pause" streaming, it's impossible to resume from the point it was paused. After resuming, audio/video decoders will act as if there were a big packet loss.
It is possible to implement FEC schemes for RTP, but it looks like there no clients supporting FEC now.
|VLC Media Player||1.0, 2.0||OK||N/A (1)|
|Infomir MAG250 IPTV STB||0.2.12||OK||?|
|FFmpeg's ffplay||0.5.9||OK||No (2)|
|MPlayer||1.1||not ok||N/A (1)|
|Elecard RTSP NetSource(3)||5.0||OK||OK|