[FFmpeg-devel] [PATCH] AVPacket.display_duration

[Uoti Urpala]

On Wed, 2008-09-10 at 15:00 +0200, Michael Niedermayer wrote:
> On Tue, Sep 09, 2008 at 01:44:39PM +0300, Uoti Urpala wrote:
> > On Tue, 2008-09-09 at 06:07 +0200, Michael Niedermayer wrote:
> > > I also do not know if this is the best solution, the obvious alternative
> > > to display_duration is to have the matroska demuxer convert the codec
> > > bitstream to a representation that contains the display_duration.
> > > It seems that for all subtitle formats such representations exists, ASS as
> > > well as plain text (SRT).
> > 
> > If you mean that there would already exist a variant of the bitstream
> > format that specifies the duration, not really. The format Aurelien used
> > for ASS was taken from the line specification of the document describing
> > monolithic .ass files that are meant to be read as a unit; 
> 
> what we store in h264 AVPackets matches what is written in the spec for
> "monolithic" .h264

It's not "monolithic" in the sense I mean. It's already meant for
multimedia and divided into packets etc. .ass files are meant to be read
as a whole. Their parts aren't designed to be suitable for use as
packets, and they aren't. You wouldn't try to mux subtitles using exact
parts of some OpenOffice file.

> > AFAIK that
> > format is not used for packets anywhere. 
> 
> see nut or for the matter any other container supporting ass/ssa, raw .ass
> being one at least that also stores them that way

What container actually has existing files with such a format?

There is no "raw" .ass (it's not a codec). The .ass files described by
the spec do not store anything as packets. If you want to interpret them
in terms of multimedia containers then you can say the timestamp part
belongs belongs to the ".ass container" and the ".ass codec" has no
timestamps.

> > And it is not well suited for
> > such use, as it specifies not duration but both starting time and end
> > time, _as absolute timestamps_.
> 
> I dont know about you but i can subtract absolute timestamps to get a
> relative one. So start and end time is as good as duration.

You can subtract them, but then you're reinterpreting the format in a
way that doesn't match the original meaning any more. How far would you
take that and still claim to be using something matching lines in
an .ass file? "We're using exactly the same format as a line in .ass
files. However, in nut you must remember to interpret the x coordinate
field as font size, and the y coordinate field as border width"?

Nothing uses such an interpretation of the fields. It certainly doesn't
match lines in the .ass spec. You could not write lines with such
interpretation into an .ass file and expect it to work.

> Of course this does not mean that iam against adding a display_duration
> field to AVPacket, iam just saying that what AVPackets should contain should
> match the codec spec (= .ass here) unless there are strong reasons to do
> something else.

.ass is no codec. The closest thing to a "codec spec" is the Matroska
one. There are strong reasons to do something else.