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

[Ivan Kalvachev]

On 8/6/09, Aurelien Jacobs <aurel at gnuage.org> wrote:
> On Thu, Aug 06, 2009 at 05:31:48PM +0300, Uoti Urpala wrote:
>> On Thu, 2009-08-06 at 14:25 +0200, Aurelien Jacobs wrote:
>> > On Thu, Aug 06, 2009 at 12:10:21AM +0300, Uoti Urpala wrote:
>> > > On Wed, 2009-08-05 at 16:23 -0400, compn wrote:
>> > > > now if we could just get the lavf mkv demuxer to handle
>> > > > subtitles w/ mplayer, then we could stop maintaining this
>> > > > duplication
>> > > > of code.
>> >
>> > I already sent a simple patch for this long ago. It is attached again.
>>
>> And it's still wrong and breaks stuff.
>
> There is no know breakage with this patch !
>
>> Why do you insist on having the
>> lavf demuxer munge the subtitles into that format nobody wants to use?
>
> nobody ???
> Anyway, in case you didn't realize, ffmpeg settled on a bitstream to
> export ASS track (this is not especially related to the mkv demuxer).
> This bitstream format won't change unless you propose a patch on
> ffmpeg-devel.
> Whining on this list won't have any effect.
> 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)
>  2) disregard ffmpeg bitstream format, continue to use matroska internal
>     format, and basically drop support of lavf in MPlayer.
>  3) support both format inside MPlayer (quite ugly and redundant, and will
>     become useless when native mkv demuxer will be removed from MPlayer)
>  4) don't do anything (this is more or less the same as 2)
>
> 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.
> Please anyone, give your opinion about this.

I would accept #3.
I doubt that the code duplication would be any major.

The native mkv demuxer is not going to be replaced anytime soon,
It may be bigger, but it is far more easier to understand, maintain and extend.

There are projects (aegisub) that go into great lengths to use
an alternative mkv demuxer instead of the generic lavf one.
I don't blame them, i tried to fix one of the bugs they pointed at me
and I bumped into design shortcoming.
(All frames after demuxing are marked as keyframes).

I don't like demuxers that mess with the content.
Lavf does this a lot and it is source of constant problems and endless tweaking.

Best Regards