[FFmpeg-devel] [PATCH] AVPacket.display_duration
Wed Sep 10 18:15:39 CEST 2008
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:
> > 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.
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
so .ass is not meant to be viewed?
> 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 ...
> 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.
> > > 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).
.ass files are "raw" ass.
> 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
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
> > > 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.
> 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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel