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

[Uoti Urpala]

On Thu, 2008-09-11 at 01:05 +0200, Aurelien Jacobs wrote:
> Uoti Urpala wrote:
> 
> > On Tue, 2008-09-09 at 16:32 +0200, Aurelien Jacobs wrote:
> > > Here we have 2 different formats. One which can contain the subtitle display
> > > duration through the mean of start time and end time (aka .ass format) and
> > > one which can't store this information (aka matroska's ass format).
> > 
> > Actually we have only one existing muxed format: the Matroska one. What
> > you called the ".ass" format and wanted to use internally in demuxer
> > packets is [...]
> 
> parsed and decoded by any ASS decoder out there.

They parse complete .ass files. Players don't play streams consisting of
packets with your proposed format.

> > > The only format left is standard .ass format (unless you can show me another
> > > more popular format which can store display duration by itself).
> > 
> > As explained above your ".ass format" is only a popular format for
> > complete files, not for subtitle packets.
> 
> And by the fact that any ASS decoder already have anything needed to
> decode it.

Only to the extent they'd have "anything needed to decode" any similar
format containing about the same information.

> > > I don't say that standard .ass is perfect or anything, but that's the least
> > > worst format we have which contains display duration, and no one came up
> > > with anything better up to now.
> > 
> > An obvious less-broken alternative for muxing into containers which
> > cannot keep duration at the container level is to modify the Matroska
> > format to add duration inside the packet. So instead of your absolute
> > start time and absolute stop time there would be only duration relative
> > to the start time, and start time would be specified by the
> > container-level pts.
> 
> I agree that storing only the duration instead of start and end time
> in muxed packet would have some small advantages. And if there were a
> specification and wild acceptance for such a format in the ASS community,
> I would probably have picked this one.
> But I certainly don't want of a new ffmpeg/MPlayer specific format that
> won't be recognized by most ASS parser/muxers/...

You ARE creating a lavf-specific format that is not used by anything
else.

> I'm definitely fed-up with this discussion which won't bring us anywhere,
> so I will sum-up my position one last time:
>  - I won't accept using format that don't contain display_duration
>    (in one way or another) as an interchange format between
>    muxers/demuxers/decoders.

Why does the interchange format have to contain that when duplicating
the information makes things more difficult?

>  - I also won't accept a format that don't have a formal spec and a
>    wild acceptance.
>  - I am totally open to a format containing a duration (instead of start
>    and end time) and a ReadOrder, as long as it meats above requirements.
> 
> Now, if you really care that much about this issue, you can simply
> write some spec for the perfect format of your dream (ensuring it meats
> above requirements), promote it and get it accepted by the ASS
> development community. I will then be happy to implement this new
> superior format in lavf.

Do you understand why no specification for how to store ASS in
containers without duration fields exists? Because people aren't using
ASS in such containers! Yet you expect there to already exist a spec
suitable for that. If you want "wild acceptance" you need to have a use
case - IOW you'd need to get people to start using ASS in other
containers.

> And if you don't care enough... Why should I ?

Because you are the one proposing to use a format different from
Matroska for the sake of other containers. People aren't using it in
other containers yet. So if you want to start you have to create a
format suitable for it.

You can NOT expect there to already exist a "wildly accepted" spec for
something that is not being done at all! Nor can you expect there to be
even good common practice. So your insistence on an already established
standard is completely unreasonable.

If you want to create a standard for using ASS in all containers then do
it right. Don't expect to be able to pick from existing accepted
practices, because there are no practices for something that is not
being done. If you don't care enough to do it right then at least don't
break things worse by doing it wrong.