[mythtv-users] Seek problems with Handbrake 0.9.5 high profile encodings
Jeremy Jones
jeremy.dwain.jones at gmail.com
Tue Jan 31 19:49:50 UTC 2012
On Tue, Jan 31, 2012 at 11:59 AM, Jason Gillis <spuppet at comcast.net> wrote:
>
> 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
>
If this is a recording that was already in the database (recorded
using mythtv) then you need to re-build the seek tables after running
handbrake to transcode.
See:
http://www.mythtv.org/wiki/Repairing_the_Seektable
The line: mythcommflag --file <filepath> --rebuild
should do the trick.
If this is a new video file, just being dropped into mythvideos, then
I'm afraid my answer may be irrelevant, and I can't help.
Good luck,
Jeremy
More information about the mythtv-users
mailing list