<div>I think I've found inconsistencies in the generation of recordedseek table data, which can affect the behaviour of the cutlist editor and transcoding with "--honorcutlist".</div><div><br></div><div>This may also be linked to the problem reported in ticket #10800: "Inaccurate mythtranscode cuts", but I wanted to discuss it here first.</div>
<div><br></div><div>In 0.25, there are now 3 mechanisms for writing data to the recordedseek table:</div><div> - the original recording process</div><div> - mythcommflag --rebuild</div><div> - mythtranscode --buildindex</div>
<div><br></div><div>It appears that the 3 processes generate different data for recordings (specifically in my case, 1080i ATSC recordings). I've seen this repeatedly when using the cutlist editor, and it can make a significant difference in the editing. As a result, I now run "mythtranscode --buildindex" on any recording prior to editing it, as I've found this provides the most accurate seek table. (I've set up a User Job to automate this.)</div>
<div><br></div><div>Below is an example comparison I've made based upon a sample recording (1080i ATSC, 1:01:56 duration). </div><div><br></div><div>In order to compare the different seektable results, I used a recording where the station places a "Viewer discretion is advised" warning panel prior to the blank frames following each commercial -- the transition is immediate (no fade), so the first blank frame following the commercial/panel is distinct. </div>
<div><br></div><div>Note that in 0.25, the skip-list algorithm places the mark at the midpoint of the sequence of blank frames, so the offset between the "first blank frame" number and the skip-list mark should be a negative number of frames. In the following, the numbers in parentheses are the observed offsets from the skiplist marks. </div>
<div><br></div><div>Running "mythutil --getskiplist --chanid 1431 --starttime 20120606135900" gives:</div><div> Commercial Skip List: 15442-21883,40244-46238,54123-59787,68998-74970,85273-91854,104884-111688</div>
<div><br></div><div>Using the original recording seektable values and using the cutlist editor:</div><div> Blank frames start: 21891 (skip mark offset: +8), 46245 (+7), 59796 (+9), 74976 (+6), 91855 (+1); end frame 111402</div>
<div><br></div><div>After running "mythcommflag --rebuild --chanid 1431 --starttime 20120606135900"</div><div> Blank frames start: 21861 (skip mark offset: -22), 46215 (-23), 59766 (-21), 74946 (-24), 91825 (-29); end frame 111373</div>
<div><br></div><div>After running "mythtranscode --buildindex --chanid 1431 --starttime 20120606135900"</div><div> Blank frames start: 21876 (skip mark offset: -7), 46230 (-8), 59781 (-6), 74961 (-9), 91840 (-14); end frame 111388)</div>
<div><br></div><div>As an independent comparison, I ran VideoReDo on the recording, and got the following datapoints:</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: 21874+1, 46228+1, 59779+1, 74959+1, 91841+1; video end (111387+1) </div><div> ->Blank frames start: 21875, 46229, 59780, 74960, 91842; video end (111388)</div><div><br></div><div>This is with recent versions of Mythbuntu 0.25/fixes, up to: MythTV Version : v0.25.1-2-g648f0ae from MythTV Branch : fixes/0.25</div>
<div><br></div><div>I can't say for sure that this is related to ticket #10800, but it definitely could be a factor. It probably will affect anyone using the cutlist editor, and the "--honorcutlist" transcoding option.</div>
<div><br></div><div>By the way, kudos to the developers for the improvements in the cutlist editor user interface -- it's now quite easy to use for quick editing of a recording.</div><div><br></div>