Hi Luca, On Tue, 18 Apr 2006, Luca Abeni wrote: > According to the section about time-slicing (that should be always used > in DVB-H, right?) it seems to me that some code in dvb_net.c has to be > changed. In particular, dvb_net_sec() assumes that the MAC address is > always coded in 6 bytes in the MPE header. > But it seems to me that if time-slicing is used, then only 1 or 2 bytes > are used for the MAC address, and the remaining 4 bytes are used for > encoding the time-slicing real time parameters. Afaik: in the former MAC-Address-part information is stored which gives you the point in time from when the next burst is coming for this section. > So, dvb_net.c might end up forging ethernet packets with a wrong MAC > address... Exactly that is the reason why dvb_net is not working with DVB-H transmissions right away. > 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) > Is anyone already thinking about a possible solution? Thinking a lot, but I have no time to do anything... I was only thinking of the multicast MPE-sections: I was thinking to use a normal DVB-T device (support by linux-dvb). (The additional 4K FFT mode and the 8k-interleaver used with 4k and 2k FFT is not supported currently by any DVB-T demod in linux-dvb, but very soon there will be at least one device which has such a demod inside.) 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. 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). The daemon would get a /dev/dvb/adapterX, and one start-frequency (or more). The daemon could even handle time-slicing by implementing a new-frontend-op called suspend/resume. One should be able to set up the daemon to handle all or only one network inside one TS or more TSs (don't remember the correct name for those networks) As the multicast-address of the ESG is fixed, a possible user could first request this address (by running flute, e.g.), the daemon would tune to the appropriate frequency, setup the section filter, start the decap. After having the ESG checked out, you theoretically have all the information to request more services (by joining their multicast group). > (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 :). > (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. Please take this mail just as ideas. I was working a little bit with DVB-H last summer, but I didn't read all the standards, maybe something is completely wrong in my understanding. regards, Patrick. *) As libucsi is small, fast, platform-independent, easily extendable and C it is, IMHO, the best thing to be used for that part. PS: If you want to start something, there is some space left in dvb-apps or somewhere else on linuxtv.org :) _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
