[mythtv-users] Seek problems with Handbrake 0.9.5 high profile encodings

Jason Gillis spuppet at comcast.net
Tue Jan 31 17:59:38 UTC 2012


On Jan 25, 2012, at 2:08 PM, Jason Gillis wrote:

> Hi all,
> 
> I'm having trouble with seeking in encodings of videos that have been created using Handbrake 0.9.5 and the "High Profile" preset.  I don't have problems with recordings (HD-PVR and HDHR), ISOs, or other video files.  This seems to have been discussed before on the list, but it doesn't look like it was completely resolved.  The previous discussion is here:  http://www.gossamer-threads.com/lists/mythtv/users/483209
> 
> On my system, seeking forward always seems to work fine, but seeking back will go back differing amounts.  The amount it goes back seems to be somehow dependent on how long it's been since a seek back event occurred.  That is, it's fairly accurate when I've seeked back recently (i.e. I seek back once, it takes me a long distance back in the recording, the next seek takes me back about the 5 seconds I expect).  If no seek back has happened recently, when I seek back it can go 10 - 15 minutes back.  
> 
> The old thread seems indicate that some people saw relief upgrading to 0.24, but since I'm already on that, I'm not sure where to look next.  I don't recall this being a problem until relatively recently, but I don't know exactly when it started.  Probably in the November/December timeframe.  I've tried rebuilding the seek tables using mythcommflag, but that doesn't seem to have helped either.

I've been experimenting with different encoding options in Handbrake to see what options change this behavior (and I'm finally seeing the real benefit of an i7! :).  It seems like nothing I do for an .m4v file type seems to help.  Choosing the normal or high profile doesn't seem to make much difference.  (Normal might result in less drift from real time, though.)

I did find today that an MKV container instead of a .m4v results in no drift.  I also don't see any messages in the -v playback logs about video getting ahead of the audio.

Is there anyone out there that could confirm this behavior, or perhaps confirm that there might be issues with processing of .m4v files? (I'm assuming ffmpeg handles that, so I'll do some searching about that.)

J

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120131/2533416d/attachment.html 


More information about the mythtv-users mailing list