A fix was introduced in 43c5d3e7c9, which
adds handling for dropped frames in theora decoding. However, this
didn't handle the case where the granule position for the current packet
is invalid.
These changes introduce a check on the granule position of the current
packet. If the granule position is valid, proceed to properly calculate
the frame number and the next frame start time from the granule
position. If the granule position is not valid, use best estimation of
for these values.
These changes also refactor to combine the checks for the two cases
where the granule position is passed to theora functions. The
documentation for both of these functions states that they will return
-1 in the case that the provided granule position is negative.
Before this fix, `decodePacket` adjusted `_nextFrameStartTime` and
`_curFrame` only when `th_decode_packetin` returned `0`. But there's
another "non-error" value which can be returned by such function,
`TH_DUPFRAME` (1). This value shows up when a "dup" frame gets decoded,
meaning that playback is proceeding, but there's no need to update
`_surface` (because the contents of the decoded frame buffer have not
changed). Still, one should update `_curFrame` and
`_nextFrameStartTime` to prevent a/v/subtitle sync issues.
PR #4276 incorrectly assumed "rate" was the frame rate of the video, but it
should be the playback rate. Revert that change.
Instead, add an alternate API for fetching frame rate from TheoraDecoder.