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

[Uoti Urpala]

On Wed, 2008-09-10 at 16:30 +0200, Michael Niedermayer wrote:
> On Wed, Sep 10, 2008 at 04:21:25PM +0300, Uoti Urpala wrote:
> > On Wed, 2008-09-10 at 13:55 +0200, Michael Niedermayer wrote:
> > > On Sun, Sep 07, 2008 at 06:23:11PM +0300, Uoti Urpala wrote:
> > > > And even if you thought lavf users wouldn't need it, dropping the
> > > > information when you remux mkv->mkv is bad unless you can be sure nobody
> > > > anywhere has a use for it (which I think they do).
> > > 
> > > If readorder contains information that is usefull for a realistic case
> > > Then we can try to find a way to export it.
> > > Though that requires some realistic use case to be found first.
> > 
> > It allows easily comparing a .ass file that has gone through muxing to a
> > multimedia container and back to one that hasn't. I've done that even
> > though I haven't done much related to editing subtitles.
> 
> running both through sort before comparing allows that too.

Sorting also destroys the structure of the file.
 
> > Your attitude seems to be "We're not too familiar with the area where
> > this information could be useful, but we'll assume it is useless and
> > delete it from files muxed though FFmpeg unless someone who knows better
> > actively comes to tell us why we shouldn't do that". I think you should
> > at least do some checking before deciding to delete information that has
> > been deliberately added to the files.
> 
> Your attitude seems to be "I know its useless but i will troll about it
> anyway"

Do you really consider yourself familiar enough with subtitle work that
you know better?

> [...]
> > > vorbis packets also contain their duration.
> > 
> > They contain their number of samples. But you don't need that duration
> > to time any display changes. Nothing special happens when the duration
> 
> You where suggesting to remove all timing information from the bitstream,
> try to remove it from vorbis and mpeg2

Vorbis and mpeg2 have no comparable timing information in the bitstream.
I think the explanations I've written about that really should be good
enough...
 
> > > 2. its based on the assumtion that there are just start and end time.
> > >    Iam not sure if there really is no subtitle format that cannot apply
> > >    some effects at intermediat times, and these times would be in the
> > >    codec bitstream, it would be rater messy to attempt to move this to
> > >    demuxer packets.
> > 
> > Yes if there a lot of other information then it has to be left inside
> > the bitstream in practice. Actually SSA/ASS can have offsets from
> > start/end in milliseconds for move effects, but they're not used often
> > AFAIK. Instead of adding fields to demuxer packets you could represent
> > those as percentage of duration instead so any linear transformation of
> > the timeline would always work without editing the packets. Anyway I
> 
> uhm, so you suggest now to have _all_ demuxers and muxers convert ass
> subtitles or actually all subtitles to uoti-subs? start and end at demuxer
> level and everything else as percentages of the duration?

No I do not suggest doing that in practice. That was in response to your
"would be messy to move this to demuxer packets" and shows that demuxer
packets still wouldn't need extra fields. But I do not consider such
"intermediate times" to be a significant enough issue to matter at the
moment. I think the Matroska format is good enough for SSA/ASS in
practice.

> just cut a file and merge the cutted parts differently you still will have
> to update the subtitle bitstream.

Why would you have to if you don't use a format that keeps timestamps
inside the bitstream? If you have some nontrivial effect then it might
require codec-specific modification to cut it halfway, but the usual
case should not require changing packets.

> It may surprise you but we do not disagree that much about a cleanup
> of subtitle information, it is rather the place where it is done that
> we disagree about.
> 
> What i proposed a while ago (and you apparently missed) is that all subtitles
> demuxed by demuxers should be converted into a unified representation by the
> subtitle decoders, then this unified representation could be rendered by a
> renderer to a displayable bitmap. The unified subtitle also would be easy to
> edit and could be again by an encoder be encoded to a specific subtitle format
> like ass or srt.

Creating a new "unified representation" would basically require
designing a new subtitle format (if it wouldn't be ASS), and it'd need
to have all the complexity of ASS. That alone would be a fairly big
task; trying to do it as just a part of a player implementation cleanup
sounds overly ambitious.