[FFmpeg-devel] [PATCH] AVPacket.display_duration

[Michael Niedermayer]

On Tue, Sep 09, 2008 at 02:09:24PM +0300, Uoti Urpala wrote:
> 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.

In some cases a <put anything here> could be a good choice even if
<put anything else here>.


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


> If you represent each subtitle with a single packet you need
> 2 time values per packet.

see above


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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080910/45ddb55f/attachment.pgp>