[mythtv] [PATCH] better GOP detection for HDTV

Doug Larrick doug at ties.org
Mon Dec 22 12:18:23 EST 2003


On 2003.12.22 11:47, Jason Hoos wrote:

> Seeking (ff/rw) was still funky, but then it was funky on the  
> "normal" station too.  When I told it to rewind, it seems to do  
> something more akin to pausing, and after doing that it seemed to get  
> "stuck" for a while before it finally started playing again.  I was  
> also unable to fast-forward back to "real time".  Should this be
> working for HDTV yet, and if so any suggestions as to what I should  
> look at to figure out why it isn't?

Yes, this is definitely supposed to work for HDTV (and everybody  
else :-).  When you say seeking, are you jumping (arrow keys) or ff/rew  
at 1x/1.5x/2x (<> or sticky keys)?  If your keyframes (fake or  
otherwise) are too far apart, it can get stuck at a frame in 1x ff/rew  
mode; the workaround is to go faster.

Do you see this behavior with recordings too, or just live TV?

For live TV, avformatdecoder does not get the positionmap from  
hdtvrecorder, but figures it out by watching the stream.  Watching an  
in-progress recording does some of this as well.  I'd say your problem  
is that MpegPreProcessPkt needs to look for sequence headers (instead  
of GOP) under the same set of circumstances that hdtvrecorder does.

If that's not it, to debug, I'd suggest (1) looking at your positionmap  
from the database, and (2) uncommenting debug statements in  
avformatdecoder's DoFastForward & DoRewind so you can see where it's  
trying to seek to and where it actually ends up.

-Doug
-------------- 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/20031222/622baec6/attachment.pgp


More information about the mythtv-dev mailing list