Mythtranscode exits out after sending 1st frame

[Geoffrey Hausheer]

I have a very old recording (circa 2004, .nuv format recorded with PVR250 I think). It plays fine in myth, but when I tried to transcode it, mythtranscode exited after sending the 1st frame.

I debugged it to this: The second time through MythPlayer::TranscodeGetNextFrame?

lastDecodedFrameNumber = videoOutput->GetLastDecodedFrame()->frameNumber;

returns -1 since lastDecodedFrameNumber is uint64_t, it becomes a very large number. Later we do this:

        if (totalFrames && lastDecodedFrameNumber >= totalFrames)
            return false;

which fires because lastDecodedFrameNumber is > totalFrames.

When I changed lastDecodedFrameNumber to a signed int64_t and changed the above check to

        if (totalFrames && lastDecodedFrameNumber >= (int64_t)totalFrames)

Transcoding worked fine. The proper solution may be for GetLastDecodedFrame?() to not return a frame number of -1, but I don't know enough about the video buffers to go any further.

I can provide the original nuv if needed, but it is about 1GB. I can try trimming it down to see if I can reproduce with only a portion of the file as well.

[Github]

Handle decoded frame number of -1 more gracefully

Fixes #9699. The proposed fix in the ticket has been implemented. As the frameNumber can be -1, the type of lastDecodedFrameNumber must be signed. This is to fix a premature exit during transcoding, but it quite likely could rear its ugly head in other contexts too.

A better permanent fix would be to treat the special case of frameNumber == -1 and deal with it specifically.

Thanks to ghaushe for the find.

Changeset: 3721bc0a1c6c0b4b109abf61c24d91a2ce879e1f