On Thu, Oct 31, 2002 at 05:37:44PM +0100, Klaus Schmidinger wrote: > Johannes Stezenbach wrote: > > > > I don't see why an application would request a TS from the driver if the > > applicaton wants PES and the driver can deliver PES. > > STB controllers that support recording can use any format they want, > > as long as they support playback of the same format. > > The entire recording and "Transfer Mode" mechanisms of VDR are based on the > assumption that the driver can deliver TS packets, since that's the most > basic form of data (AFAIK that's the way it is broadcast), and it is the > easiest way to distribute the data to various receivers. This is what made, > for instance, "overlapping recordings" possible in VDR. I also don't see > how one would be able to record more than one programme (or one programme > with several audio PIDs) if the driver delivers PES. As far as I understand > things this is only possible if it delivers TS (but please correct me if I'm > wrong here).
The API allows you to get multiple PES at the same time, just open /dev/dvb/adapter0/dmx0 multiple times, set your DMX_PES_OTHER/DMX_OUT_TAP filter, and read from /dev/dvb/adapter0/dmx0 (currently broken, see my other post today). If the hardware can give you a filtered TS, the most natural way is to get it via DMX_OUT_TS_TAP from /dev/dvb/adapter0/dvr0. If the hardware does not give you TS packets, but PES (or the infamous Technotrend AVPES) packets, the driver must try to recreate the TS if you ask for DMX_OUT_TS_TAP. That's where all those "badly mltiplexed TS" were coming from that we had until some months ago. But to cut that discussion short, I just reviewed some of the driver source, and there is much less code devoted to multiplexing than I thought. Since what we have now seems to work pretty good, maybe just forget what I wrote. Regards, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
