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

[Tim Davies]

Well, it seems my assumption with AC3 and the messed up timing on the
recordings isn't right.  I did some tests (only once each):

Chan    Video    Audio     Time OK
-----------------------------------
1       576i    MP2&AC3    no
2       576i    MP2&AC3    no
3       576i    MP2        yes
7       576i    MP2        yes
9       576i    MP2&AC3    no

You can see how I was getting to the conclusion, but now the HD streams:

12      1080i    AC3      no
20      1080i    AC3      no
30      576p     MP2      no
70      576p     MP2&AC3  yes
90      1080i    AC3      no
 
I don't see a pattern there.  Maybe there is just something wrong with the
code that gets the video timings wrong in a transport stream.  I haven't
tried to understand that (yet!).

I was thinking that the Aussie AC3 "hack" is probably better in
dvbrecorder.cpp as the recorded stream is then in a format that can be
transcoded easily.  And mpegts.c is untouched.  And it is simpler.  Any
opinions against doing it that way?

I fixed the audio buffer problems with extra audio buffering, but I still
get slightly stuttery video when I change to channels 30 or 70 from another
channel.  No errors in the logs.

These are the progressive scan channels, so maybe that is the common factor.
It isn't evident when you start watching on these channels.  And I have
played with the deinterlace settings (a lot!), but it doesn't change.

Where to start looking?


Tim.
 

> -----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 3:41 PM
> To: 'Development of mythtv'
> Subject: RE: [mythtv] [PATCH] Big DVB Patch V3.5 - MPEG TS
> 
> 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: 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.
>