[MPlayer-dev-eng] [PATCH] Dolby TrueHD support for mkv demuxer

[Aurelien Jacobs]

On Fri, Aug 07, 2009 at 02:20:34AM +0300, Uoti Urpala wrote:
> On Thu, 2009-08-06 at 23:18 +0200, Aurelien Jacobs wrote:
> > On Thu, Aug 06, 2009 at 10:24:57PM +0300, Uoti Urpala wrote:
> > > On Thu, 2009-08-06 at 19:38 +0200, Aurelien Jacobs wrote:
> > > > There is no know breakage with this patch !
> > > 
> > > That's just your lack of knowledge then.
> > 
> > Maybe because you didn't informed me ! I'm impatient to know !
> > 
> > > The part about it breaking the
> > > internal demuxer should be obvious.
> > 
> > And the fix which was already committed as r27529 is as obvious !
> 
> It doesn't fix caching subtitles over seeking.

Seeking in subtitles don't work anyway with native demuxer... (at least
seeking forward)
That's one of the reason people should use -demuxer lavf.

> > > To implement the export of the
> > > normal SSA format from Matroska would be trivial.
> > 
> > Sure. But it won't change the fact that MPlayer need a patch similar to what
> > I propose. If you change lavf mkv demuxer to export its raw pseudo-ASS
> > format, you will have to use a new codec ID. It won't be compatible
> > with CODEC_ID_ASS which is used by other demuxers. And MPlayer would still
> > have to support this CODEC_ID_ASS format.
> 
> Why would MPlayer have to support that?

Because that's the way it is stored in every containers but mkv.

> You're hoping to get other containers to use your personal format,

It's definitely not my personal format...

> (possibly you can influence NUT, but what that container uses is mostly
> academic when there are no real files using it).

I don't need to influence NUT. That's already the format that is used in
NUT since quite some time...
But if you think it's too much "academic" (since when mplayer don't support
academic formats ?), you may be interested to know that it is also the
format which is stored in AVI files. And I have nothing to do with it.
It's in use since many years, and well supported by a variety of tools,
especially on windows...

> > > > Now there are only few possibilities for MPlayer:
> > > >  1) embrace ffmpeg bitstream format and use it (this is what my patch is
> > > >     about, and is quite simple)
> > > 
> > > That format sucks technically and is undesirable to have as MPlayer's
> > > internal format.
> > 
> > That's just laughable...
> 
> You have been told what the technical problems are.

You too... No need to start one more sterile debate.

> You have not been
> able give any reason why those would not be real problems. Even if you
> think there's still reason why your pet format should be used despite
> the problems, you should not try to deny the existence of the problems
> with such "laughable..." comments. That is arguing at a stupid "yes! no!
> yes! no!" level.
> 
> 
> > At least that's not me who defined the long term goal to drop native
> > demuxers in favor of lavf. I've agreed to this goal. And AFAIK, most
> > developers agreed to this.
> > To my knowledge, you are the only one actively working in the opposit
> > direction (by implementing new features in native demuxers).
> 
> I am not working against lavf usage in general. I have added features to
> the internal Matroska demuxer, but not to the others. I intend to add
> support for more Matroska features in the future, and given how you've
> behaved in regard to this subtitle issue it doesn't seem like a good
> idea to try doing any related improvements in lavf instead of internal
> demuxer.
> 
> 
> > > The format you insist on sucks technically.
> > 
> > The format you insist on sucks technically.
> 
> Again you're arguing at a stupid word game level.

You started :-)

> You have been told what the problems are.

You too...

> You have not been able to identify any similarly
> serious problems with the normal Matroska format.

Huh ! You know perfectly well serious problem in the Matroska format.
Do I need to speel this out again ?
The need for out-of-band storage of event display duration makes it
strictly incompatible with any container but mkv, and require every
multimedia framework to carry this value out-of-band in their whole
pipeline (while no other format require this).
Some people (including me) thinks that this is a more serious issue
than the lake of ReadOrder. Maybe you have other priorities, but
you can't deny that the Matroska format has problems.
We both know that both formats have problems. No one implemented
a better format, so we will have to live with both.

I guess I will implement support for lavf ass subtitles without touching
to the current Matroska subtitles support, so that you can continue to
use it in your fork.

Aurel