<div class="gmail_quote">On Tue, Jan 31, 2012 at 12:59 PM, Jason Gillis <span dir="ltr"><<a href="mailto:spuppet@comcast.net">spuppet@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div class="im"><div><blockquote type="cite"><div style="word-wrap:break-word">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: <a href="http://www.gossamer-threads.com/lists/mythtv/users/483209" target="_blank">http://www.gossamer-threads.com/lists/mythtv/users/483209</a><br>
<br>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. <br>
<br>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.<br>
</div></blockquote></div><br></div><div><div>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.)</div>
<div><br></div><div>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.</div><div><br></div><div>
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.)</div>
<span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></blockquote><div>I recently encoded a few videos with Handbrake High profile and noticed something similar, but I didn't attribute it to Handbrake. In fact, I've not looked at the log or tracked it down. I was using a recent "nightly" build of Handbrake x64 on Windoze 7.</div>
<div><br></div><div>/Brian/ </div></div>