Hi Rob, Rob.McConnell wrote:
> 5. Output control. I think we need to have another look at > this again. > When setting up a PID filter what type of output should be > delivered to the > internal queue? My h/w supports the following types in > addition to the > dedicated A/V decoder streams (DMX_OUT_DECODER): > > a) Full 188 bytes TS packets - yup, this is the same as > setting the > output to DMX_OUT_TS_TAP. > b) Header and adaptation fields only - useful for interrogating > fields without having to have the full payload dumped into memory and > copied > about endless times. > c) Just the payload. > d) table sections with our without filtering. > e) The h/w also supports a "dump" queue that can be > configured to > allow parts of a TS from other PIDs to be dumped into it. > For example, > it is possible to configure the h/w so that > the payload > goes off to one queue and the header/adaptation fields are > delivered to > this > general dump queue. > We should avoid to make the driver hardware dependend !!! > 6. Another device to support PSs for MPEG-1 and MPEG-2 > formats would be > desirable and should be implemented in kernel space to take > any advantages > of the available h/w. For devices that don't have a h/w > filter for the > stream id/etc. then this should be implemented in s/w (kernel > space) to > keep the api consistent. For PS material this is likely to > be from a HDD, > CDROM, DVD, ... that should have DMA capability, so it would > make sense to > keep it all in kernel space with ioctls to choose the > filtering capability > and to read the filtered PS back. Yes this needs to be inside, but still the questeion in one device or two ? > Do we currently support Audio ES in the API? If not, then > this needs to > be added as my h/w supports this. > When i look at the audio decoder device i also ask this question! Regards, thomas -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.