Seek in ffmpeg decoder doesn't work for files with negative AVStream start_time

Submitted by zealcharm on Sun, 2019-02-17 13:08

Forums:

Hello,

I have a lot of MKV files (audio+video) that play correctly with MOC, but can't be seeked, with neither normal nor silent seek. Most of those files have been obtained from Youtube using youtube-dl. After playing a bit with the logging options, I found that a "Seek too large" message was printed in the console from within the ffmpeg.c decoder.

After checking the associated code, there is an overflow check on ffmpeg.c, that assumes that ffmpeg's AVStream start_time is always positive or zero. This doesn't seem to be the case, as some files can have a negative start_time (see for example https://stackoverflow.com/questions/41032079/ffmpeg-start-time-is-negative ). I don't have any file that I can upload as an example at this moment, though it appears that youtube-dl (as I use it most of the time, which is "youtube-dl --add-metadata http://...") generates a lot of those. .

I am currently testing a patch that also checks the possibility that ffmpeg's AVStream's start_time is negative in the overflow check, and it appears to fix the problem, from some quick testing:

Index: decoder_plugins/ffmpeg/ffmpeg.c =================================================================== --- decoder_plugins/ffmpeg/ffmpeg.c (revision 2994) +++ decoder_plugins/ffmpeg/ffmpeg.c (working copy) @@ -1190,7 +1190,10 @@ data->stream->time_base.num); if (data->stream->start_time != (int64_t)AV_NOPTS_VALUE) { - if (seek_ts > INT64_MAX - data->stream->start_time) { + // Check for overflow, before updating the timestamp: + // https://stackoverflow.com/questions/2633661/how-to-check-for-signed-integer-overflow-in-c-without-undefined-behaviour + if ((data->stream->start_time > 0 && seek_ts > INT64_MAX - data->stream->start_time) || + (data->stream->start_time < 0 && seek_ts < INT64_MIN - data->stream->start_time)) { logit ("Seek value too large"); return false; }

Regards.

jcf

Mon, 2019-02-18 00:38

Your patch looks good to me, but I'm not sure it's the whole story.

Are you able to determine whether data decoded from negatively timestamped frames gets returned to MOC or is it just consumed in the decoding process? (The referenced post suggests it does not get displayed for video, but it's not clear whether or not it is the FFmpeg libraries which implement this.)

If that's the case, then maybe seeking on such files might need to be limited to zero as an earliest seek time rather than the negative start time. I don't know if FFmpeg does that anyway, or if it might fail because of the missing "lead in" frames. (An examination of ffplay(1) code doesn't help; it doesn't even protect against overflow.)

However, I would expect such negative start times to be quite small and probably unnoticable anyway.

zealcharm

Tue, 2019-02-19 07:35

Those two videos should work for testing:
https://zealcharm.soon.it/MocFfmpegStartTimeTestVideo1.mkv
https://zealcharm.soon.it/MocFfmpegStartTimeTestVideo2.mkv

More info and tests later.

jcf

Wed, 2019-02-27 00:30

This patch has been committed as r2995 (MOC 2.5) and r2996.