[FFmpeg-devel] [PATCH] AVPacket.display_duration
Wed Sep 10 17:50:36 CEST 2008
On Wed, Sep 10, 2008 at 05:05:43PM +0300, Uoti Urpala wrote:
> On Wed, 2008-09-10 at 15:15 +0200, Michael Niedermayer wrote:
> > On Tue, Sep 09, 2008 at 02:09:24PM +0300, Uoti Urpala wrote:
> > > There are 2 time positions per subtitle: when it appears and when it
> > > disappears.
> > This is true for some subtitle formats, not all, there can be just 1 time and
> > duration can be until the next packet, or there can be more than 2
> > times with some changes in effects at intermediate times.
> That there are 2 relevant time positions per subtitle is true for ALL
> subtitle formats, whichever way you use to express them (single packet
> that expresses duration too or another packet to signal it, either with
> new subtitle too or without).
> > > If you represent each subtitle with a single packet you need
> > > 2 time values per packet.
> > see above
> Did you somehow miss the "If you represent each subtitle with a single
> packet"? There are formats that use another packet to signal the end and
> so only one time value per packet is enough, but I'm explicitly talking
> about the ones that use a single packet.
As you already admitted on mplayer-dev that subtitles can contain intermediate
times at which effects change and that they just dont matter because its a
rarely used feature.
I guess i dont need to comment this any further.
> > > Moving one of them inside inside the codec
> > > data is a hack and makes inspection and manipulation of the values
> > > harder.
> > We arent moving them inside, they are inside. Inspection is not hard when
> You can have a codec where it has already been moved inside, but in some
> of the most popular cases (with Matroska) it hasn't been.
> > the value is exported in a AVPacket.display_duration and manipulation needs
> > to update the internal value anyway, matroska is the only exception known to
> > me that could get away without the internal update. And iam not even sure
> > this is true for all subtitle formats one can store in matroska.
> > Now as iam not planning to drop support for other containers the update
> > of internal values will be needed in case the duration is changed.
> > If this where a terribly difficult task one could use it as argument but
> > its just a bitstream filter with a few lines of code that is needed to
> > update the times based on pts&display_duration.
> If you're going to mangle subtitle packets into a different
> representation anyway then you can use an internal format that keeps the
> timing information in packet fields only. That doesn't require "dropping
> support for other containers".
are you now arguing about the bikeshed of "what is the better internal
If aurel prefers we surely can have our matroska demuxer output unchanged
matroska-ass and have a bitstream filter to change to .ass format.
What we will not have is all muxers duplicating the matroska-ass fixup
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel