<div class="gmail_quote">On Wed, Jun 13, 2012 at 12:46 PM, Jim Stichnoth <span dir="ltr"><<a href="mailto:stichnot@gmail.com" target="_blank">stichnot@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="im">On Mon, Jun 11, 2012 at 9:39 PM, Ken Scales <<a href="mailto:ashtonprairie@gmail.com">ashtonprairie@gmail.com</a>> wrote:<br>
> I think I've found inconsistencies in the generation of recordedseek table<br>
> data, which can affect the behaviour of the cutlist editor and transcoding<br>
> with "--honorcutlist".<br>
<br>
</div>This is very interesting. Do you see the problem with 720p recordings<br>
as well, or just 1080i?</blockquote><div><br></div><div>Good question, Jim! I didn't have an answer, so today's project was to check it out. We only have one English language station here that broadcasts in 720p (CBC), so my experience with ATSC 720p has been limited. I recorded a 1-hour block, and repeated the same tests I reported for 1080i. Results below.</div>
<div><br></div><div>In summary, "mythtranscode --buildindex" provides the best results for me for this format as well. In second place would be the recordedseek table generated by the original recording process. 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><br></div><div>Here are my test results for recordedseek table data on a 720p ATSC recording:</div><div><br></div><div><div>Running "mythutil --getskiplist --chanid 1041 --starttime 20120613155900" gives:</div>
<div> Commercial Skip List: 0-3490,20926-31810,50900-62980,88253-101523,137034-146118,154504-163262,175882-185857,197534-207204</div><div> </div><div>Using the original recording seektable values and using the cutlist editor:</div>
<div> Blank frames start: 3503 (skip mark offset: +13), 31793 (-17), 62963 (-17), 101503 (-20), 146099 (-19),</div><div> 163253 (-9), 185843 (-14), 207185 (-19); end frame 228831</div><div><br></div><div>After running "mythcommflag --rebuild --chanid 1041 --starttime 20120613155900"</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>After running "mythtranscode --buildindex --chanid 1041 --starttime 20120613155900"</div>
<div> Blank frames start: 3485 (skip mark offset: -5), 31775 (-35), 62945 (-35), 101485 (-38), 146081 (-37)</div><div> 163235 (-27), 185825 (-32), 207167 (-37); end frame 222814</div><div><br></div><div>Running VideoReDo on the recording, here are the results:</div>
<div> (Note: VideoReDo counts frames starting at 0, so the framecounts need to be incremented by 1 for comparison with the cutlist editor)</div><div> Blank frames start: 3484+1, 31774+1, 62944+1, 101484+1, 146080+1, 163234+1, 185824+1, 207166+1; video end 222813+1 </div>
<div> ->Blank frames start: 3485, 31775, 62945, 101485, 146081, 163235, 185825, 207167; video end 222814</div></div><div><br></div></div>