nok at kirkeby
May 1, 2012, 12:07 AM
Post #7 of 10
Then I would suggest that devel/rtp should go in that direction, i.e. one
Re: devel/rtp: multiple IPTV streams, same port-no
[In reply to]
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>
>>> 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://126.96.36.199:2000 and udp://
>>> 188.8.131.52: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...
> mythtv-dev mailing list
> mythtv-dev [at] mythtv