[mythtv-users] Inconsistencies in generation of recordedseek table data (0.25/fixes)

[Ken Scales]

On Wed, Jun 13, 2012 at 12:46 PM, Jim Stichnoth <stichnot at gmail.com> wrote:

> On Mon, Jun 11, 2012 at 9:39 PM, Ken Scales <ashtonprairie at gmail.com>
> wrote:
> > 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".
>
> This is very interesting.  Do you see the problem with 720p recordings
> as well, or just 1080i?


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.

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.

Here are my test results for recordedseek table data on a 720p ATSC
recording:

Running "mythutil --getskiplist --chanid 1041 --starttime 20120613155900"
gives:
   Commercial Skip List:
0-3490,20926-31810,50900-62980,88253-101523,137034-146118,154504-163262,175882-185857,197534-207204

Using the original recording seektable values and using the cutlist editor:
   Blank frames start:  3503 (skip mark offset: +13), 31793 (-17), 62963
(-17), 101503 (-20), 146099 (-19),
      163253 (-9), 185843 (-14), 207185 (-19); end frame 228831

After running "mythcommflag --rebuild --chanid 1041 --starttime
20120613155900"
   Blank frames start:  3470 (skip mark offset: -20), 31760 (-50), 62930
(-50), 101470 (-53), 146066 (-52),
      163220 (-42), 185810 (-47), 207152 (-52); end frame 222799

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:

   Moving 1 frame back skips: 3470->3463 (7 frames), 31760->31747 (13),
62930->62926 (4), 101470->101458 (12), 146066->146053 (13),
      163220->163216 (4), 185810->185806 (4), 207152->207142 (10)


After running "mythtranscode --buildindex --chanid 1041 --starttime
20120613155900"
   Blank frames start:  3485 (skip mark offset: -5), 31775 (-35), 62945
(-35), 101485 (-38), 146081 (-37)
      163235 (-27), 185825 (-32), 207167 (-37); end frame 222814

Running VideoReDo on the recording, here are the results:
   (Note: VideoReDo counts frames starting at 0, so the framecounts need to
be incremented by 1 for comparison with the cutlist editor)
   Blank frames start:  3484+1, 31774+1, 62944+1, 101484+1, 146080+1,
163234+1, 185824+1, 207166+1; video end 222813+1
 ->Blank frames start:  3485, 31775, 62945, 101485, 146081, 163235, 185825,
207167; video end 222814
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120614/ca51c3fc/attachment.html>