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

[Aurelien Jacobs]

On Thu, Aug 06, 2009 at 09:49:08PM +0300, Ivan Kalvachev wrote:
> 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.

OK. Any other opinion ?

> I doubt that the code duplication would be any major.

Sure. It probably wouldn't be much. Just a little bit ugly.

> The native mkv demuxer is not going to be replaced anytime soon,

I don't have the same feeling, but that's not important.

> It may be bigger, but it is far more easier to understand, maintain and extend.

Easier to maintain and extend ? Well, I have to disagree...

> There are projects (aegisub) that go into great lengths to use
> an alternative mkv demuxer instead of the generic lavf one.

It would be interesting to know the reason of this. I think I've never
heard any complain from them.

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

Huh ? I doubt that the lavf mkv demuxer is marking all frames as keyframe.
It would be a serious bug. Anyway, if I would get a proper bug repport,
it would probably be fixed quickly.

Aurel