[mythtv-users] Commercial skips about 5-15 seconds early

Kevin Kuphal kuphal at dls.net
Sun Oct 16 17:57:33 EDT 2005


Chris Pinkham wrote:

>Could this have been broken for almost a year?  When the changes were
>put in to have NVP get framesPlayed from videoOutput, the line below
>was commented out in nuppeldecoder.cpp.  This is in changeset 4908.
>
>http://cvs.mythtv.org/trac/changeset/4908
>
>           else if (frameheader.comptype == 'V')
>            {
>                lastKey = frameheader.timecode;
>                //framesPlayed = frameheader.timecode - 1;
>
>                if (!hasFullPositionMap)
>
>We later backed out the change right below the one I've quoted above.  In that
>change, the changset commented out a "framesPlayed++;", I wonder if we should
>have reverted this one as well.
>
>When using the null video output, NVP gets its framesPlayed from the decoder
>directly.  The flagger never seeks (after initial logo detection), so its
>value for framesPlayed (from nvp->GetRawVideoFrame()->frameNumber) just goes
>up one by one as framesPlayed is incremented in the decoder.
>
>When playing the recording normally and skipping around (whether manually or
>using NVP::AutoCommercialSkip()), the framesPlayed may take jumps since
>it is being recalculated in the decoder everytime we seek.
>
>Kevin, Can you uncomment the line above in nuppeldecoder.cpp?  It's on line
>968 in HEAD.  That will cause the framesPlayed to be set based upon the sync
>frame we just saw and should cause the framesPlayed to line up between the
>player and other programs that don't seek like the flagger.  I think you'll
>also need to apply the attached patch to the flagger to get it to cope
>with the jumping frame numbers.  Basically, it just inserts dummy records
>into the frameInfo map and pretends the missing frames were blank.
>
>Make a note of what the commercial skip markers are set to for the sample
>recording and then rerun mythcommflag and check to see if it caused the
>frame numbers for the commercials to change.  If they did, they should be
>higher now if you had missing frames in the video.  If they are, try
>watching the program again and see if it skips in the right place this
>time.
>
Ok.  I applied this patch and the uncomment change to my remote frontend 
(for completeness, this is does *not* include the change we made before 
to initialize framesPlayed and use an incrementer).  I noted the cutlist 
that was generated by the previous run of mythcommflag and I ran the 
patched mythcommflag from my remote frontend against the program in 
question.  Results:

Before:
0 - 2136
22107 - 28738
43179 - 49673
61868 - 68459
77060 - 84056
93179 - 100204
105639 - 108048

After:
0 - 2548
22145 - 29518
43257 - 50398
61981 - 68588
77195 - 85198
93340 - 101548
105834 - 108048

It now begins the skip at the correct point but seems to skip too far by 
about 12 seconds or so.  You'll notice that while the start skip 
increased by about 73 frames, the end skip increased by about 700 or so, 
ie: the duration of the commflag changed as well as the start point with 
this change.  It seems that if the duration had stayed the same but the 
start point increased as it did, this would have been a perfect skip as 
I usually find.

Kevin


More information about the mythtv-users mailing list