[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