[FFmpeg-devel] [PATCH] AVPacket.display_duration
Tue Sep 9 13:09:24 CEST 2008
On Tue, 2008-09-09 at 06:19 +0200, Michael Niedermayer wrote:
> On Tue, Sep 09, 2008 at 01:57:45AM +0300, Uoti Urpala wrote:
> > I think the best choice for FFmpeg is to use an internal storage format
> > that keeps all the timing information in demuxer packet fields like
> > display_duration when possible. Not all containers can represent such
> > timing information directly at the container level, so they have to use
> > hacks like moving it inside the codec packets or a less hacky but more
> If 1 container behaves different from every other then it should be that
> 1 that contains the workarounds not every other. Of course there could be
> a intermediate layer that fixes it up but certainly not every muxer that
> doesnt have a matroska display_duration field.
> The question of where to convert is of course independant
> of the existence of AVPacket.display_duration.
It's not just a question of which format is the most common but also
which makes the most sense internally. In some cases a certain internal
format could be a good choice even if no container used it natively.
There are 2 time positions per subtitle: when it appears and when it
disappears. If you represent each subtitle with a single packet you need
2 time values per packet. Moving one of them inside inside the codec
data is a hack and makes inspection and manipulation of the values
harder. And there is no single standard codec format to convert to. If
you want to convert for example plain ASCII subtitles to a format that
uses a packet to mark the end of a subtitle that is easiest done from a
format that keeps the display duration at the demuxer packet level.
> > It's also a format
> > that keeps sane semantics at the muxing level; moving timing information
> > inside codec packets with some codec-specific coding will cause problems
> > if you want to do even simple timing changes during remuxing.
> If, as you seem to implicate change display_duration without updating the
> timing inside the bitstream you will achive just one thing, create a broken
So it's best to use a bitstream format that doesn't keep timing inside
the bitstream. I think changing the durations would mostly work with the
Matroska bitstream format for SSA/ASS; there were a couple of special
cases where offsets could be specified in milliseconds, but mostly for
example changing the speed of a file by multiplying all timestamps and
durations by a constant should work. Obviously it would work perfectly
for all plaintext subtitles.
Note that the format Aurelien used for SSA/ASS was much worse than just
keeping the duration inside the bitstream. As I mentioned in an earlier
mail it kept absolute timestamps in the bitstream, so you could not even
cut a part from the middle of a file and move it to start at pts 0
without breaking things.
More information about the ffmpeg-devel