<div class="gmail_quote">On Thu, Jun 14, 2012 at 1:32 AM, Ken Scales <span dir="ltr"><<a href="mailto:ashtonprairie@gmail.com" target="_blank">ashtonprairie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im"> I found that the results with "mythcommflag --rebuild" had several problems: not only did the seek table not line up very well with the skiplist values, but seeking within the cutlist editor had significant misbehaviours, making editing a very frustrating experience. See my note below regarding the seeking misbehaviours. Based upon this experience, I definitely do not recommend using "mythcommflag --rebuild" for 720p ATSC recordings in current 0.25/fixes builds; use "mythtranscode --buildindex" instead.</div>
</div></blockquote><div><br></div><div>< snip ></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div> After running "mythcommflag --rebuild --chanid 1041 --starttime 20120613155900"</div>
<div>
<div> Blank frames start: 3470 (skip mark offset: -20), 31760 (-50), 62930 (-50), 101470 (-53), 146066 (-52),</div><div> 163220 (-42), 185810 (-47), 207152 (-52); end frame 222799</div><div><br></div></div></div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div class="gmail_quote"><div><div>However, seeking within the cutlist editor exhibited odd behaviour: e.g., attempting to move to the next cut point would only move 1 frame at a time forward or backward, until the cut point was finally found, and then would do the expected skip to the next cut point. Similarly, once the above "first" blank frame had been located, attempting to move by a single frame backward would result in an unexpected jump of several frames back: </div>
</div><div><br></div></div><div class="gmail_quote"><div><div> Moving 1 frame back skips: 3470->3463 (7 frames), 31760->31747 (13), 62930->62926 (4), 101470->101458 (12), 146066->146053 (13),</div></div>
</div>
<div class="gmail_quote"><div><div> 163220->163216 (4), 185810->185806 (4), 207152->207142 (10)</div></div></div></blockquote><div class="gmail_quote"><div><div><br></div></div></div></blockquote><div><br></div>
<div>Update/correction: I've now seen this same misbehaviour in the cutlist editor after rebuilding the seek table for another recording with "mythtranscode --buildindex", so this is NOT related to the seek table values generated by "mythcommflag --rebuild". In retrospect, this actually makes sense that it would be a separate issue in the cutlist editor (and perhaps may be addressed by some of the recent ffmpeg-related updates in 0.26).</div>
<div><br></div></div>