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

Michael Niedermayer michaelni at gmx.at
Thu Aug 2 17:32:25 CEST 2012

On Thu, Aug 02, 2012 at 04:40:33PM +0200, Nicolas George wrote:
> 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.

MPEG-PS and TS require demuxer timestamps only to be periodically
stored not on every frame and there is no requirement for frames to
have equal or predictable durations beyond what the codec syntax
allows. So yes one has to use either them or nothing in these cases

> 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.

hmm, my concern was with removial not about adding vs not adding.

> 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?

no, i mean that if you scale times in mpeg2 its frame rate field upon
which various fields are based would be wrong, this would break
playback-ability in some cases and still be "just wrong" in the rest
so scaling times of many videos requires changing the codec bitstream
mpeg1/2/4 and h264 fall in this category at least so iam not sure
how much is gained by avoiding this need for subtitles.
In reality scaling times and ignoring the inconsistency may of course
just happen to workout with some containers and players but this
doesnt mean one can do it without creating inconsistencies in the
files. That is this is not a subtitle specific issue ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- 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/c2f02153/attachment.asc>

More information about the ffmpeg-devel mailing list