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
_______________________________________________
mythtv-users mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
