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

[Michael Niedermayer]

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.


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


[...]
> > 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


[...]
> 
> > 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?

Because it would keep you from having to update the information when it
changes within the limited subset of editing oprations you consider?

And within the broken architecture mplayer/mencoder uses ...

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

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.

[...]
-- 
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/cd6e6313/attachment.pgp>