[mythtv] [PATCH] Plextor PX-TV402 / go7007 keyframe seek fix

Nathan Lutchansky lutchann-mythtvdev at litech.org
Mon May 23 02:11:31 UTC 2005

On Mon, May 23, 2005 at 10:26:36AM +0900, Jack Porter wrote:
> This patch fixes the problem of up to a second of mpeg blockiess 
> whenever you seek in a video captured with one of these devices.
> The first frame the Plextor gives us isn't necessarily an I-frame, so 
> the seek table isn't synced with what's in the mpeg stream.  Thanks to 
> Mark Spieth for tracking down the root cause of this.   Simply throwing 
> away everything before the first I-frame lets everything start off in sync.

Yeah, I'd noticed that sometimes the MythTV captures don't start on a
keyframe.  There's actually two bugs that conspire to create this
condition.  The first is that the initial key frame at the start of an
encoding session is always huge.  Like 15-30KB.  This is because the
bitrate control is in its start state and simply allows whatever size
macroblocks the encoder feels like generating.  However, this normally
works fine.  The problem is that MythTV changes channels immediately
before starting the encoder (which is a valid thing to do), but since the
tuner is still trying to lock onto the station when the encoder produces
the first frame, the input signal is noise and a HUGE frame is generated.  
This HUGE frame overflows the ring buffer on the USB chip and the frame
header is lost, causing the kernel driver to discard the remaining data
and not start delivering data to MythTV until the second frame, which is a
P frame.

Anyway, that's way more than you probably wanted to know, but I'll see if 
I can modify the tuner driver to wait until the PLL is locked before 
allowing the encoding to start, and this will probably fix the problem.

> But unfortunately things sometimes get out of sync again for the rest of 
> the recording for some reason - perhaps if a frame is dropped.

The encoder will also attempt to detect scene changes and will insert a 
new I frame if too many intra MBs would be inserted into the P frame.  So 
even with no frame drops you're still not going to see exactly 30-frame 
GOPs in most conditions.

> My solution was to write a 'sync' frame to the nuv only when the frame 
> data written is an MPEG4 I-frame.  Why are the sync frames placed so 
> rigidly placed exactly 30 frames apart in the nuv?

Right, so this isn't going to work for the GO7007 for the reasons above.  
The GO7007 driver (and probably other V4L2 MPEG drivers) pass the frame
type through the V4L2 flags, so if that could be used to produce the sync
frames in the NUV that would probably be the way to go about it.  -Nathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050522/b25c442f/attachment.pgp

More information about the mythtv-dev mailing list