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

Tim Davies tim at opensystems.net.au
Wed Jan 12 20:19:58 EST 2005


Here's the results of my testing of transform.c/h.

This is using the avformatdecoder.cpp patches from Mark and the one line AC3
change in dvbrecorder.cpp.  No patches to mpeg.c and using software AC3.
Yep, a bit of a mouthful!

Recording the TS:  (I took out the incCurrentAudio bit for this)

- No patch: results in 30 and 70 video being a bit funny on a channel
change.  The rest is fine.
- Mark's patch: makes changing to channels 30 and 70 worse, no audio and
very choppy video.  The subsequent channel change is affected, then it's
good again.  Hmm...this sounds familiar!
- Marcus' patch: makes the video and audio very choppy on every channel.

Not recording the TS:

- No patch: no AC3!  Channels with only AC3 soundtracks are choppy.
- Mark's patch: has magical video stripes and can't change channels.  Audio
seems okay.
- Marcus' patch: doesn't do anything.  The frontend gives up.

I doubt this helps much...


Tim.



> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
> On Behalf Of Mark Anderson
> Sent: Thursday, 13 January 2005 6:18 AM
> To: Development of mythtv
> Subject: Re: [mythtv] AC3 + bigdvb3.5 + australia + transport.c
> 
> On Wed, 12 Jan 2005 09:15 am, Mark Anderson wrote:
> 
> I fixed the audio in trandsport.c, unfortunatley I screwed up the video.
> Attached is the diff as it stands, anyone see anything obvious causing the
> video screw up?
> 
> The diff is applied againts the original transport.c and no mpeg.c hack is
> needed.
> 
> Cheers,
> Mark.
> 
> > Folks,
> >
> > After a number of hours starting at hex dumps and trying. to learn a bit
> > about mpeg/dvb protocols I have finally found the problem with
> transport.c,
> > unfortunately I haven't been able to craft some code that actually fixes
> > it.
> >
> > The problem: The 9th byte of the mpeg2 data is the header length, in
> > australia for AC3 payload this is always set to 7 bytes. The code in
> > transport.c only ever puts 4 of the 7 bytes into the transformed stream.
> > mpeg.c looks at the header length and makes sure it pulls out that many
> > bytes:
> >
> > The code in mpegps_read_pes_header is:
> >
> >     len -= header_len;
> >         while (header_len > 0) {
> >             get_byte(&s->pb);
> >             header_len--;
> >         }
> >
> >
> > Because transform has not put the last three bytes of the header in,
> mpeg.c
> > pulls out the wrong bytes and everything goes downhill from there. I
> have
> > confirmed that if transport puts the full 7 bytes in the it all works
> fine.
> >
> > I added the following code to write_ipack in transport.c to try to fix
> > this:
> >
> >  /*write in the rest of the header as specified by p->hlength*/
> >         if ((p->cid == PRIVATE_STREAM1) && (p->count == 13))
> >         {
> >                 while (p->count < (p->hlength + 9))
> >                 {
> >                         p->buf[p->count++] = data[p->count - 13];
> >                 }
> >         }
> >
> > This almost does it except there are 3 additonal bytes after the four
> byte
> > streamid/ac3_off header. If I hack mpeg.c to pull the extras out it
> > produces perfect audio. The reason the extra three bytes are added due
> to
> > the above code is that it adds the reast of the header, but since
> > write_ipack has no way of telling the caller that it has used up some
> bytes
> > out of its source buffer, the bytes are re-added in the next call to
> > write_ipack.
> >
> > Marcus, since you are much more familiar with this code, maybe you could
> > work out how to get the proper header bytes added?
> >
> > Cheers,
> > Mark Anderson



More information about the mythtv-dev mailing list