ashtonprairie at gmail
Jun 11, 2012, 9:39 PM
I think I've found inconsistencies in the generation of recordedseek table
Inconsistencies in generation of recordedseek table data (0.25/fixes)
data, which can affect the behaviour of the cutlist editor and transcoding
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
- 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"
Commercial Skip List:
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
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
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
(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
->Blank frames start: 21875, 46229, 59780, 74960, 91842; video end
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