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

[Chris Pinkham]

> >If the frame numbers in the editor match the frame numbers in the commercial
> >skip list, and the frame numbers displayed when AutoCommercialSkip skips
> >match those as well, then the frame number during playback must not be
> >matching the frame number you see when in edit mode (or when the flagger
> >plays frame-by-frame through the video).  Does this sound like what's
> >happening or did the video skip at the right place (visually) when you
> >printed out the frame numbers above.
> >  
> >
> This sounds like what is happening based on what I saw above

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.

-- 
Chris

-------------- next part --------------
Index: programs/mythcommflag/ClassicCommDetector.cpp
===================================================================
--- programs/mythcommflag/ClassicCommDetector.cpp	(revision 7495)
+++ programs/mythcommflag/ClassicCommDetector.cpp	(working copy)
@@ -112,6 +112,7 @@
 
     currentAspect = COMM_ASPECT_WIDE;
 
+    lastFrameNumber = -2;
     curFrameNumber = -1;
 
     if (getenv("DEBUGCOMMFLAG"))
@@ -651,6 +652,19 @@
     fInfo.format = COMM_FORMAT_NORMAL;
     fInfo.flagMask = 0;
 
+    // If we somehow skipped frames, pretend they were blank.
+    if (lastFrameNumber != (curFrameNumber - 1))
+    {
+        fInfo.flagMask = COMM_FRAME_BLANK;
+
+        lastFrameNumber++;
+        while(lastFrameNumber < curFrameNumber)
+            frameInfo[lastFrameNumber++] = fInfo;
+
+        fInfo.flagMask = 0;
+    }
+    lastFrameNumber = curFrameNumber;
+
     frameInfo[curFrameNumber] = fInfo;
 
     if (commDetectMethod & COMM_DETECT_BLANKS)
Index: programs/mythcommflag/ClassicCommDetector.h
===================================================================
--- programs/mythcommflag/ClassicCommDetector.h	(revision 7495)
+++ programs/mythcommflag/ClassicCommDetector.h	(working copy)
@@ -120,6 +120,7 @@
 
         bool verboseDebugging;
 
+        long long lastFrameNumber;
         long long curFrameNumber;
 
         int width;