Project

General

Profile

Feature #4229

URL handling in mutiplex specification not able to bind SSM adress type

Added by Utz Martin almost 3 years ago. Updated over 2 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
IPTV
Target version:
-
Start date:
2017-03-01
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)

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::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

Feature #4256: IGMP v3 support for IPTV via Source Specific MulticastRejected

Actions

History

#1

Updated by saen acro almost 3 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).
#2

Updated by Utz Martin almost 3 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.

#3

Updated by Mono Polimorph almost 3 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. ;)

#4

Updated by Utz Martin almost 3 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.:(

#5

Updated by saen acro almost 3 years ago

Recapsulation is not implemented for RTP

-f mpegts

from your pipe you do this and from http-rtp you get TS

#6

Updated by Mono Polimorph almost 3 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).

#7

Updated by Mono Polimorph almost 3 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. ;)

#8

Updated by Utz Martin almost 3 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#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. ;)

Thank you Mono Polimorph !!!!! This is very helpful.

#9

Updated by Tom Kistner over 2 years ago

Hi all, if anyone needs this urgently, I have posted a PR: https://github.com/tvheadend/tvheadend/pull/938

#10

Updated by Utz Martin over 2 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!

#11

Updated by Tom Kistner over 2 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.

#12

Updated by Jaroslav Kysela over 2 years ago

  • Status changed from New to Fixed

Applied to the main tvh repository. v4.1-2490-g2d90cd6

Also available in: Atom PDF