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

Michael Niedermayer michaelni at gmx.at
Tue Aug 18 21:06:13 CEST 2009


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:
[...]
> > > > 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

ohh well, mplayer-dev was such a evil place back then in the good old days
with no personal insults ...


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

good, thats a valid request
if you or aurel posts a patch that exports that missing field in
AVPacket.data in a way that does not violate the ass spec i wouldnt mind
approving it (assuming it otherwise is ok, like yeah, no exploits of internal
gcc 2.95 bugs)
Not that i belive that it would help a single user on the planet nor
that it would change your complaining if a useless field is exportet

i hope that people forgive me that i dont reply to every wrong claim in
this thread. I dont want to fuel this at all, though if there is something
technical that requires the attention of the ffmpeg maintainer, someone
please point me to it.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090818/7934ca70/attachment.pgp>


More information about the MPlayer-dev-eng mailing list