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 <[email protected]> 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
> [email protected]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> [email protected] with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
