Feature #4229
URL handling in mutiplex specification not able to bind SSM adress type
100%
Description
I observed that TVheadend is not able to handle URLs of SSM (source specific multicast)in ist multiplex description.
For SSM the URL is of the type rtp://[email protected]:10000.
Notice, this URL example adresses an IPTV stream which is only available if you are connected to the Network of German Telekom under an appropriate contract. Unfortunately TVheadend binds only rtp:\\232.0.20.35:1000 of the complete URL and neglects the source node part 87.141.215.251.
If the routers IGMP implementation is standard conform, it will fail in connecting to any source node of the requested stream. A fix would be very helpful!
Subtasks
History
Updated by saen acro almost 8 years ago
HTTP commands -------------- udpxy responds to HTTP (GET) commands to receive data from a dedicated multicast group and forward it to the initiating (HTTP) connection. The command to relay traffic is in the format as below: http://address:port/cmd/mgroup_address[SEP]mgroup_port/ [SEP] ::= :|%|~|+|-|^ i.e: http://ip:port/cmd/mgroup_address:mgroup_port/ http://ip:port/cmd/mgroup_address%mgroup_port/ http://ip:port/cmd/mgroup_address~mgroup_port/ ...... http://ip:port/cmd/mgroup_address^mgroup_port/ are acceptable and should all work in the same manner. cmd ::= udp | rtp where ip and port match the listening address/port combination of udpxy, and mgroup_address:mgroup_port identify the multicast group to subscribe to. Using 'udp' command will instruct udpxy to probe for known types of payload (such as MPEG-TS and RTP over MPEG-TS); using 'rtp' makes udpxy assume RTP over MPEG-TS payload, thus skipping the probes. udpxy will start a 'client' process for each new relay request as long as their number would not exceed a pre-set maximum (see usage summary).
Updated by Utz Martin almost 8 years ago
saen acro wrote:
[...]
With the command http://87.141.215.251/rtp/232.0.20.234:10000 I cannot access the stream. The log of the scan process is
2017-02-14 18:01:53.026 subscription: 0010: "scan" subscribing to mux "TEST", weight: 6, adapter: "IPTV", network: "Telekom_Entertain_TV", service: "Raw PID Subscription"
2017-02-14 18:02:08.025 mpegts: TEST in Telekom_Entertain_TV - scan no data, failed
2017-02-14 18:02:08.025 subscription: 0010: "scan" unsubscribing
The network sniffer observes no IGMP traffic. No change when using udp instead of rtp!
Using the pipe
pipe:///usr/bin/ffmpeg -loglevel fatal -i rtp://232.0.20.234:10000?sources=87.141.215.251 -vcodec copy -acodec copy -acodec copy -f mpegts pipe:1
I can access the stream.
Updated by Mono Polimorph almost 8 years ago
Utz Martin wrote:
saen acro wrote:
[...]
[...]
Hi,
You need IGMPv3 support for select the source address. IGMPv2 not supports this function.
I suspect that TVHeadend and UDPXY only support IGMPv2. Then you're out of luck!
Request to incorporate IGMPv3 support pointing to some source code example.
Updated by Utz Martin almost 8 years ago
Mono Polimorph wrote:
Utz Martin wrote:
saen acro wrote:
[...]
[...]
Hi,
You need IGMPv3 support for select the source address. IGMPv2 not supports this function.
I suspect that TVHeadend and UDPXY only support IGMPv2. Then you're out of luck!Request to incorporate IGMPv3 support pointing to some source code example.
IGMPv3 support is available at my router and at my host. I can access the stream from ffmpeg! I don't understand why TVheadend requires more than an appropriate (full) adress binding.
My stupid imagination is that ffmpeg und TVheadend should use the same Linux system calls and should behave similar.
Sorry, I am really not very familiar whith such software issues.
Updated by saen acro almost 8 years ago
Recapsulation is not implemented for RTP
-f mpegts
from your pipe you do this and from http-rtp you get TS
Updated by Mono Polimorph almost 8 years ago
Utz Martin wrote:
Mono Polimorph wrote:
You need IGMPv3 support for select the source address. IGMPv2 not supports this function.
I suspect that TVHeadend and UDPXY only support IGMPv2. Then you're out of luck!IGMPv3 support is available at my router and at my host. I can access the stream from ffmpeg! I don't understand why TVheadend requires more than an appropriate (full) adress binding.
Hi,
You need IGMPv3 support because IGMPv2!=IGMPv3. Even if your network supports IGMPv3, the calls for v2 and v3 are different. So, if your OS supports IGMPv3 multicast group joining and you like to use it, then your software needs to do the correct calls.
At time TVheadend doesn't support IGMPv3 (just like several other software).
Updated by Mono Polimorph almost 8 years ago
Mono Polimorph wrote:
Request to incorporate IGMPv3 support pointing to some source code example.
Hi,
As example, you can use the code from FFMPEG (that has support for IGMPv3).
Here the function "udp_set_multicast_sources()" that implements the joining to a multicast group with IGMPv3 calls:
http://github.com/FFmpeg/FFmpeg/blob/415f907ce8dcca87c9e7cfdc954b92df399d3d80/libavformat/udp.c#L280
And as you can see here:
http://github.com/FFmpeg/FFmpeg/blob/415f907ce8dcca87c9e7cfdc954b92df399d3d80/libavformat/udp.c#L881
this funtion is called when the "source" parameter is attached to the multicast address.
If not, then the function for IGMPv2 is called: "udp_join_multicast_group()".
I hope this helps if someone likes to implement it in TVheadend.
Updated by Utz Martin almost 8 years ago
Mono Polimorph wrote:
Mono Polimorph wrote:
Request to incorporate IGMPv3 support pointing to some source code example.
Hi,
As example, you can use the code from FFMPEG (that has support for IGMPv3).
Here the function "udp_set_multicast_sources()" that implements the joining to a multicast group with IGMPv3 calls:
http://github.com/FFmpeg/FFmpeg/blob/415f907ce8dcca87c9e7cfdc954b92df399d3d80/libavformat/udp.c#L280And as you can see here:
http://github.com/FFmpeg/FFmpeg/blob/415f907ce8dcca87c9e7cfdc954b92df399d3d80/libavformat/udp.c#L881
this funtion is called when the "source" parameter is attached to the multicast address.
If not, then the function for IGMPv2 is called: "udp_join_multicast_group()".I hope this helps if someone likes to implement it in TVheadend.
Thank you Mono Polimorph !!!!! This is very helpful.
Updated by Tom Kistner over 7 years ago
Hi all, if anyone needs this urgently, I have posted a PR: https://github.com/tvheadend/tvheadend/pull/938
Updated by Utz Martin over 7 years ago
Tom Kistner wrote:
Hi all, if anyone needs this urgently, I have posted a PR: https://github.com/tvheadend/tvheadend/pull/938
Great!!! Thank you very much, Tom!
Updated by Tom Kistner over 7 years ago
You're welcome. NB: If you use this on a system with several interfaces, you might have to specify the interface to bind to in the advanced mux options.
Updated by Jaroslav Kysela over 7 years ago
- Status changed from New to Fixed
Applied to the main tvh repository. v4.1-2490-g2d90cd6