Mailing List Archive: MythTV: Dev

devel/rtp: multiple IPTV streams, same port-no

Index | Next | Previous | View Threaded

nok at kirkeby

Apr 28, 2012, 2:09 PM

Post #1 of 10 (620 views)
Permalink

devel/rtp: multiple IPTV streams, same port-no

Hi

I was trying to figure out why devel/rtp didn't work for me and found a
major (if you're struck by it) flaw in the multicast handling in MythTV.
The problem is that my provider delivers streams like
udp://222.111.222.xx:2000. That is for all streams the port-no is the same.
In Linux, basically only the port-no differentiates the various
udp-streams. Thus I noticed a strange phenomena in MythTV: two iptv-tuners
recording two different streams but all data goes to the first stream !

I made a small test-program: Open two sockets, join two different multicast
streams (udp://222.111.222.123:2000 and udp://222.111.222.124:2000). I
noticed the bind() for the second socket failed. When I read from the
sockets, only the first socket has any data but the data was a merge from
both streams ! After some digging I found out that apparently you can only
have one common socket for all streams and should use sockopt IP_PKTINFO to
find the multicast group the data is for.

I'm not quite into the class-relations in MythTV yet but are trying to
figure out how to handle this. Could anybody responsible for the devel/rtp
branch please comment on this ? Whether this is "just" a patch or a major
rewrite ?

What's strikes me is that appearently I only had minor problems whether the
"old" IPTV code and that code didn't use IP_PKTINFO either.

danielk at cuymedia

Apr 28, 2012, 6:07 PM

Post #2 of 10 (604 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

On Sat, 2012-04-28 at 23:09 +0200, Niels Ole Kirkeby wrote:
> Hi
>
> I was trying to figure out why devel/rtp didn't work for me and found
> a major (if you're struck by it) flaw in the multicast handling in
> MythTV. The problem is that my provider delivers streams like
> udp://222.111.222.xx:2000. That is for all streams the port-no is the
> same. In Linux, basically only the port-no differentiates the various
> udp-streams. Thus I noticed a strange phenomena in MythTV: two
> iptv-tuners recording two different streams but all data goes to the
> first stream !

Just a bug, what you are describing should be handled by the
setsockopt call on line 225 of iptvstreamhandler.cpp.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

jyavenard at gmail

Apr 28, 2012, 6:23 PM

Post #3 of 10 (599 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

Hi

On Sunday, 29 April 2012, Daniel Kristjansson wrote:

> On Sat, 2012-04-28 at 23:09 +0200, Niels Ole Kirkeby wrote:
> > Hi
> >
> > I was trying to figure out why devel/rtp didn't work for me and found
> > a major (if you're struck by it) flaw in the multicast handling in
> > MythTV. The problem is that my provider delivers streams like
> > udp://222.111.222.xx:2000. That is for all streams the port-no is the
> > same. In Linux, basically only the port-no differentiates the various
> > udp-streams. Thus I noticed a strange phenomena in MythTV: two
> > iptv-tuners recording two different streams but all data goes to the
> > first stream !
>
> Just a bug, what you are describing should be handled by the
> setsockopt call on line 225 of iptvstreamhandler.cpp.
>
> -- Daniel
>
>
>
Actually, it's probably the same bug I was seeing for RAOP; since the
change to use ServerPool everywhere... They all try to bind locally to the
port they connect to remotely.
Only the first will work; any further ones will fail to be created.....

ServerPool should only be used for incoming sockets; not for connecting to
a remote machine... I assume the commit that replaced sockets with
ServerPool everywhere broke functionality in quite a few more places.

JY

nok at kirkeby

Apr 28, 2012, 11:51 PM

Post #4 of 10 (598 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

I believe you miss the point: It is not just a call to setsockopt(). You
can only have one socket for all multicast-streams. Whether you have 1, 4
or 8 iptv-tuners, they should all use the same socket. At least if any of
them might use the same point-no. As for me :-)

I assume this is the case for all multicast-streams. Thus any streams using
the same port-no needs to use the socket and PKTINFO even thou the
functionality is not related.

2012/4/29 Daniel Kristjansson <danielk [at] cuymedia>

> On Sat, 2012-04-28 at 23:09 +0200, Niels Ole Kirkeby wrote:
> > Hi
> >
> > I was trying to figure out why devel/rtp didn't work for me and found
> > a major (if you're struck by it) flaw in the multicast handling in
> > MythTV. The problem is that my provider delivers streams like
> > udp://222.111.222.xx:2000. That is for all streams the port-no is the
> > same. In Linux, basically only the port-no differentiates the various
> > udp-streams. Thus I noticed a strange phenomena in MythTV: two
> > iptv-tuners recording two different streams but all data goes to the
> > first stream !
>
> Just a bug, what you are describing should be handled by the
> setsockopt call on line 225 of iptvstreamhandler.cpp.
>
> -- Daniel
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>

nok at kirkeby

Apr 29, 2012, 4:46 AM

Post #5 of 10 (589 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

2012/4/28 Niels Ole Kirkeby <nok [at] kirkeby>

> Hi
>
> I was trying to figure out why devel/rtp didn't work for me and found a
> major (if you're struck by it) flaw in the multicast handling in MythTV.
> The problem is that my provider delivers streams like
> udp://222.111.222.xx:2000. That is for all streams the port-no is the same.
> In Linux, basically only the port-no differentiates the various
> udp-streams. Thus I noticed a strange phenomena in MythTV: two iptv-tuners
> recording two different streams but all data goes to the first stream !
>
> I made a small test-program: Open two sockets, join two different
> multicast streams (udp://222.111.222.123:2000 and udp://
> 222.111.222.124:2000). I noticed the bind() for the second socket failed.
> When I read from the sockets, only the first socket has any data but the
> data was a merge from both streams ! After some digging I found out that
> apparently you can only have one common socket for all streams and should
> use sockopt IP_PKTINFO to find the multicast group the data is for.
>
> I'm not quite into the class-relations in MythTV yet but are trying to
> figure out how to handle this. Could anybody responsible for the devel/rtp
> branch please comment on this ? Whether this is "just" a patch or a major
> rewrite ?
>
> What's strikes me is that appearently I only had minor problems whether
> the "old" IPTV code and that code didn't use IP_PKTINFO either.
>

I just discovered another "hidden" feature of Linux: You can bind to a
multicast address. Thus if the bind() call in iptvstreamhandler.cpp, line
211 includes the multicast adress instead in ANY_HOST it actually works.
Just tested. However as far as I can understand, using IP_PKTINFO is the
"portable" way to do, for those OS who understands this option. But since
mythtv currently is only Linux, does it matter ?

kkuphal at gmail

Apr 30, 2012, 8:13 AM

Post #6 of 10 (570 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

On Sun, Apr 29, 2012 at 6:46 AM, Niels Ole Kirkeby <nok [at] kirkeby> wrote:

>
>
> 2012/4/28 Niels Ole Kirkeby <nok [at] kirkeby>
>
>> Hi
>>
>> I was trying to figure out why devel/rtp didn't work for me and found a
>> major (if you're struck by it) flaw in the multicast handling in MythTV.
>> The problem is that my provider delivers streams like
>> udp://222.111.222.xx:2000. That is for all streams the port-no is the same.
>> In Linux, basically only the port-no differentiates the various
>> udp-streams. Thus I noticed a strange phenomena in MythTV: two iptv-tuners
>> recording two different streams but all data goes to the first stream !
>>
>> I made a small test-program: Open two sockets, join two different
>> multicast streams (udp://222.111.222.123:2000 and udp://
>> 222.111.222.124:2000). I noticed the bind() for the second socket
>> failed. When I read from the sockets, only the first socket has any data
>> but the data was a merge from both streams ! After some digging I found out
>> that apparently you can only have one common socket for all streams and
>> should use sockopt IP_PKTINFO to find the multicast group the data is for.
>>
>> I'm not quite into the class-relations in MythTV yet but are trying to
>> figure out how to handle this. Could anybody responsible for the devel/rtp
>> branch please comment on this ? Whether this is "just" a patch or a major
>> rewrite ?
>>
>> What's strikes me is that appearently I only had minor problems whether
>> the "old" IPTV code and that code didn't use IP_PKTINFO either.
>>
>
> I just discovered another "hidden" feature of Linux: You can bind to a
> multicast address. Thus if the bind() call in iptvstreamhandler.cpp, line
> 211 includes the multicast adress instead in ANY_HOST it actually works.
> Just tested. However as far as I can understand, using IP_PKTINFO is the
> "portable" way to do, for those OS who understands this option. But since
> mythtv currently is only Linux, does it matter ?
>

MythTV runs on Linux, MacOS, and Windows so it does...

Kevin

nok at kirkeby

May 1, 2012, 12:07 AM

Post #7 of 10 (563 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

Then I would suggest that devel/rtp should go in that direction, i.e. one
common socket for all (udp) streams and use IPPKTINFO. Daniel ? I guess
it's you who is resposible for the devel/rtp branch. Could you comment ?

I'm still trying to figure out the class-hierarchy and how the mythtv
software works but once I'm there you can count me in (In whatever spare
time I've left :-)

Niels Ole Kirkeby

2012/4/30 Kevin Kuphal <kkuphal [at] gmail>

> On Sun, Apr 29, 2012 at 6:46 AM, Niels Ole Kirkeby <nok [at] kirkeby> wrote:
>
>>
>>
>> 2012/4/28 Niels Ole Kirkeby <nok [at] kirkeby>
>>
>>> Hi
>>>
>>> I was trying to figure out why devel/rtp didn't work for me and found a
>>> major (if you're struck by it) flaw in the multicast handling in MythTV.
>>> The problem is that my provider delivers streams like
>>> udp://222.111.222.xx:2000. That is for all streams the port-no is the same.
>>> In Linux, basically only the port-no differentiates the various
>>> udp-streams. Thus I noticed a strange phenomena in MythTV: two iptv-tuners
>>> recording two different streams but all data goes to the first stream !
>>>
>>> I made a small test-program: Open two sockets, join two different
>>> multicast streams (udp://222.111.222.123:2000 and udp://
>>> 222.111.222.124:2000). I noticed the bind() for the second socket
>>> failed. When I read from the sockets, only the first socket has any data
>>> but the data was a merge from both streams ! After some digging I found out
>>> that apparently you can only have one common socket for all streams and
>>> should use sockopt IP_PKTINFO to find the multicast group the data is for.
>>>
>>> I'm not quite into the class-relations in MythTV yet but are trying to
>>> figure out how to handle this. Could anybody responsible for the devel/rtp
>>> branch please comment on this ? Whether this is "just" a patch or a major
>>> rewrite ?
>>>
>>> What's strikes me is that appearently I only had minor problems whether
>>> the "old" IPTV code and that code didn't use IP_PKTINFO either.
>>>
>>
>> I just discovered another "hidden" feature of Linux: You can bind to a
>> multicast address. Thus if the bind() call in iptvstreamhandler.cpp, line
>> 211 includes the multicast adress instead in ANY_HOST it actually works.
>> Just tested. However as far as I can understand, using IP_PKTINFO is the
>> "portable" way to do, for those OS who understands this option. But since
>> mythtv currently is only Linux, does it matter ?
>>
>
> MythTV runs on Linux, MacOS, and Windows so it does...
>
> Kevin
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>
>

danielk at cuymedia

May 11, 2012, 12:38 PM

Post #8 of 10 (455 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

On 05/01/2012 03:07 AM, Niels Ole Kirkeby wrote:
> Then I would suggest that devel/rtp should go in that direction, i.e.
> one common socket for all (udp) streams and use IPPKTINFO. Daniel ? I
> guess it's you who is resposible for the devel/rtp branch. Could you
> comment ?
>
> I'm still trying to figure out the class-hierarchy and how the mythtv
> software works but once I'm there you can count me in (In whatever spare
> time I've left :-)

I've applied your patch as is + some error handling on the binding.
It has the wonderful property of being simple and working properly.

IP_PKTINFO and recvmesg is probably the way to go though. I had
hoped to be able to use QUdpSocket, but it looks like the model
it uses is a bit too simple.

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

james.dutton at gmail

May 14, 2012, 2:34 PM

Post #9 of 10 (438 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

On 28 April 2012 22:09, Niels Ole Kirkeby <nok [at] kirkeby> wrote:

> Hi
>
> I was trying to figure out why devel/rtp didn't work for me and found a
> major (if you're struck by it) flaw in the multicast handling in MythTV.
> The problem is that my provider delivers streams like
> udp://222.111.222.xx:2000. That is for all streams the port-no is the same.
> In Linux, basically only the port-no differentiates the various
> udp-streams. Thus I noticed a strange phenomena in MythTV: two iptv-tuners
> recording two different streams but all data goes to the first stream !
>
> I made a small test-program: Open two sockets, join two different
> multicast streams (udp://222.111.222.123:2000 and udp://
> 222.111.222.124:2000). I noticed the bind() for the second socket failed.
> When I read from the sockets, only the first socket has any data but the
> data was a merge from both streams ! After some digging I found out that
> apparently you can only have one common socket for all streams and should
> use sockopt IP_PKTINFO to find the multicast group the data is for.
>
> I'm not quite into the class-relations in MythTV yet but are trying to
> figure out how to handle this. Could anybody responsible for the devel/rtp
> branch please comment on this ? Whether this is "just" a patch or a major
> rewrite ?
>
> What's strikes me is that appearently I only had minor problems whether
> the "old" IPTV code and that code didn't use IP_PKTINFO either.
>
>
Why not use Source Specific Multicast. I.e. So you can match against both
source and destination of the multicast.
SSM uses multicast addresses that start with 232.X.X.X

danielk at cuymedia

May 14, 2012, 3:07 PM

Post #10 of 10 (443 views)
Permalink

Re: devel/rtp: multiple IPTV streams, same port-no [In reply to]

On 05/14/2012 05:34 PM, James Courtier-Dutton wrote:
> On 28 April 2012 22:09, Niels Ole Kirkeby <nok [at] kirkeby
> <mailto:nok [at] kirkeby>> wrote:
> Why not use Source Specific Multicast. I.e. So you can match against
> both source and destination of the multicast.
> SSM uses multicast addresses that start with 232.X.X.X

MythTV does support specifying the the source. That's not the problem
The problem is that you bind more than once to the same port on the
local machine this either fails outright due to permissions and all
the data goes to the first socket to bind to that port, or if the
additional binds are allowed, individual packets are sent randomly
to any one of the open socket readers.

There are two ways to deal with this. One is to re-architect so that
instead of having one reader thread per stream, we have one thread
per locally bound port. The other is to simply bind to the multicast
address+port instead of listening on that port on a local address
and keep the current architecture. For now we're doing the latter
as it works well on Linux and results in a nice simple architecture.
However, it may not be portable. So this needs to be tested on other
operating systems and we may need to consider the less elegant but
more portable solution.

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads