Hi Patrick, 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 filter). 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 again... [...] > *) 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. Thanks, Luca -- Proud to be "coglione" _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
