Okay, I've tested out the dvbrecorder.cpp change and it works fine. Although, I'd write the line like this ;-)
pmt[p++] = (*es).Type == ES_TYPE_AUDIO_AC3 ? STREAM_TYPE_AUDIO_AC3 : (*es).Orig_Type; It should have the exact same net effect as what I did. Either way, I'm happy. I still had to remove the incCurrentAudioTrack bit of Mark's patch. It causes problems on SBS HD and Seven HD; I think these are the two HD services that offer both MPEG *and* AC3 audio tracks. But, I get audio buffer overruns anyway if I change to Seven HD. I think this is 6 channel AC3 (the demo loop). Before the buffer overruns I get "dropping back audio_buffer_unused" output from mythfrontend. Is the software AC3 having a cow here? If you exit and watch live TV again, all is good. I did notice that the time scale is all screwed up in recordings with an AC3 soundtrack. A 2 hour recording might register as 15 minutes long. It makes for some interesting fast forwarding and rewinding! Recordings with MPEG audio only are fine. At least with my quick testing. Does the code use the soundtrack to do the timings/length calculations? Setting "use video as timebase" doesn't change anything. Any thoughts? Tim. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Tim Davies > Sent: Wednesday, 12 January 2005 7:12 AM > To: 'Development of mythtv' > Subject: RE: [mythtv] [PATCH] Big DVB Patch V3.5 - MPEG TS > > Right, timezones suck! Sleeping while everyone else is awake is a pain in > the butt... > > Chopping up about 5 emails here: > > > Are you using SPDIF passthrough? If you are not, i.e using software AC3, > > then > > the audio rates and channels will be differenent between stations which > > will > > be enough for check audio params function to pick up the changed audio > > type > > and re-initialise. When using SPDIF passthrough the audio is set to 2 > > channel > > 48000, which also happens to be what we get from the mpeg audio, and so > a > > test on rate and channel is not enough to detect the changed audio type. > > This > > mught explain why I need the incCurrentAdio stream change and you do > not. > > I'll have a look to see if there is a smater way to do this that will > work > > with both. > > Yes, I'm using software AC3. I've been holding off buying a receiver > until > this code works (strangely enough). It's interesting that incrementing > the > current audio stream causes mine to freak out. > > > Yeah, the current descriptor handling is kinda quick and dirty. I > > haven't analyzed the patch that deeply, but I don't think it is safe. I > > tried using dynamically allocated memory at first too, but since we are > > storing it inside a QT object which gets passed around and copied and > > what not, we end up with several copies of the object which all point to > > the same memory. When the destructors are called, the first one will > > destroy the data and the other objects are left with undefined data at > > best and probably a segfault. > > > > I think we should create a new "Descriptor" object which can be stored > > in a QValueList DescriptorList or something. That object then needs to > > ensure that if the object is cloned, the data is cloned as well. > Opinions? > > Yep, agree on that one. I was getting hairs on the back of my neck > standing > on end as I wrote the reallocs... > > > You can look at the CreatePMT() in dvbrecorder.cpp code and its possible > > changing the one line where (*es).Orig_Type is written to the PMT to > > something > > like this. > > > > if ((*es).Type == ES_TYPE_AUDIO_AC3) > > pmt[p++] = 0x81; > > else > > pmt[p++] = (*es).Orig_Type; > > > > Give this a shot and let me know if this solves your issues.. > > I'll take any advice on this one. I just worked back from mpegts.c and > found that not all descriptors where making it through. I'm happy to do > the > "hack" in dvbrecorder.cpp. > > > Yeah, but anyway, that is another issue and not really related to Tim's > > AC3 patch. The PMT stream type fix should be perfectly safe but I'm not > > sure if that's enough for AC3 to work or if the other parts of the patch > > (descriptors, avformatdecoder and mpeg hack) are needed as well...? > > Okay: > > - Reading all the descriptors was needed to identify that the private > stream > was actually AC3. > - The audio track changing code in Mark's patch is used, but the > mpeg.c/transform.c hacks are not. > > > So where are we on this? Sorry, I still haven't woken up yet...brain not > on... > > > Tim.
_______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
