On Sat, 15 Jan 2005 02:40 am, Tim Davies wrote: > > 1. I have removed the code to do audio track selection for PS recording, > > it > > should still work for TS. I will re-add this code after all this has made > > into into cvs. > > Awww...that was the cool bit! > it'll be back. Best to keep the patch as small as possible for the moment.
> > 2. Cleaned up some test code and hacks in transport.c. It now functions > > correctly and does not have the #if 0 stuff in it. > > That bit still works for me too. > > > 3. Tim, the change you made to the incCurrentAudioTrack call broke my > > setup. > > After looking at what you did I got an idea for a better fix which works > > for > > me and I am pretty sure it will work for you too. Can you test and > > confirm. > > No, but I think I have figured this one out. We have mutually exclusive > interests. It all happens when we see a packet from an audio stream that > isn't the wantedAudioStream... > > For your case you are saying: "Hey I didn't expect that packet, maybe I > should be listening to that instead!". You expect a single audio stream > written by dvbrecorder.cpp and there may have been a channel change (and > hence a codec change). Right? > > In my case, quite often there is more than one audio track (MPEG + AC3). > If I'm listening to the AC3 track, I specifically want to ignore any > packets from the MPEG stream. > > Surely autoSelectAudioTrack should get the right track, and if there is a > channel change this needs to be called again. I can see only two > conditions that currently call autoSelectAudioTrack: > > - When the recorded file is opened, obviously! > - If the current track has a greater index than what the stream contains. > That is just a sanity check. > > Surely at the end of ScanStreams (or somewhere like that) would be the > place to do it. GetFrame just doesn't seem the right place. And > autoSelect would be better than just incrementing the stream index until it > gets it right. > > I'm not sure we can do the test based on stream index after a channel > change (and therefore a complete set of streams changing). That's asking > for trouble. > > What do you reckon? > I reckon we are hacking in circles. The root cause of the problem for the PS playback is that mpeg.c does not remove unused audio tracks from the mpeg stream. So if I select a channel running MPEG audio, autoSelectAudioTrack selects the MPEG stream. Then when you change channels to a channel with AC3 audio mpeg.c adds a new track for AC3 to the mpeg stream but does not remove the old track (it just never sends packets on it). So you end up with avformatdecoder finding the packets from the new stream, seeing they are not on the wantedAudioStream and ignoring them, hence no audio. Avformatdecoder has no wany of knowing if an audio track is actually recieving data. This problem does not happen with TS recording, since all of your tracks are getting data. Although I suspect there will need to be a call to autoSelectAudioTrack when you change channels and get a new set of tracks which may or may not contain AC3 audio, but that's another issue (maybe the streams_changed callback is being called correctly from mpegts.c?). Making a strategic call to autoSelectAudioTrack wont fix the PS problem becuase it only looks for the exsitence of the track not whether it actually has any data being sent on it. So once you select a channel with AC3 audio, AC3 will always be selected, even when you move to a channel without AC3. The correct fix to the problem would be to make mpeg.c remove the unused tracks from the list of tracks and then call the streams_changed callback to get avformatdecoder to call autoSelectAudioTrack to select the correct track. I couldn't work out how to get mpeg.c to detect that a track was no longer needed, so I put in the too hard basket. Maybe I need to revist that descision. Until we do that fix, we need some code to detect if the stream actually has packets in it; if it doesn't then try another stream. This is the hack I added in v4 of the patch that you remved for v5. I know it is not the nicest of code but I think it will work for everyone until we can fix mpeg.c to remove the unused track. > I might have a hack at it in the morning (Perth time). > > > 4. This patch is a diff between cvs from a few hours ago, bigdvb3.5, and > > Marcus' latest trans.dif patch. It was based on v5 of the oz-ac3 as > > supplied > > by Tim. It should patch cleanly this time I hope. > > Patches cleanly, but all your patches seem to be in DOS format which upsets > the patch command (for me anyway!). > DOS format? I don't think so, I run linux all the way. I made a number of my changes with the wrong .vimrc which was putting in hard tabs, maybe thats the problem? Cheers, Mark Anderson > > Tim. _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
