[linux-dvb] Re: V4 API proposal

[Marcus Metzler <mocm@metzlerbros.de>]

emard@softhome.net writes:
 > > 
 > > 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. :-)

I can only support this statement.

 > 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? 

No the OEM provides the tables. Have you ever used a digital
receiver. Most of them come with preprogrammed transponder and channel
lists. Which are sometimes updated by a channel search by the user or
a firmware update by the OEM.

 > 
 > > 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.

It may also cause security and stability problems.

 > 
 > 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. 
 > 

The kernel should not care about the pids. The user space program sets
the demux filters and scans for new channels if needed. It's not the
job of the kernel to do that.


 > 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. 
 > 

You don't write configuration files from kernel space.
Otherwise exactly this is done by user space programs.

 > This approach can be wierd, but it's novel and up-to-date
 > with latest kernel technology. 

What kernel have you been looking at? 
A PID is not a device like a USB device or a PCMCIA card.

 > 
 > we have computers to do all the boring hex data housekeeping and
 > autodetection for us. 
 > 

The user uses user space programs that are written by people who know
what they are doing and not the kernel directly.

 > 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. 

For a mosaic you need several MPEG decoders. You either need special hardware
for that or very fast/ several CPUs. I don't know what you are
dreaming about. STBs are usually just "normal" CPUs (arm, mips, i386, ppc)
with some receiver hardware and maybe an MPEG decoder. The only thing
that is different from a PC is the box size, they can't use extra PCI
cards, the amount of memory, hard disk space and they may not have
quite the fastest CPU possible for a desktop (between 10% and
100%). The latter is compensated by special hardware which makes them
even faster for their specialized task than a PC.  


Marcus

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/



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