[MPlayer-dev-eng] [PATCH] Dolby TrueHD support for mkv demuxer
Uoti Urpala
uoti.urpala at pp1.inet.fi
Thu Aug 6 21:24:57 CEST 2009
On Thu, 2009-08-06 at 19:38 +0200, Aurelien Jacobs 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 !
That's just your lack of knowledge then. The part about it breaking the
internal demuxer should be obvious.
> > Why do you insist on having the
> > lavf demuxer munge the subtitles into that format nobody wants to use?
>
> nobody ???
Yes. Maybe you want to force others into using it, but it seems you're
not even really using it yourself. And nobody actually using the
subtitles wants that format AFAIK...
> 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).
Yes lavf started arbitrarily munging the subtitle packets into a format
that nobody was using, no user wanted, and which loses information.
> This bitstream format won't change unless you propose a patch on ffmpeg-devel.
> Whining on this list won't have any effect.
Your insistence has nothing to do with patches or lack of them, and
claiming that is dishonest on your part. To implement the export of the
normal SSA format from Matroska would be trivial.
> 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.
> 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. So "dropping lavf support"
is exaggerated; at most the lavf Matroska demuxer is affected.
> 3) support both format inside MPlayer (quite ugly and redundant, and will
> become useless when native mkv demuxer will be removed from MPlayer)
Given the current development of the lavf Matroska demuxer I doubt the
internal Matroska demuxer will be removed any time soon.
> 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. I think that
is a very reasonable thing to ask; lavf should not decide that some
information must not be used and throw it away. Then, whatever stupid
format you insist on using inside lavf, as long as no information is
lost it can at least be converted back in demux_lavf.
> > > > The lavf Matroska demuxer doesn't export information needed for ordered
> > > > chapter support either.
> > >
> > > Neither does the native Matroska demuxer AFAIK, so what's your point ?
> >
> > It does in git.
>
> There is no MPlayer git repository.
> Please stop using the name "MPlayer" for your own fork especially now that
> it is obvious that your goals are diverging from MPlayer's one.
Who defines "MPlayer's goals"? People like you who don't work on
MPlayer?
> If this patch annoys you regarding your fork, note that I didn't proposed
> it for inclusion in you fork. Only in MPlayer repository. Feel free to
> do whatever you want with your damn fork, except hindering MPlayer's
> development.
The format you insist on sucks technically. And it sucks independently
of any particular repository or version; it sucks for programs
completely different from MPlayer too.
You talking about "hindering MPlayer's development" is silly. I am
improving MPlayer. You are not, and have not for years.
More information about the MPlayer-dev-eng
mailing list