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

[Uoti Urpala]

On Thu, 2009-08-13 at 22:30 +0200, Aurelien Jacobs wrote:
> 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.

First you claimed the patch causes no breakage. Then you admitted that
yes it would break things but said that the fix was obvious. Now you're
admitting that yes it does break things and yes the "fix" wouldn't
actually fix everything, but you still have to talk about how some
things are not perfect anyway even without the extra breakage...


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

That claim is wrong in two ways - in practice it isn't stored in other
containers (I wouldn't count .ass files as "containers"), and nothing
uses your format except maybe nut.


> > You're hoping to get other containers to use your personal format,
> 
> It's definitely not my personal format...

Few others want anything to do with it.


> > (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...

So maybe you _were_ able to influence nut, though again "is used" is
kind of academic...


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

A while ago you posted on ffmpeg-devel and talked about the spec for AVI
which was NOT your format, but instead simply stored an .ass file as one
chunk in the .avi file.


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

No doubt any debate is useless when you delete or ignore most of the
actual content of what I say in your replies, respond to the rest with
contentless dismissals, and argue using blatant bullshit and outright
lies.


> > > > 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 :-)

I did not. I said something meaningful. Then you deleted all context and
replied to one part by parroting what I said.


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

The context was usage as MPlayer's internal format. Containers which
cannot natively store packets that need two timestamps will need to use
workarounds (such as using two packets or moving one timestamp inside
packet data). But there are no such limitations in MPlayer code, and no
reason to deliberately cripple the code to add such limitations.

>  and require every
> multimedia framework to carry this value out-of-band in their whole
> pipeline (while no other format require this).

It's no more "out-of-band" than any other timestamp data, and having it
in separate timestamp fields is right for exactly the same reasons why
any other timestamp fields exist. MPlayer already _has_ an
implementation, which pretty much requires just having one struct field.
There is no reason to cripple that.


> Some people (including me) thinks that this is a more serious issue
> than the lake of ReadOrder.

It is NO issue for internal storage format. People who want to store
SSA/ASS in containers with more limited timestamp support will have to
decide on some workaround; but there's no reason to add ugly workarounds
to MPlayer when none are necessary.

You're again completely ignoring parts of what I wrote. Your reply makes
it sound as if "lack of ReadOrder" had been the main or even only
problem I identified. It wasn't, and you're trying to ignore the rest.


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

Even if some container did use an inferior format there would be no
reason to use it as MPlayer's internal representation. And talking about
formats used in containers, "no one implemented a better format" is a
weak justification for your actions. The Matroska format already existed
in wide use so in that case "have to live with it" is appropriate; but
you could pick a better format to push for use in other containers.


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

Your format sucks independently of where it is used. MPlayer should not
represent subtitles internally in that format. If lavf returns subtitles
in your format then they should be converted to MPlayer's current
internal format in demux_lavf.c. You should implement export of Matroska
subtitles in lavf in a way that doesn't lose information so that they
can be converted back fully.