[mythtv] AC3 + bigdvb3.5 + australia + transport.c

Mark Anderson markjanderson at mail.com
Fri Jan 14 18:54:44 EST 2005


<snip>

> > > 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.
>
OK, I have fixed it. I removed the code to switch tracks in GetFrame and 
changed mpeg.c to re-use the existing audio track when the codec changes. 
This means mpeg.c only supports one audio track, but the rest of myth has 
that problem anyway (except for TS recording of course.)

I have now tested this on both PS and TS recording. I set one card to be TS 
and one to be PS so I can test this problem properly. 

This is the first time I have used TS recording and I like it. HD stations 
work (except seven which runs in slow motion!!???) and I can switch between 
audio tracks.

Will post a patch later 'cuase I gotta go out now.

Mark



<snip>


More information about the mythtv-dev mailing list