[mythtv] DVB Changes / Patch Applied

[Tim Davies]

As far as I can see, this patch (oz-ac3.diff) does at least four things:

> 1) wantac3 setting in the setup
> 2) make the PS autopid use <1>
> 3) make AvFormatDecoder::autoSelectAudioTrack use <1>
> 4) deal with codec changes (?)
>
> <1> & <2> looks conceptually good to me although I'd implement it 
> slightly differently, partly because I'm planning on removing the 
> preferredFooStream hack completely and move that logic into 
> dvbrecorder. I'd also call it "ac3wanted" or something to make it sort 
> together with "ac3passthrough". I also have an idea for the 
> dvbrecorder which, if it works, will make it possible to record 
> multiple audio streams with PS recording too and then we won't need 
> <2> any more. I think this would also eliminate parts of the tracksel 
> patch. Once Taylor gets things going with the followup patch I'll try 
> and sort this part out...
>
> I haven't looked that much at the rest of the patches (ffmpeg and the 
> avformatdecoder is pretty much new territory to me) but you've seen 
> what Isaac said. I think it would help if you could identify more 
> clearly exactly what the problems are and how to fix them. And trim it 
> down and split it up in distinct parts. Maybe some more comments? I'd 
> like to help but I don't understand the patch yet and my time is a bit 
> limited. :(

I guess 1,2,3 are all to do with getting the preferred track into the 
recording and then chosen for playback.  It is quite common here to have 
both an MPEG2 and AC3 audio track in a service.  The ideal solution (for 
me) is for both the PS and TS to record  both audio tracks, and then one 
is auto selected on playback but can be overridden by the user. I'm sure 
some would disagree though :-p.

Part 4 is the important bit.  It reinits the audio if it detects a codec 
change, as well as (what it did previously) detect the change in sample 
rate and/or the number of channels.

There were a couple of extra bits as well, like not aborting when a 
decoder wasn't found.  I'm not sure whether Mark did this just while 
testing, but I know from experience that the frontend would crash if it 
did abort.  If you have multiple tracks, you'd really want to see if you 
can decode the another one before giving up entirely.

Does anyone else out there have multiple audio tracks?  I would have 
thought this kind of thing would be a necessity...

I'm also a bit reluctant to do too much; this is Mark's baby - I'm just 
pushing it along...


Tim.