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

Ken Scales ashtonprairie at gmail.com
Tue Jun 12 04:39:05 UTC 2012


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 may also be linked to the problem reported in ticket #10800:
"Inaccurate mythtranscode cuts", but I wanted to discuss it here first.

In 0.25, there are now 3 mechanisms for writing data to the recordedseek
table:
  - the original recording process
  - mythcommflag --rebuild
  - mythtranscode --buildindex

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.)

Below is an example comparison I've made based upon a sample recording
(1080i ATSC, 1:01:56 duration).

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.

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.

Running "mythutil --getskiplist --chanid 1431 --starttime 20120606135900"
gives:
   Commercial Skip List:
15442-21883,40244-46238,54123-59787,68998-74970,85273-91854,104884-111688

Using the original recording seektable values and using the cutlist editor:
   Blank frames start:  21891 (skip mark offset: +8), 46245 (+7), 59796
(+9), 74976 (+6), 91855 (+1); end frame 111402

After running "mythcommflag --rebuild --chanid 1431 --starttime
20120606135900"
   Blank frames start:  21861 (skip mark offset: -22), 46215 (-23), 59766
(-21), 74946 (-24), 91825 (-29); end frame 111373

After running "mythtranscode --buildindex --chanid 1431 --starttime
20120606135900"
   Blank frames start:  21876 (skip mark offset: -7), 46230 (-8), 59781
(-6), 74961 (-9), 91840 (-14); end frame 111388)

As an independent comparison, I ran VideoReDo on the recording, and got the
following datapoints:
   (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:  21874+1, 46228+1, 59779+1, 74959+1, 91841+1; video
end (111387+1)
 ->Blank frames start:  21875, 46229, 59780, 74960, 91842; video end
(111388)

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

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120612/62675863/attachment.html>


More information about the mythtv-users mailing list