On Thu, May 05, 2005 at 08:14:31AM +0100, Charlie Brej wrote: > Yeah the original patch is patchy but I don't think this patch is perfect > either. Basically this picks off the first descriptor_tag. I did run a few > scans to look for such a 'tell' but it isn't that easy. I hacked about the > dvbscan util to tell me more info about the streams it doesn't know about > (I can send you a patch). From what I have seen yeah the audio streams > have an 0x0A tag on them and they are easy to recognize. But the both the > Audio and Video streams have the 0x52 tag on them (the audio usually has > the 0x0A first though). So the patch seems correct unless they change the > order of these tags.
The audio stream tag (0x0A) is also looked at the next switch statement and used to parse the language code. This is why I asked on the list a few days ago about if the subtitle streams etc are always in a private section. If they were then the whole lot could be consolidated into a much nicer bit of logic. Unfortunately it seems that things were done that way because it is not guaranteed that subtitle streams etc are always in private sections :-( > > Stuart Auchterlonie wrote: > >While we are talking about major TODOs there will be a need for a > >mechanism for the frontend to tell the backend which PIDs it wants. > > I think this would be much simpler done if the backend simply records all > streams given in the channel description. The front end can then pick and > choose which streams to play. This will allows you to record interactive > content, teletext, subtitles... and then maybe later when viewing select > the stream you want to listen/watch though the interactive interface or a > manually cycle through all (suspected) audio/video streams. What about when you need to pick a program off a different transport stream? Streams that the mheg application wants are coded in the form dvb://<original_network_id>.[<transport_stream_id>].<service_id> It is theoretically possible that a different transport is being used is it not???? Stuart
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
