[FFmpeg-devel] [PATCH 2/3] textdec: Rename all generic parts from srt to text.

[Nicolas George]

Le sextidi 16 thermidor, an CCXX, Michael Niedermayer a écrit :
> Some additional comments
> - we do not remove timestamps from video streams like h264 or mpeg2
>   they contain various, also h264s various timestamps are possibly
>   too complex
>   to remove and too deeply integrated to remove even if we wanted.
>   there are picture order counts various SEIs that contain timing
>   stuff, GOP in mpeg2 that does, ...

I trust you on this, but are these timestamps user anywhere outside the
decoder really as timestamps.

Also, I am not considering _removing_ timestamps from the stream: I want to
stop adding them. If you look at an ASS stream in a Matroska file, the
packets have a timestamp and a duration as part of the EBML structure like
any other packet, and there is no timestamp in the payload data of the
packet. The Matroska demuxer in lavf rewrites the payload data to add the
timestamp in it in text form. I hope you agree this is completely absurd.

What I am proposing, for demuxers, amounts to:

- for multimedia demuxers (Matroska, nut, etc.) remove, as much as possible,
  all special cases concerning subtitles;

- for text subtitles demuxers, be compatible with the multimedia demuxers.

I do not see how anyone could disagree with that.

> - considering such complex timestamps, does similar exist in
>   subtitles ? i mean for example things deeper in the syntax refering
>   to some timestamps ? like <blink start="11:23:90">this</blink> ?

If such a format happens to exist, I would say:

- This is braindead. We have to deal with it, but that does not prevent us
  from insulting whoever invented it.

- Stream copy with time shift or time scaling would not be possible for this
  format.

- The decoder would have to convert the absolute timestamp to a relative
  one: <blink start="11:23:90"> becomes {\blink(45)}, assuming the packet's
  timestamp is 11:23:45; the encoder would do the opposite.

> - The problem with scaling timestamps or cutting applies to video too

Do you mean keyframes, or something else?

> - Can the case occur / has it been considered that a container can
>   store subtitles with their own i stream timestamps and
>   different/inconsistent timestamps at the demuxer layer.
>   Iam mentioning this because if you remove the timestamps from the
>   subtitle bitstream what do you do if they dont match the demuxer
>   provided timestamps to begin with ? 

I am not aware of a format plus subtitle codec where the timestamp is
present both in the format structure and in the stream payload.

(Except Nut produced by ffmpeg from ASS, but that could be considered just a
bug.)

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120802/791f4ab3/attachment.asc>