Hi Dave, Thanks for clearing up how the audio mixing works and setting me straight with dvbstream's ways of handling pids. I did learn C 10 years ago, but have forgotten most of it and can only kind of understand the basics now. I have a friend who might be able to help with the name-pipes in ts-filter. What would make this whole thing much easier is if /dev/dvb/adapter0/dvr0 wouldn't get locked as soon as something (such as "cat") tries to read from it. Catting the device twice and running two instences of ts2es and mpg123 would be messy, demanding of the cpu Etc but would at least work. Also, in my earlier post I slightly confused things by saying that I was using mplayer in my attempts to get this working. Although I did initially use mplayer, I quickly switched to mpg123 as it I didn't need the video anyway! Thanks for your ideas and I'll see if I can get something going! Regards, Monty Dave Chapman wrote... > 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. >
