Hello Jamie, please have a look at my other mail for details.
Mpeg decoders usually don't parse Transport Streams (I only know one old chipset which has some kind of simple demultiplexer built in for single program TS). Therefore they don't know what a PID is. So why should the A/V PIDs be given to the mpeg decoder device? The Transport Demux has toPresumably mpeg decoder driver would be a better description.
Or "mpeg demux".
My approach is to put the stuff where it belongs. 8-) Mpeg demux to a specialized mpeg demux device, general purpose stuff to one device, that can be opened multiple times.But video/audio/pcr for example has nothing to do with demuxing, it's mpeg decoding. Section filters are always bound to one PID, so why not one oper per PID?
video, audio and pcr _do_ have something to do with demuxing, see above.
Being naive, I can ask stupid questions :)
Why can't demuxing just be attached wherever you like. Playback, record,
like a push down stack : sys v streams.
The decoder has nothing to do with filtering but instead is getting the filtered data from the demux hardware.
You may want to delay demuxing?So it makes sense to name it "mpeg demux", because it demuxes/filters the stream, but doesn't have anything to do with the mpeg decoder behind it (that's what adapter0/video0 is for).
I also imagine mpeg decoder devices becoming far more common on their
own than than combined with tuner type devices. E.g. motherboards like mini-itx, Atmel AT91RM9200, combined with slower, lower power processors.
Jamie
CU Michael. -- Info: To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.