Opened 5 years ago

Closed 5 years ago

#1573 closed enhancement (invalid)

Enhancing -ss option

Reported by: burek Owned by:
Priority: wish Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Consider the following example command line:

ffmpeg -ss 00:03:00 -i input -vframes 1 out.jpg

The result will be 1 image frame somewhere around 3rd minute, depending on gop size of the input, at the last found keyframe, but the seeking will be extremely fast.

Now consider this line:

ffmpeg -ss 00:02:30 -i input -ss 00:00:30 -vframes 1 out.jpg

The output will be the exact image frame at the 3rd minute of the input and the seeking will be very fast for the first 2 and a half minutes, following the slow seeking (frame-by-frame) for the next 30 seconds, resulting in the combination of the fast and accurate seeking.

My question is if the -ss input option (before -i) can be enhanced in such a way that it automatically adds another -ss output option (after -i) which will compensate for the difference between the last found keyframe and the user specified seek time.

For example, if the last found keyframe in that input was at 00:02:57, the result should be the same as if the user has typed:

ffmpeg -ss 00:02:57 -i input -ss 00:00:03 -vframes 1 out.jpg

I hope you get my point. The idea is to seek as fast as possible until the last keyframe in the specified interval and then to slowly seek to the precise time point, specified by user, all automatically, without users having to investigate the input to find out the last keyframe's position.

Change History (6)

comment:1 Changed 5 years ago by Cigaes

ffmpeg seeks backward by default, which means that if it can not seek exactly to 00:02:47, it will seek to 00:02:45 rather than to 00:02:50. So I believe what you want can simply be achieved using:

ffmpeg -ss time -i input -ss 0 output

OTOH, this does not seem to be frame-accurate, there seems to be a very small difference. Strangely, it does not appear on the showinfo filter.

comment:2 Changed 5 years ago by burek

I'm not sure I understand what is the purpose of -ss 0 in your example? The idea is to seek fast (using keyframes) for the most part and then to slowly (accurately) seek to the precise point in time, using -ss after the decoding of frames. As I understand, your example just seeks to the last key frame in specified time, but it doesn't seek accurately to that time point?

comment:3 Changed 5 years ago by Cigaes

The -ss time option at input adjust the timestamps according to the target time, not the approximate time where a keyframe has been found. Therefore, after -ss time has done its work, timestamp 0 is where you wanted your video to start, and you have extra frames before. The -ss 0 will precisely skip to that point.

comment:4 Changed 5 years ago by burek

I hear this for the first time so far. Where can I check it and read more about it, to make sure I understand what is actually going on here?

comment:5 Changed 5 years ago by jbvsmo

Hi, I'm working on a project with multiple ffmpeg processes converting parts of a video at the same time and the speedups I'm achieving are amazing.

But, for this to work, I rely on fast seek, otherwise the slow seek makes the method useless. The problem is that

ffmpeg -ss time -i input -ss 0 output

doesn't always give me the right frame!

I found in the mail list (here and here) that ffmpeg may reach a frame after the specified time and never go back.

Are there any chances of a really accurate and fast seek in a single option? BTW, seek by frame number is possible?

The ffmpeg version I'm using is from git on September 12 (2 weeks before ffmpeg 1.0).

comment:6 Changed 5 years ago by cehoyos

  • Resolution set to invalid
  • Status changed from new to closed

I don't think this is a valid ticket:
The original request suggests to change the behaviour from "seek as fast as possible if requested by the user" to "do not seek as fast as possible, no matter what the user wants" which does not seem like a good idea.
And there is a possible bug report, but it is incomplete / impossible to reproduce.

Note: See TracTickets for help on using tickets.