[MPlayer-dev-eng] [PATCH] libass: fix parsing of tracks extracted from containers

[Michael Niedermayer]

On Mon, Sep 15, 2008 at 11:32:59PM +0300, Uoti Urpala wrote:
> On Mon, 2008-09-15 at 16:52 +0300, Ivan Kalvachev wrote:
> > So the stuff I don't understand.
> > 
> > 1. Is "Block's timecode" the only PTS that this packet have?
> 
> Yes.

No, it is not and you know that as you admited already that there are
other time related fields that are not removed by matrska-ass
ill quote the spec for ivan and others:
--------------------
\k<duration>           <duration> is the amount of time that each section
               of text is highlighted for in a dialogue event with the
               Karaoke effect. The durations are in hundredths of seconds.
...
\t([<t1>, <t2>, ] [<accel>,] <style modifiers>)

                             <t1>, <t2> Animation beginning, ending time offset [ms] (optional)

                             <accel> Modifies the linearity of the transformation (optional)
...
\move(<x1>, <y1>, <x2>, <y2>[, <t1>, <t2>])

                             <x1>, <y1> The coordinate to start at.
                             <x2>, <y2> The coordinate to end at.
                             <t1>, <t2> Animation beginning, ending time
...
\fade(<a1>, <a2>, <a3>, <t1>, <t2>, <t3>, <t4>)


                <a1> Alpha value before <t1>
                <a2> Alpha value between <t2> and <t3>
                <a3> Alpha value after <t4>
                <t1>, <t4> Animation beginning, ending time offset [ms]
                <t1> - <t2> Alpha value will be interpolated between <a1>
                  and <a2>
                <t2> - <t3> Alpha value will be set to <a2>
                <t3> - <t4> Alpha value will be interpolated between <a2>
                  and <a3>

\fad(<t1>, <t2>) <t1> the time length of fading in
                <t2> the time length of fading out
--------------------

I really honestly think, uoti you are going a little too far with this
missinformation compaign.
ASS is defined in the ass spec, it has many timestamps, and i myself
have seen the karaoke highlight effect so it isnt rare either.

Matroska picks 2 of the timestamp fields and removes them from the ass
lines, the other timestamps are not changed or removed, this still results
in a codec & container timestamp mix, that surely will not become any
less problematic if your idioitc suggestion of changing the "packet"
timestamp without fixing the bitstream is applied. That is no matter
which of the suggested systems is used, in all cases do the ass packets
need to be edited if timestamps change.


> 
> > 2. Why do we want the demuxer to mess with the string (aka, data, aka payload) instead of just passing it. In other words, why do we dump useful data?
> 
> I'm not 100% sure what you mean with this question. Do you mean why
> Aurelien wants to convert the format from the one normally used by
> Matroska? I think he wants to "standardize" on his own version of the
> format and hopes to use a single internal format which doesn't need
> conversions to/from containers that use his version (though currently no
> container does and there's little evidence they would in the future).

aurel wants to move the 2 timestamps that matroska removes from standard
.ass back where the .ass spec says they should be.
The format aurel wants is described in the specification of .ass files,
it is not his format. Also exactly this format is used in nut.

convertion between .ass and .mkv will need convertion of the format
whereever it is done, doing it in the mkv demuxer means nut and other
formats like avi could use the packets directly.


> 
> > 3. If "Block's timecode" is stored in AVPacket.pts and "Block's duration" is stored in AVPacket.convergence_duration, doesn't that mean we have everything we need for muxing?
> 
> Aurelien's use of convergence_duration was mistaken and he should have
> used another field (probably waited for a patch adding display_duration
> to be applied); but yes, all the information should be available in the
> packet fields, and having it in the bitstream is completely redundant
> for an internal format. 

So you propose that a .ass demuxer removes these fields?
The fact that .ass and .mkv use a different format leaves no choice
either one converts or the internal format is ambigous.
Now if one must convert why should that be the .ass and not mkv demuxer?


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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- 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/mplayer-dev-eng/attachments/20080918/878ac45a/attachment.pgp>