On Fri, Sep 8, 2017 at 5:34 PM, Gyan <[email protected]> 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 <[email protected]> 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! _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
