[linux-dvb] Re: section demux rewritten

[Ralph Metzler <rjkm@metzlerbros.de>]

Johannes Stezenbach writes:
 > Emard,
 > 
 > Emard wrote:
 > > >  > So average_network_user wouldn't have to care which PID is there,
 > > >  > and as he szap's also restart network apps to change the dvb0_0
 > > >  > for dvb0_1, but instead just register dvbnet -p 8192 and have one
 > > >  > and only dvb0_0 for all network purposes 
 > > > 
 > > > 
 > > > So, there could be use for multi-PID section filters after all!
 > > 
 > > I'm wishing to have multi-PID section filter for a long time
 > 
 > I think Ralph was just pulling your legs. It doesn't make sense

Urgh, I actually wasn't (this time ;-).

Scanners which process a lot of PMTs would also be easier to write.
You just set one filter for PMT headers, add PIDs when parsing the PAT
and you still can differentiate the returned sections by looking 
at the service ID field. 

 > to dump all data from a TS into the dvbnet device. First of all,
 > some of that data isn't even in section format (video etc.), and
 > then there could be more than one MPE stream in the TS, which you
 > cannot handle with only one net device (that would be like having
 > two ethernet cards in your PC and only one eth0 device).

You would of course have to supply a PID list and be certain that it
makes sense with the data the service provider of this transponder sends. 

The drawbacks I see are that you just push a lot of complexity from
the user program and/or dvb_net layer into the driver level filters
and I see no real performance gains from this right now.
The advantage would be that you save a few bytes for the identical 
filter data/mask/mode structs and of course the dvb_net layer and 
user programs would look very simple.

But for hardware with (non-multi-PID) section filters implementing this
might even be a nightmare...

Ralph


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.