[FFmpeg-devel] [PATCH] AVPacket.display_duration

Måns Rullgård mans
Tue Sep 9 01:53:56 CEST 2008

Aurelien Jacobs <aurel at gnuage.org> writes:

> Uoti Urpala wrote:
>> On Mon, 2008-09-08 at 21:50 +0200, Michael Niedermayer wrote:
>> > On Fri, Sep 05, 2008 at 05:35:13PM +0200, Aurelien Jacobs wrote:
>> > > For some subtitles track, each AVPacket must carry the display duration
>> > > of the contained subtitle.
>> > > The attached patch adds a dedicated AVPacket.display_duration field.
>> > 
>> > Iam not against this, but i would like to understand better for which cases
>> > it is needed.
>> > 
>> > plain UTF-8 and ASCII ?
>> > If so does mov, avi, asf, ... support plain UTF-8 and ASCII ?
>> > if yes how do they know the display_duration ?
>> In http://roundup.mplayerhq.hu/roundup/ffmpeg/issue588 you compare the
>> subtitle situation to video and do not see why it would need something
>> different. However the subtitle formats that exist in practice DO need
>> something extra.
>> A video frame implicitly lasts until the next frame overwrites it,
> That's where you're wrong. The next frame *don't* overwrites the previous
> one. It only modify it (in case of predictive frames).
> And the exact same situation happens with subtitles. Let's see the
> following example with subtitles A and B:
>   A - start: 2 - end: 8
>   B - start: 6 - end: 10
> Here, subtitle B don't "overwrite previous frame", it only modify it
> (by adding one more subtitle line on the screen...).
> Now, the display duration of subtitle A is exactly comparable to
> the duration a video frame has effect on the following frames
> (ie. until further frame don't reuse any data derived from the
> original frame, which is often until next key frame).
> And this duration is never stored in container for video frames,
> it's stored in the video bitstream itself. So it don't sound
> very strange to do the same thing for subtitle streams.

This is DVD subtitles work.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list