Bug #5866
Multicast from multiple sources
0%
Description
Some networks may provide two sources for the same multicast address, see here:
```
21:41:26.577351 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.577930 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.577960 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.577975 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.578745 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.579667 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.579702 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.579708 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.580487 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
```
This currently results in continuity counter errors and inability to watch the channel:
```
Mar 31 21:33:15 speedy tvheadend31043: TS: ...: H264 #256 Continuity counter error (total 88744) #257 Continuity counter error (total 7560)
Mar 31 21:33:15 speedy tvheadend[31043]: TS: ...: MPEG2AUDIO
Mar 31 21:33:15 speedy tvheadend31043: TS: ...: MPEG2AUDIO #258 Continuity counter error (total 7565) #400 Continuity counter error (total 11127)
Mar 31 21:33:16 speedy tvheadend[31043]: TS: ...: TELETEXT
```
I'd like tvheadend to correctly distinguish this and receive data only from one source and filter out the other ones.
History
Updated by Flole Systems over 4 years ago
Updated by How exactly should tvheadend know which is the right IP and which is the wrong one? Would be great if you could clear that up.
Updated by Daniel Kucera over 4 years ago
Updated by When the destination multicast address and port are the same, it is expected to be the same service.
I would configure this on first come, first serve basis so the first packet received would select the source address and only this would be accepted from that moment on. In my case it doesn't matter which source is chosen.
I also tried specifying source address in playlist like this:
#EXTINF:-1,HDTV: ARD rtp://[email protected]:1234 but I'm getting following error:
iptv: plist2.m3u - HDTV: ARD in SANET2 - cannot find ip address for interface (null) [e=Resource temporarily unavailable]
Updated by
Updated by Daniel Kucera over 4 years ago
saen acro wrote:
It's time to put udpixy on each interface with multicast.
I have a different workaround and it's time to improve tvheadend.
Updated by Flole Systems over 4 years ago
Can anyone think of a valid scenario where it's actually wanted to receive a single stream from multiple IPs/Sources? I think that would also cause quite some out of order packets so maybe we could indeed simply filter it and then just be done with it. This could also be a potential Denial-Of-Service issue if someone just sends random packets to the wide open UDP Port that is receiving the stream.
Updated by Daniel Kucera over 4 years ago
Actually one possible solution would be that during mux scan, the source IP would be detected and saved. But it may break services which often change source IP.
Updated by saen acro over 4 years ago
FFMpeg support multiple inputs as beckup input, when first fall switch to next.
Similar scenario exist in DVB inputs in TVH.
Updated by Flole Systems over 4 years ago
- Status changed from New to Accepted
- Target version set to 4.4
I was just trying to figure out if it's indeed as simple as getting the IP from the first packet and "locking" on that. If there is a valid scenario where half of the stream comes from x and the other half comes from y that would obviously not work and we need this to be optional. For failover the stream just needs to be restarted and it will lock on the IP of the backup source if that's the only one sending.
Updated by Daniel Kucera over 4 years ago
Flole Systems wrote:
I was just trying to figure out if it's indeed as simple as getting the IP from the first packet and "locking" on that.
Yes, this is exactly what I would preffer.
If there is a valid scenario where half of the stream comes from x and the other half comes from y that would obviously not work and we need this to be optional.
This doesn't seem to be probable because the latency synchronization would be impossible in most networks.
For failover the stream just needs to be restarted and it will lock on the IP of the backup source if that's the only one sending.
Fine for me.
Updated by Łukasz Dymek over 4 years ago
Updated by Maybe full SSM implementation? SSM, so we have one multicast, and multiple sources, where one is main, another is backup..