[linux-dvb] DVB-H, time slicing, MPE-FEC and multicast...

frankio kaboom at tiscalinet.it
Mon Feb 13 18:15:07 CET 2006


-Prologue-
I can receive a DVB-H signal from Winter Olympics 2006 trial with a
regular DVB-T PCI card,
it's a 10 video services transport stream (5 Mbps) with time slicing and
MPE-FEC enabled.
I can dump the stream to disk and analyze it with no problem using
dvbsnoop, so there is no DVB-H specific modulation type involved (e.g.
4k mode).
Video is H264 and audio is AAC-LC, they are encapsulated in a multicast
IP stream.

Following Thomas' post
(http://linuxtv.org/pipermail/linux-dvb/2006-February/007947.html) I
tried to decode some video or audio data with VLC (I have also .sdp
files) to no availability.
After some investigations I found out that packets were not forwarded to
L3 because of their MAC address and I could only receive packets in
promiscuos mode, using i.e. tcpdump.

-The problem-
I think the actual implementation of dvb_net.c in DVB driver about MPE
multicast IP datagrams is broken if time slicing and/or MPE-FEC are used.
The dvb_net_sec() MPE parsing function forges ethernet headers like this:

    /* create ethernet header: */
    eth[0]=pkt[0x0b];
    eth[1]=pkt[0x0a];
    eth[2]=pkt[0x09];
    eth[3]=pkt[0x08];
    eth[4]=pkt[0x04];
    eth[5]=pkt[0x03];

but in ETSI EN 301 192 v1.4.1 this is the case only if
MAC_address_range==0x06 in multiprotocol_encapsulation_info, in every
other case the above assignments are wrong.

-My problem-
In my stream MAC_address_range==0x02, so only last two bytes of
destination MAC are valid, first 4 bytes carry real_time_parameters used
by MPE-FEC and time slicing and should be ignored (unless someone comes
up with FEC decoding ;) ).

In my case a quick and dirty hack would be (not tried yet):

    /* create ethernet header: */
    eth[0]=0x01;
    eth[1]=0x00;
    eth[2]=0x5E;
    eth[3]=0x00;
    eth[4]=pkt[0x04];
    eth[5]=pkt[0x03];

as per RFC 1112 multicast IP to MAC mapping, but I'm sure we can deal
with it in a proper way.

-The proper way-
I think dvbnet should honor multiprotocol_encapsulation_info found in
Data_broadcast_descriptor if data_broadcast_id==0x0005 (MPE), so it has
to scan SDT first (don't know another way to check MAC_address_range value).
Sorry but I have little or no idea of which modifications are needed,
I'm pretty new to Linux DVB API.
Suggestions are welcome, hope I didn't spread too much nonsense.

Francesco Schiavarelli





More information about the linux-dvb mailing list