You can demonstrate the overflow using ffplay and this opus file:
https://storage.googleapis.com/chcunningham-chrome-shared/bear-opus.webm
Before patching, try:
ffplay -ss 2 bear-opus.webm
Notice that, in spite of the seek to 2 seconds, the file plays back from
time 0. After patching, re-run and find that the playback begins from the 2
second time.
On Thu, Jul 21, 2016 at 12:01 PM, Chris Cunningham <
chcunning...@chromium.org> wrote:
> When seeking a file where codec delay is greater than 0, the timecode
> can become negative after offsetting by the codec delay. Failing to cast
> to a signed int64 will cause the check against skip_to_timecode to evaluate
> true for these negative values. This breaks the "skip_to" seek mechanism.
> ---
> libavformat/matroskadec.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index f3d701f..60b1b34 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3150,7 +3150,10 @@ static int
> matroska_parse_block(MatroskaDemuxContext *matroska, uint8_t *data,
>
> if (matroska->skip_to_keyframe &&
> track->type != MATROSKA_TRACK_TYPE_SUBTITLE) {
> - if (timecode < matroska->skip_to_timecode)
> + // Compare signed timecodes. Timecode may be negative due to
> codec delay
> + // offset. We don't support timestamps greater than int64_t
> anyway - see
> + // AVPacket's pts.
> + if ((int64_t)timecode < (int64_t)(matroska->skip_to_timecode))
> return res;
> if (is_keyframe)
> matroska->skip_to_keyframe = 0;
> --
> 2.8.0.rc3.226.g39d4020
>
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
