[mythtv] num of frames played vs nvp->GetTotalFrameCount()

[Daniel Walton]

On Tue, 30 Jan 2007, Chris Pinkham wrote:

> * On Thu Jan 25, 2007 at 02:04:47AM -0500, Daniel Walton wrote:
> > I have a recording of an ABC HD show that is one hour long and according to
> > nvp->GetTotalFrameCount() is 158700 frames:
>
> I think a couple different things are coming into play.  I believe there
> is still code in the editor that will not let you seek within a certain
> distance of the end of the recording.  This is by design and dates back a
> long time, so it may not even be required anymore, but I'm not 100% sure.

k, I'll take a look at that part of the code.

>
> There is also a minor difference in how frames are calculated which
> may affect frame numbers on corrupted files.  It appears that the
> new/experimental commercial flagger just increments frame numbers as it
> goes through.  If there are any corrupted or missing frames in the file,
> they may not get counted with this method.  When you seek, the decoder's
> frame counter gets reset based on the keyframe distance and the keyframe
> number that you jumped to.
>
> If you look in ClassicCommDetector, you'll see that I do the following
> to set the current frame number:
>
>     VideoFrame* currentFrame = nvp->GetRawVideoFrame();
>     currentFrameNumber = currentFrame->frameNumber;
>
> That way I'm syncing my frame numbers with the decoder's frame counter.
>
> I'm not sure if this totally explains why your frame numbers are off,
> but it is a couple things that I ran into while I was going through the
> same process with the existing commercial flagger.  In the beginning,
> I'd see that the blank frame detector said frame X was blank, but when I
> tried to view that frame in the editor, I'd see that the player thought
> it was frame Y (usually higher than X).

This is exactly the problem I'm seeing, commdetector2 says frame 1000 is blank
but when I use the editor to go through frame by frame it is actually frame 1000
+ some delta.

> Once I switched my code to using currentFrame->frameNumber instead of just
> doing currentFrameNumber++ ever frame, the accuracy was much better.

cool, I will give this a try.  Thanks Chris

Daniel