[FFmpeg-devel] [PATCH] AVPacket.display_duration

Uoti Urpala uoti.urpala
Wed Sep 10 19:07:32 CEST 2008


On Wed, 2008-09-10 at 18:15 +0200, Michael Niedermayer wrote:
> On Wed, Sep 10, 2008 at 04:48:03PM +0300, Uoti Urpala wrote:
> > On Wed, 2008-09-10 at 15:00 +0200, Michael Niedermayer wrote:
> > > 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. 
> 
> Ok, sorry i already suspected you mean something else as i didnt really
> consider the .ass spec to be that monolithic.
> 
> 
> > It's already meant for
> > multimedia 
> 
> so .ass is not meant to be viewed?

It was not meant to be included in a multimedia work in "source" form.
IIRC it (or more precisely the original SSA) was a format meant for a
hardsubbing tool. The end result was a hardsubbed file.

> > 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.
> 
> seems ass does work in containers ...

In practice it's used in Matroska, which doesn't use packets matching
lines in .ass files. And of course you could make the format "work", but
that doesn't mean it would be a good design.

> > You wouldn't try to mux subtitles using exact
> > parts of some OpenOffice file.
> 
> ive never seen videos with subtitles in open office files, i think you
> should upload a sample, tell us what player supports it and provide a
> url to the spec. Then we can discuss about OpenOffice subtitles.
> failing that i think you shouldnt troll.

You can create plaintext subtitles in OpenOffice (not that different
from plain ASS subs), but you still wouldn't want to take the packet
format directly from OpenOffice.

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

You didn't give any examples...

> > 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.
> 
> I can also say that every 3rd byte should be xored with 'u' still that doesnt
> make it a good idea nor the simplest / minimum change solution.
> if one has to transform something that transform should be minimal in general.
> Do not do more than is needed to achive the goal.
> We also could convert .ass to openoffice files (to pick your own ridiculous
> comparission).

I think considering the codec without the timestamps is a rather natural
thing to do.

> > > > 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. 
> 
> wrong, the difference in the original is the display_duration
> it still is in a packet, this is not a reinterpretation.

You're reinterpreting the meaning of the fields if you say the "start
time" field does not mean start time and "end time" field does not mean
end time. In the original version "0:00:00.00,0:01:00.00" is definitely
different from "0:17:11.23,0:18:11.23". In your version they mean the
same. You couldn't use a packet with the semantics from your version as
line in an .ass file. No program could interpret them the same; you'd
need to know which version you're dealing with. You could just as well
use a completely different representation for the duration.

> > 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"?
> 
> Are you now making things up to use them as arguments?
> Nut stores codecs unchanged or with minimal changes so no such
> reinterpretation would be done.

How does that differ from the reinterpretation of the time fields? The
parsing program would need different logic in either case. From a
decoder's point of view the difference between an .ass line and a
Matroska ASS packet is about the same as the difference between an .ass
line and your proposed format.





More information about the ffmpeg-devel mailing list