Re: [Mplayer-dev-eng] projectmayo's divx codec...
Hello Christoph, I noticed the discussion here about our new codec and want to clarify a few things.
And _maybe_ they used some optimizing compiler for compiling (Intel's or visual c), not gcc...
This is not correct, libraries I sent to Arpi were built using ordinary gcc 2.95.2. My experience with pgcc and Intel C compiler for Linux is too disappointing.
They can't (or don't want?) release source, only in binary form. They said that it's because of licensing problem, divx 3.11 decoding is illegal this way, and maybe they are using some code or tables from the win32 DLL... I (and also Eugene) hope that it will change to LGPL soon, and they will release sources.
I did what I could to convince people here to make today's release of decoder under LGPL, but I'm not the one who makes all decisions. Our strategists think that decoder is a potential source of revenue for the company, in which case it's safer not to have sources in public. It prevents our competitors ( ffmpeg guys for example ;-), or 3ivx ) from stealing our code and putting it into their closed-source projects. This position is unlikely to change. Encoder is closed too. You will see a thorough explanation of this accompanying the official release.
Btw it's quite buggy, crashes playing files encoded with opendivx 0.47, and crashes for everything if postprocessing is enabled.
Windows version is quite stable. Linux port is not tested enough well, we are working on it.
can you 1) force keyframes by a parameter?
Yes.
2) change bitrate or quantizers "on-the-fly" (without restarting codec?)
You can either use internal rate control module or write your own ( interface allows to pass quantizers to the encoder and get back bit count information ).
3) modify the internal buffer where the last frame was backuped? 4) influence the error measure like SAD?
No, what for?
The encoder engine is based on Eugene's "Sparky" codec
Just for the record, this is absolutely not true, it is even written in different language ( but since you probably won't ever see the source, it does not matter :-) ). -- Best regards, Eugene mailto:sparky@projectmayo.com _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi,
I noticed the discussion here about our new codec and want to clarify a few things.
Welcome on this list :)
And _maybe_ they used some optimizing compiler for compiling (Intel's or visual c), not gcc...
This is not correct, libraries I sent to Arpi were built using ordinary gcc 2.95.2. My experience with pgcc and Intel C compiler for Linux is too disappointing. I've found Intel's compiler very good, for C-only soucres. It helped about 15-20% for libmpeg2 and opendivx decore, and even for ffmpeg. I think it does P3 pipeline optimization much better than gcc.
They can't (or don't want?) release source, only in binary form. They said that it's because of licensing problem, divx 3.11 decoding is illegal this way, and maybe they are using some code or tables from the win32 DLL... I (and also Eugene) hope that it will change to LGPL soon, and they will release sources.
I did what I could to convince people here to make today's release of decoder under LGPL, but I'm not the one who makes all decisions. Our strategists think that decoder is a potential source of revenue for the company, in which case it's safer not to have sources in public. It prevents our competitors ( ffmpeg guys for example ;-), or 3ivx ) from stealing our code and putting it into their closed-source projects. They can still steal code, if they ever heard about disassemblers :) (What about BIEW? :)))
This position is unlikely to change. Encoder is closed too. You will see a thorough explanation of this accompanying the official release. Hmm. Then use some special license, like opendivx's one, which doesn't allow using this code in commercial closed-souurce stuff. Or simply release it as GPL.
I want to change things inside the codec, and also trying to improve it and/or mix with some other code. I like opensource for this. I like to modify things to fit our needs. Just check mplayer, every library used there (for example libmpeg2, opendivx decore :) and ffmpeg) are modified a bit. For example, I've modified libmpeg2 to use opendivx's postprocessing code :) It helps a lot for low-bitrate mpeg1 files.
Btw it's quite buggy, crashes playing files encoded with opendivx 0.47, and crashes for everything if postprocessing is enabled.
Windows version is quite stable. Linux port is not tested enough well, we are working on it. Is the windows version already released? Maybe we can try it with your win32 loader...
The encoder engine is based on Eugene's "Sparky" codec
Just for the record, this is absolutely not true, it is even written in different language ( but since you probably won't ever see the source, it does not matter :-) ). Hmm. I've read at opendivx-devel list that new-wave encore2 is based on teh Sparky codec. If I remember well, you wrote that mail :) Btw it was strange, because sparky has been written in C++ :(
A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
On Wed, Jul 18, 2001 at 05:58:43AM -0700, Eugene Kuznetsov wrote:
I (and also Eugene) hope that it will change to LGPL soon, and they will release sources.
I did what I could to convince people here to make today's release of decoder under LGPL, but I'm not the one who makes all decisions. Our strategists think that decoder is a potential source of revenue for the company, in which case it's safer not to have sources in public. It prevents our competitors ( ffmpeg guys for example ;-), or 3ivx ) from stealing our code and putting it into their closed-source projects.
They CAN'T DO THAT! If you release source under GPL (LGPL is little different I don't know the correct situation for LGPL), everybody wants to use your code, or a part of it, must release their code under GPL too! SO they can't build closed source products using GPL code as well ... In this case thay would break GPL, and you can prosecute them :) - Gabor -- --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]---------[ lgb@lgb.hu ]-- U have 8 bit comp or chip of them and it's unused or to be sold? Call me! -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]----- _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
On Wed, 18 Jul 2001, Eugene Kuznetsov wrote:
Hello Christoph, Hejsan,
3) modify the internal buffer where the last frame was backuped? 4) influence the error measure like SAD?
No, what for?
3) for easy SMP parallelisation (heading to realtime encoding). Since I don't expect any source to be release, a method I came up with (and discussed with eagle) seems the only one to me that will be successful to get speedup and low latencies at the same time. 4) for combination with two-pass. Since I don't expect any source to be released, but I still want to use "better" error measures in scenes where SAD is known to be bad (e.g. fades/dissolves).
The encoder engine is based on Eugene's "Sparky" codec
Just for the record, this is absolutely not true, it is even written in different language ( but since you probably won't ever see the source, it does not matter :-) ).
But it's based on "encore2" that was removed from PMs CVS some months(?) ago? gruel -- Dipl. math. Christoph Lampert (complex analysis, integral formulae) Email: gruel@gmx.de | Email: lampert@math.chalmers.se _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
participants (4)
-
Arpi -
Christoph Lampert -
Eugene Kuznetsov -
Gábor Lénárt