This "autodetection" is technically impossible. a) Not all hardware has the ability to provide a raw transport stream
b) If it had the capability, you would lose data between the time the
kernel creates the device and the user scans for directory entries.
Think of tables which are broadcasted at very low rates.
Besides that, I think you proposal is weird and I don't like it. :-)
If it is impossilble, how does this STB hardware scan channels to
search for stations? Does the user need to supply all freqency/
polarization/symbolrate parameters and pids for each channel
he wants to see?
See above. Additionaly this would require the kernel to a) know what types of pids do exist (audio (how about ac3 - non-ac3), video, teletext, different kind of sections) b) identify them As above, I think it is weird and I don't like it.
Yes either the userspace decoder daemon should know
about all types of PIDs, or in case of hardware acceleration,
kernel has to know about PIDs, cooperate with hardware
and steer the hardware demux properly.
Rarely broadcast tables have to be cached and channels
added when the daemon first sees them. Then it will write
configuration file so next time it can come up quickly.
This approach can be wierd, but it's novel and up-to-date
with latest kernel technology.
we have computers to do all the boring hex data housekeeping and
autodetection for us.
It's also resource hungry but
will provide the maximum user luxury. One will be able to
simple tune and immediately see autodetected receptions,
record many channels simultaneously, and have features yet
unseen in single view STB's.
Imagine having STB capable to display multiple PIDs from a tuned
frequency in a mosaic all in one screen and then choose
which one you want to view full screen. Make STB technically
years ahead of competition, set a bit higher price and win all
of the customers.
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.