Re: Format of /dev/video or where to get MPEG TS stream?

[Ralph Metzler <rjkm@netcologne.de>]

Terry Hardie writes:
 > I tried implementing it (/dev/vbi is Major 81, Minor 224, right?), and I

Yes, thatīs the right device.

 > never get anything while reading from /dev/vbi. I tried pid 0x10
 > (NIT) also, with no filters, and still got nothing - I do get video data
 > (although I haven't tried understanding it) on /dev/video, and have a good
 > signal lock. If I set the video pid to 0x10, I can get some NIT data, so
 > I'm sure it's there.


Oops, sorry, my example was fine for IP/MPE data but for section data
you have to use something like this:

struct bitfilter filt = {
 pid,
 { section, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},
   mode,0,
   FILTER_MEM,
};


where section is ((section_id << 8) | 0xff )

mode is one of 

#define	SECTION_SINGLE		0x00
#define	SECTION_CYCLE		0x02
#define	SECTION_CONTINUOS	0x04

where SECTION_SINGLE gives you the section just once, SECTION_CYCLE
gives you one cycle of sections with same id but different section
numbers (read the ETSI) and SECTION_CONTINUOS keeps writing out the
section as long as the filter is active.

FILTER_MEM specifies that data is piped to /dev/vbi (sorry, without
this of course you couldnīt get anything)

There is also FILTER_UDP which is supposed to give you the data on a
UDP port (like in the windows driver) but this does not work for me.
Somewhere the packets get lost. 
Question: Does 	"skb->ip_summed = CHECKSUM_UNNECESSARY;" only refer to 
the IP package checksum, i.e. do I have to calculate the UDP checksum
to get the packets safely through the kernel?


And you HAVE TO set some filter data. Empty filters (all 0) do not give you
all sections but nothing!
To get all section of one PID you could use two filters with the same
PID, one with:

 { 0x0101, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},

and one with:

 { 0x0001, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},

as filter.
I am not sure if this is the firmwares fault or a hardware limitation.
The firmware checks for the first non-zero mask bits to determine the
number of relevant filter bytes and rejects filters without mask bits.
Iīll have to see what happens if I allow this in the firmware.

For an example of how to use all this for a channel scan look in DVB/libdvb.


Ralph