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

[Michael Niedermayer]

On Wed, Sep 10, 2008 at 07:28:14PM +0300, Uoti Urpala wrote:
> On Wed, 2008-09-10 at 17:26 +0200, Michael Niedermayer wrote:
> > On Wed, Sep 10, 2008 at 03:24:33PM +0300, Uoti Urpala wrote:
> > > On Wed, 2008-09-10 at 13:32 +0200, Michael Niedermayer wrote:
[...]
>  
> > > > nut does not have ReadOrder.
> > > 
> > > Just to make it gratuitously incompatible with Matroska? Or because you
> > > were confused by the nonexistent ".ass codec format"? If you can't use
> > > the Matroska format directly at least design a sane one (adding a
> > > duration field to the Matroska format is an obvious choice, and allows
> > > lossless conversion between the containers).
> > 
> > no, nut uses the format as described in the .ass spec. We will not mess
> > with it in any way beyond the minimum needed to store it. Its the same with
> 
> You earlier said that you would NOT use the semantics given for lines in
> the .ass spec.

no i did not say this.


> Instead of interpreting the first two fields as the start
> and stop time you would interpret their difference as duration

yes that is the same as the ass spec says duration = end-start


> from the
> start time given at demuxer level.

the start time in the bitstream and at the demuxer level
match, and if they do not the file is broken and its up to the player to
decide what to do.


> If you do that you're not using
> semantics compatible with lines in .ass files any more.

> Couldn't you
> just as well specify that the first field should be interpreted as
> duration and second as ReadOrder? That would give a more practical
> result (no need to pointlessly calculate the difference), would allow
> keeping ReadOrder, and would have no disadvantages over the "difference"
> format (no decoder could interpret either format the same way as lines
> from .ass files anyway, and the differences would be no harder to
> handle).

I do not have any strong objections to this, though i do not really
see what good this would do. ReadOrder is not terribly usefull and
duration is known from both start & end.

Anyway i will leave this to aurel to decide if he prefers this as output
from our matroska demuxer


[...]
> > 2. do the job halfway or actually less than that, by just extracting the
> >    start & end time, while leaving the actual text and intermediate times
> >    in the packet
> 
> I'm not sure what you mean by "leaving the actual text". What would
> qualify as "not leaving"? Turning it to pictures? I think that's a
> completely separate issue from extracting timing information.

putting it in char *.
Use cases would be
* converting to other subtitle formats
* speech synthization (maybe for vissually impaired people and i dont
  mean totally blind just people who can recognize the main parts of a movie
  but not read the subs)
* atomatic spell checking

Of course one could do all of the above with ass itself but that would then
not work when the input is a different format.


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

The worst form of inequality is to try to make unequal things equal.
-- 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/20080910/e54d8e19/attachment.pgp>