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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
