[FFmpeg-user] Understanding the behavior of "-ss/-t" option
nitishsprabhu at gmail.com
Sat Sep 9 07:30:41 EEST 2017
On Fri, Sep 8, 2017 at 5:34 PM, Gyan <gyandoshi at gmail.com> wrote:
> ffmpeg -seek_timestamp 1 -copyts -ss 1 -i src.mp4
> produces a file, reported as,
> Duration: 00:00:01.00, start: 2.000000, bitrate: 276 kb/s
> whose video contents correspond to TS 2 to 3 of src.mp4, (frame counter
> 25). 'ss' acts as relative offset, and is apparently immune to
> seek_timestamp. Source timestamps are copied over to output.
On Fri, Sep 8, 2017 at 2:53 PM, Nicolas George <george at nsup.org> wrote:
> After further testing, it seems the -ss option is itself relative to the
> file's start time: by setting -ss 60 with a file that starts at 60, you
> are asking to seek to timestamp 120. And with -copyts, you get that
> Therefore, the problem is that [120;130[ \cup [60;70[ = \emptyset, not
> [0;10[ as I said before.
Thanks for sharing your observations an insights. I am now able to get
a better understanding of ffmpeg's behavior for "-ss/-t".
To summarize the observations, "-ss/-t" does not operate on timestamps
directly but operates on the relative offset from the start of the
file (even when "-seek_timestamp" is enabled).
>From the best of my understanding, when "-seek_timestamp" is enabled,
as the documentation says "-ss" should operate on timestamps rather
than relative offsets. So, this may be a bug, or we might have to
change the documentation with a relevant correction (probably stating
in which case "-seek_timestamp" works).
More information about the ffmpeg-user