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

[Uoti Urpala]

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.


> > 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? You're hoping to get other
containers to use your personal format, but AFAIK none have adopted it
(possibly you can influence NUT, but what that container uses is mostly
academic when there are no real files using it). So if lavf keeps
CODEC_ID_ASS for your format but Matroska files can be handled without
it, what would actually need CODEC_ID_ASS support in practice? Even if
some container did adopt that format it would be best handled by
converting to the usual packet format, with workarounds for missing
ReadOrder information if necessary.


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


> > >  2) disregard ffmpeg bitstream format, continue to use matroska internal
> > >     format, and basically drop support of lavf in MPlayer.
> > 
> > Since SSA/ASS subs do in practice not appear in containers other than
> > Matroska other containers are not affected.
> 
> It appears in straight .ass files at least as much as in mkv files.

Which should not, and are not, treated as general multimedia containers.
Those files are best read and parsed as a single unit, and there would
be little point doing it through lavf. So that's irrelevant to your
"drop support of lavf" claim.


> > > Now we have to choose one of those solution. I'm ready to implement either
> > > 1) or 3) but only if I know that this solution will be accepted in svn
> > > and won't be reverted by the arbitrary choice of a single person.
> > 
> > What you should do is implement exporting subtitles from lavf in a way
> > that does not lose any information the original file had.
> 
> This has nothing to do with the fact that MPlayer need to support CODEC_ID_ASS
> properly...

Are you being stupid on purpose to avoid addressing the actual content
of what I said? In case it was not a conscious decision I'll spell it
out:
Libavformat should support exporting the subtitles in a way that does
not lose information. That's true independently of what subtitle format
you prefer or what MPlayer does. Now if you'd actually implement this
very reasonable-to-have feature, in any form that really doesn't lose
information, then MPlayer could convert things to normal SSA/ASS packet
format in demux_lavf. This would take care of the subtitle issue for
lavf/Matroska, which is pretty much the only case that matters in
practice. With that working the handling of other CODEC_ID_ASS stuff
would be a minor issue.


> 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 have been told
what the problems are. You have not been able to identify any similarly
serious problems with the normal Matroska format. Also I'm not really
insisting on a particular format the way you are; there doesn't seem to
be any reason to change the format (it'd just add useless conversions),
but the main point is to avoid a format with the problems your format
has.

In case you've already forgotten the problems despite being told
repeatedly what they are: by far the most serious flaw is moving
semantically necessary timestamps from packet metadata fields to inside
the packet byte data and storing them there as absolute time values.
Timestamp fields exist separately from binary data for a reason, and
additionally using absolute values inside the binary data makes adding
any offsets to the timing format-specific and very cumbersome. Lacking a
way to keep the ReadOrder field causes problems but has little benefit
(conversion to remove it later if needed would be simple, putting it
back after the information has been lost isn't). The timestamps lose
accuracy (if that's no problem, would it be OK to hardcode a timebase of
100 in lavf for all video too?).