On Friday 28 January 2005 19:28, Isaac Richards wrote: > On Friday 28 January 2005 03:10 am, Mark Anderson wrote: > > > The audio codec _can't_ change for a given streamtype. The startcode > > > of a stream in a mpeg file is different based on what codec it is. > > > Streams returned from libavformat are enumerated by the startcode. A > > > new codec will be given a new logical stream. If this is necessary, > > > something's badly wrong in the ts2ps junk the dvb code is using. > > > > This fix did resolve the audio re-initialisation problem. I have just > > spent some time looking at this fix. If you want a less intrusive fix (as > > indicated in another mail) then may I suggest we add a call to > > SetupAudioParams to the end of ScanStreams, incCurrentAudioTrack, > > decCurrentAudioTrack and setCurrentAudio track. I tried this out and it > > works fine so I am happy with that alternative if you are. > > Shouldn't be in ScanStreams, though. Probably want it in autoSelect, inc, > dec, and set, before the call to CheckAudioParams. Just try to keep it > from calling NVP->ReinitAudio() if it doesn't have to, as that'll cause a > small break in the output. > I think that'll be fine, I'll test later tonight.
> > All day I have been trying to understand how you could make this > > statement. After running a few tests here at home I now understand. > > Software AC3 is already built in (I actually thought it wasn't) and so if > > it encounters an AC3 stream and ac3passthrough is disabled then the > > software decoding takes over and the audio is presented to the sound card > > just like MPEG2. Is this correct? > > Yup. > > > If this is true then I could conceed that the GUI option is not > > needed if you don't mind autoSelectAudioTrack selecting AC3 audio in > > preference to MPEG tracks when they are available. I think it is poor > > usability to expect the user to change the audio track each time they > > change to a channel with both MPEG and AC3 and they want AC3 when it is > > available. > > Well, right now, there's absolutely no difference to the user if they're > using mpeg2 or ac3 audio for software decoding. Both are going to get > downmixed to stereo until Ed Wildgoose adds a bit more code to the > audiooutput layer (which likely won't be until after the 0.17 release). > Once that's in, AC3 won't get downmixed like that anymore, and the current > autoselect audio track code should prefer that if it exists, since it > should have more channels than the mpeg2 audio. And if it's the same > number of channels, then, it doesn't really matter at all which gets > picked. =) That's fine for software but there is an advantage to using AC3 when SPDIF passthrough is enabled. It looks like the original code tries to prefer ac3 when do_ac3_passthru is enabled except it doesn't work (there are calls to autoSelectAudioTrack before do_ac3_passthru is set from the DB). So what if we prefer AC3 if do_ac3_passthru is enabled, would that be acceptable? > > > PS: there is still one more issue that needs to be resolved to get all of > > this functioning fully, that being the mpeg.c empty audio track problem. > > I am working on a better fix for this but haven't had a chance to test it > > fully. The fix involves removing the audio tracks using av_remove_stream > > the same way mpegts.c does, but finding the right spot to put it is the > > challenge. SeekReset in avformatdecoder seems like a good candiate, what > > do you think? I wrote a full explanation of the problem for Jesper if you > > are interested. > > SeekReset is called every channel change, so, yes, somewhere around there > would be appropriate. Might need some code in GetFrame() if things change > on the fly, though. > I'll sort out a patch and post it. The on the fly change is tricky, how do you detect if an audio track is no longer getting data? I had a play with it a few weeks ago and didn't get very far. Cheers, Mark Anderson > Isaac > _______________________________________________ > mythtv-dev mailing list > [email protected] > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
