Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Inconsistencies in generation of recordedseek table data (0.25/fixes)

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


ashtonprairie at gmail

Jun 11, 2012, 9:39 PM

Post #1 of 5 (1301 views)
Permalink
Inconsistencies in generation of recordedseek table data (0.25/fixes)

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.


J.Pilk at tesco

Jun 12, 2012, 3:51 AM

Post #2 of 5 (1226 views)
Permalink
Re: Inconsistencies in generation of recordedseek table data (0.25/fixes) [In reply to]

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

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


stichnot at gmail

Jun 13, 2012, 9:46 AM

Post #3 of 5 (1213 views)
Permalink
Re: Inconsistencies in generation of recordedseek table data (0.25/fixes) [In reply to]

On Mon, Jun 11, 2012 at 9:39 PM, Ken Scales <ashtonprairie [at] gmail> 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?

Jim
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ashtonprairie at gmail

Jun 13, 2012, 10:32 PM

Post #4 of 5 (1209 views)
Permalink
Inconsistencies in generation of recordedseek table data (0.25/fixes) [In reply to]

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

> On Mon, Jun 11, 2012 at 9:39 PM, Ken Scales <ashtonprairie [at] gmail>
> 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


ashtonprairie at gmail

Jun 14, 2012, 9:17 PM

Post #5 of 5 (1203 views)
Permalink
Inconsistencies in generation of recordedseek table data (0.25/fixes) [In reply to]

On Thu, Jun 14, 2012 at 1:32 AM, Ken Scales <ashtonprairie [at] gmail> wrote:

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

< snip >


> 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)
>
>
>
Update/correction: I've now seen this same misbehaviour in the cutlist
editor after rebuilding the seek table for another recording with
"mythtranscode --buildindex", so this is NOT related to the seek table
values generated by "mythcommflag --rebuild". In retrospect, this actually
makes sense that it would be a separate issue in the cutlist editor (and
perhaps may be addressed by some of the recent ffmpeg-related updates in
0.26).

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.