[linux-dvb] Question about dvbnet and time-slicing
lucabe72 at email.it
Thu Apr 20 10:33:37 CEST 2006
On Thu, 2006-04-20 at 08:44 +0200, Patrick Boettcher wrote:
> > Now, the problem is that the number of bytes used for storing the MAC
> > address in the MPE header is encoded in the
> > time_slice_fec_identifier_descriptor (where is it generally contained,
> > BTW?)... So, the dvb driver should parse a lot of tables for knowing how
> > to set the MAC address... But I do not think that parsing SDT, PMT, NIT,
> > INT, etc in the in-kernel dvb driver is a good idea. So, how can this
> > problem be solved?
> I agree to that. IMHO, the whole DVB-H stack should be implemented
> in userspace. (As long as not supported by the hardware)
I arrived to a similar conclusion, but I am still fearing that this
would result in a performance drop (before arriving to the final user
application, IP data would need to cross the KS/US boundary 3 times
instead of 1).
But I have no numbers to check if this performance drop would be
noticeable or not.
> > Is anyone already thinking about a possible solution?
> Thinking a lot, but I have no time to do anything...
Same here ;-)
> In my idea a small daemon in userspace is doing the tuning
> of the dvb-part, using the section-filter of dvb-core and is using libucsi
> (*) for doing the section-parsing.
Ok. But this would create problems if other applications want to receive
audio/video PIDs, no? (I think the demuxer device can be opened by only
one application... Or am I wrong?)
> Additionally there has to be a network-device created by some kernel
> module which has to be in contact with this daemon to communicate:
> 1) from the network-device to the daemon telling it, when a new
> multicast-join was requested, 100% sure
> 2) the daemon, if it is doing the MPE-decap and the MPE-FEC, has to pass
> the IP-packets back to it (not so sure if this is the best way).
I think this can be easily done by using a TUN device (when an
application joins an MC group on the TUN device, the daemon will receive
the IGMP - I think - packets, so that it can open the proper PID
BTW, I think this soultion (US daemon which produces traffic on a TUN
device) can work perfectly for unicast traffic too.
> > (I could only think about the really stupid solution: for multicast
> > traffic, compute the multicast MAC from the IP address, and for unicast
> > traffic always use the MAC from the DVB card :)
> In DVB-H multicast is used for the main services (ESG, other
> metadata, video/audio streams), as dvb_net is not the best place for dvb-h
> anyway, it doesn't hurt to hack it :).
Well, this would probably be the "dirty" solution, but I think it is the
easiest way to receive IP traffic on dvb-h.
Maybe a parameter can be added to the kernel module (or a new ioctl can
be defined) to specify if the MAC address has to be taken from the
section header, or if dvb_net has to construct it in a different way
(from the IP MC address, or from the DVB card MAC address).
> > (another question for the DVB experts here: if only one byte in the MPE
> > header is used for storing the MAC, where can the IP/MAC association be
> > found? Is it in the INT table?)
> Afair, yes.
Ok, thanks. I read the standard, but I did not find any explicit way to
specify an IP/MAC association in the INT. Going to check the standard
> *) As libucsi is small, fast, platform-independent, easily extendable and
> C it is, IMHO, the best thing to be used for that part.
I did not know about it until today, but it seems very useful.
Unfortunately, I've not been able to find documentation about it.
> PS: If you want to start something, there is some space left in dvb-apps
> or somewhere else on linuxtv.org :)
Well, I have to check with my boss at work. If he says that I can spend
some time on this issue, I'll surely post some patches for dvb_net, and
I'll publish here the code for the user-space daemon.
Proud to be "coglione"
More information about the linux-dvb