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

[John Pilkington]

On 12/06/12 05:39, Ken Scales 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 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.
>

I've added a link to this here.  My version of 0.25-fixes is getting a 
bit old.

> http://code.mythtv.org/trac/ticket/10584#comment:5

John P