> However, I'm not shure if it is supposed to work to cat two > PES streams into /dev/dvb/a*0/audio0 and video0 and have the > MPEG decoder produce correctly synced output... I think it should, since it enables you to play, for example, DVDs without re-encoding them as TS. And not every device supports TS input, so in that case, there would be (again) one level of remuxing which is not needed if it's not possible to feed in a dual-PES stream.
We need: (or do we alrady have? i don't know the state of the new api by hearth since i'm still stuck on the old one, still searching for some time to port our drivers to the new api...) A way to specify if an *how* the whole thing is synced. For syncing we need DTS/PTS values of each stream, and a global STC. the STC should be either extracted from one stream ("Video master mode", "audio master mode") or extracted from the adaption field ("PCR") or - somehow, and honestly i don't know how - be fed via an auxialliary stream (in case we demux a PS, which has the STC values). often (when having a non-realtime data source, like harddisk, DVD etc.) it's not needed to have a global specified STC/PCR, but in case you're playing a network stream (either DVB, TCP or multicast), it's cruical, unless you want to risk buffer over- or underruns (since the sender will - slightly - have a faster or slower clock reference then your local one.) Honestly, i'm not yet sure how to play realtime-PS via network. And I have no idea how to handle differences in latency in a clean way. felix domke -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.