Opened 6 years ago

Last modified 4 years ago

#7042 new defect

Wrong subtitle cut using -ss input option

Reported by: MonoS Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: subrip seek
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:
When applying an -ss offset on a srt subtitle file the resulting output file is cut at the wrong line and has the wrong offset.
Using the attached file and an -ss of 0:46:38.045 i expect the cut to happen on the 641th line with a timestamp of about 7 seconds, instead it happen on the 640th line messing up with the timecodes
How to reproduce:

ffmpeg -ss 0:46:38.045 -i
ffmpeg version N-90168-gc0919c4985

Attachments (2) (62.1 KB ) - added by MonoS 6 years ago.
Input subtitle file
log.txt (4.1 KB ) - added by MonoS 6 years ago.

Download all attachments as: .zip

Change History (6)

by MonoS, 6 years ago

Attachment: added

Input subtitle file

by MonoS, 6 years ago

Attachment: log.txt added


comment:1 by Gyan, 6 years ago

Use post-demuxer seek

ffmpeg -i -ss 0:46:38.045 -c copy

in reply to:  1 comment:2 by MonoS, 6 years ago

Replying to Gyan:

Use post-demuxer seek

ffmpeg -i -ss 0:46:38.045 -c copy

Why the output should be different between using -ss as an input or output filter in this case?

Last edited 6 years ago by MonoS (previous) (diff)

comment:3 by Carl Eugen Hoyos, 6 years ago

Component: ffmpegundetermined
Keywords: subrip seek added; subtitle ss cut removed

comment:4 by forresthopkinsa, 4 years ago

Post-demuxer seek doesn't work correctly either.

If you have two subtitles:

00:05 --> 00:15

00:15 --> 00:20

And you seek the output to start at 00:10, the output will look like this:

00:05 --> 00:10

It should include five seconds of the first subtitle line, but it instead discards it.

Note: See TracTickets for help on using tickets.