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

[Michael Niedermayer]

On Thu, Sep 11, 2008 at 02:01:38AM +0300, Uoti Urpala wrote:
> On Thu, 2008-09-11 at 00:31 +0200, Aurelien Jacobs wrote:
> > Evgeniy Stepanov wrote:
> > > I like this patch in general. If the demuxer is that intelligent, ReadOrder is 
> > > not needed at all.
> > 
> > Good.
> > I guess I will just apply it when I switch to lavf matroska demuxer by
> > default again.
> 
> I'm not sure whether you read my reply your patch yet; there were at
> least two things wrong with it.
> 

> > Hum... I have nothing against ReadOrder ! The only problem with ReadOrder
> > is that it don't fit in spec compliant ASS, so I wasn't able to put it
> > in. And as it's pretty much useless, that's not really a problem.
> 
> If you read the latest discussion even Michael seems to have accepted
> that your "spec compliant" format may not be an optimal one.

I think the .ass spec compliant format is the best choice for ffmpeg and
mplayer to use internally. And as i already said, i have no strong objections
to using a different format as long as it contains display_duration one way
or another if the matroska demuxer maintainer prefers it.
Still i think using a different format will bite us in the future


> 
> > > If a container does not support packet durations, it's muxer can rebuild 
> > > .ass format or whatever.
> > 
> > So virtually every muxer would need to rebuild .ass format (or anything
> > containing display_duration) except matroska.
> > On the other hand, when using standard .ass as an interchange format
> > between muxers/demuxers/decoders, only matroska has to do some specific
> > handling.
> 
> Currently the Matroska format can be muxed unmodified into at least one
> container.

The matroska format can only be muxed into matroska, there is currently
no other container in which it could be muxed


> Any other format can be muxed into zero.

The .ass one can be muxed into most containers, it may not be supported
by many players of course but thats something else. compare that to
the matroska format which can NOT be stored as is.
Also a format following the .ass spec stored in .avi is much more
likely to be supported than one which replaces 2 fields by duration
and ReadOrder


> Even if the other
> containers do not use the Matroska format that doesn't mean they'd all
> use whatever other format you pick. So there's no guarantee that any
> other format would result in less rebuilding, and at the moment it would
> certainly result in more. A format that keeps the values in demuxer
> packet fields without duplicating them in bitstream is better for
> program architecture.

if, if, if then ...
well normally codecs are stored with a minimum of reformatting
There are various practical reasons why, mjpeg in avi really are jpegs
one of course could remove parts of their header because they are
redundantly storing the width & height.
mpeg1, 2, 4, h264, ... also contain various fields that are redundant
and that could be removed when they are stored in avi, asf, nut, mkv
then mp3 stored the samplerate in its header, still this part of the
header is not removed in containers that have their own samplerate
in the header.

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/20080913/7a1f25bb/attachment.pgp>