[FFmpeg-user] Understanding the behavior of "-ss/-t" option

[Nitish Prabhu]

On Fri, Sep 8, 2017 at 5:34 PM, Gyan <gyandoshi at gmail.com> wrote:
> Running
>
>         ffmpeg -seek_timestamp 1 -copyts -ss 1 -i src.mp4
> copyts-seekts-ss1.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
> timestamp.
>
> Therefore, the problem is that [120;130[ \cup [60;70[ = \emptyset, not
> [0;10[ as I said before.
>

Gyan, Nicholas,

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).

Thanks!