[mythtv] [mythtv-commits] Ticket #1356: DTVRecorder::FindKeyframes in 0.19 causes video gltiches in firewire recordings

[Jim Westfall]

Steven Adeff <adeffs.mythtv at gmail.com> wrote [02.22.06]:
> On 2/21/06, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> > On 2/21/06, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> > > On 2/20/06, MythTV <mythtv at cvs.mythtv.org> wrote:
> > > > #1356: DTVRecorder::FindKeyframes in 0.19 causes video gltiches in firewire
> > > > recordings
> > > > -----------------------+----------------------------------------------------
> > > >  Reporter:  anonymous  |       Owner:  ijr
> > > >      Type:  defect     |      Status:  new
> > > >  Priority:  minor      |   Milestone:
> > > > Component:  mythtv     |     Version:  0.19
> > > >  Severity:  high       |
> > > > -----------------------+----------------------------------------------------
> > > >  In 0.18.1, DCT6200 firewire recordings work fine. In 0.19, a video glitch
> > > >  occurs every few seconds. I replaced the DTVRecorder::FindKeyframes in
> > > >  0.19 with the code in 0.18.1 modified to work with the changed signature.
> > > >  The video glitches went away. DVB recordings work fine in both 0.18.1 and
> > > >  0.19.
> > >
> > > did you notice the glitches when using test-mpeg2? I have a similar
> > > issue where my glitch rate within MythTV SVN is much higher than with
> > > test-mpeg2, I'm going to give your patch a go against 0.19 and let you
> > > know how it works out for me. Thanks for looking into this!
> >
> > well, so far so good, about 1hr of tv and I haven't noticed a glitch
> > at all so far, which is great. I'll let you know if I notice any or
> > see any other oddities that were not there prior to the patch.
> 
> after even more testing I've found that this completely solves the
> glitch problem I've been having running SVN up to 0.19. I've yet to
> notice a the glitches I was getting quite often before.
> 

when looking at both sets of code there is one thing that stands out as 
not being right.  The use of tspacket->data() as if its going to return a 
pointer to the start of the entire 188 byte tspacket.  Its like this in 
both versions of FindKeyFrames, plus a number of locations.

The TSPacket class doesnt define a data() function so its getting picked 
up by TSHeader::data(), which returns a pointer to _tsdata[4].  Accesses 
past the 4th byte are overflowing and seems to just be a fluke its working 
since _tsdata[4] and tspayload[184] appear to be next to each other in 
the stack.

jim