[mythtv] [PATCH] Big DVB Patch V3.5 - MPEG TS

Tim Davies tim at opensystems.net.au
Wed Jan 12 02:40:57 EST 2005

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 :

It should have the exact same net effect as what I did.  Either way, I'm

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

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?


> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
> 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.

More information about the mythtv-dev mailing list