[FFmpeg-devel] [RFC] Format of packets for text subtitles

[Nicolas George]

Le primidi 21 prairial, an CCXX, Clément Bœsch a écrit :
> Maybe not setting them is disrupting lavf?

In that case, lavf prints a warning and sets the DTS to the PTS, unless I am
mistaken.

> ATM with something like ffmpeg -i in.srt -c copy out.srt, the srt muxer (a
> raw one, lavf/rawenc.c) will just copy the timing information and thus you
> are sure the timing info are the same in {in,out}.srt.

And with something like "ffmpeg -ss 42 -i in.srt -c copy out.srt", what does
happen to the timing information?

Having the timing in the packet is IMHO utterly broken.

> If even in the case of remuxing you are reconstructing the timing
> information based on the packet pts+duration (because it's now not part of
> the data anymore) you might alter the original timing.

How? AFAIK, the syntax of timestamps is completely frozen (at least for
valid files), and the arithmetic in milliseconds is completely exact.

> lavf/srtdec.c demuxer would create a CODEC_ID_SRT stream (already the
> case) that can be remuxed "verbatim" (including timing)
> 
> lavf/matroskadec.c demuxer would create a CODEC_ID_SUBRIP stream without
> the timing info in the data.

Then -scodec copy would not work from SRT to MKV, no?

> Sure, but yet, this is fairly common; we already know two subtitles
> formats with the "event last until the next one" feature. And this is
> pretty common, see for instance this (almost) randomly selected one:
> http://samples.ffmpeg.org/sub/manyfmts/FOVH%20Koala%20player.txt

It's a text format, reading the next line to get the end time is completely
trivial. We only have a problem when getting end marker requires to demux a
lot of video frames.

But it seems to be necessary anyway.

Regards,

-- 
  Nicolas George