Thanks for the tip Nicolas. Well, -copyts works fine when you're re-encoding at full speed.
But when used in combination with -re, as shown below, it prevents the input from being "fast-seeked" to the desired position. So, it's kind of useless. ffmpeg -re -copyts -ss 20:10.00 -i input.mp4 -vf subtitles=subs.srt \ -c:v libx264 crf 25 -c:a aac -ab 160k \ -strict experimental \ -f flv $RTMP_URL I'm not intimate enough with the code to tell if that's a bug or an inherent limitation of -copyts. OTOH, the shift option added to the subtitles filter with the patch does not prevent fast-seeking. And you also have the added benefit of adjusting subtitles delay without having to rewrite them. Regards, Manolis On Mon, 4 May 2020 at 11:38, Nicolas George <geo...@nsup.org> wrote: > Manolis Stamatogiannakis (12020-05-03): > > I've noticed what appears to be a bug/missing feature in the subtitles > > filter: when "-ss" is used for the input, it is not applied to the > > subtitles stream. E.g., for the following command line, the video > playback > > will start on 20:10, but the subtitles will start from 00:00. > > You can use -copyts to keep the timestamps of the video matching with > the subtitles. > > Regards, > > -- > Nicolas George > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".