Monty wrote: > I've also played with dvbstream and although it takes two pids on the > command line, one seams to have to be a video-pid. You must be using the (deprecated) "-ps" option. Ignore that option, and dvbstream will record a transport stream file containing as many PIDs as you wish. It doesn't help you when it comes to playing back that stream though. > Of course, another potential problem with this is that the > audio-description APids seam to transmit 64 Kbits mono whereas the > standard APid's stream at 128/192 Kbits. It would seam to me that the > different encoding rates wouldn't mix very easily. As long as they use the same samplerate (probably 48KHz) then there shouldn't be a problem. The mixing will take place in the PCM domain, not the compressed MPEG domain. The best way to get support for this would be to ask the authors of whatever video player (e.g. mplayer, xine) to add native support for this feature. However, if you wanted to hack something together yourself, you will find a simple program called "ts_filter" in the source code to dvbstream. If you (or someone else) is familiar with C, then this could easily be modified so that it filters the input transport stream consisting of one video and two audio streams, and writes the video and main audio packets to one named pipe, and the secondary audio packets to another named pipe. You could then use two instances of "mplayer" to play the video and main audio stream on one audio device, and the second audio stream on another audio device - I don't know how to do that with Alsa though. Also, you don't need to use the ts2es option with mplayer - it handles transport streams natively. Dave.
