July 2001 - MPlayer-dev-eng - lists.mplayerhq.hu

Re: [Mplayer-dev-eng] projectmayo's divx codec...
by Eugene Kuznetsov 18 Jul '01

18 Jul '01

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(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

4 3

Re: [Mplayer-dev-eng] projectmayo's divx codec...
by Nick Kurshev 18 Jul '01

18 Jul '01

Hi, Arpi! On 2001-07-17 17:38:39 you wrote: >Hi, > >Just tested the first beta of Projectmayo's new divx 3.11 (ms-mpeg4v3) and >4.0 (opendivx 0.48) codec: > >Coyote.Ugly.Sample-highbitrate-atmos.avi >VIDEO: [DIV3] 640x480 24bpp 25.00 fps 1995.1 kbps (243.5 kbyte/s) > >Forcing video codec: [odivx] drv:3 (OpenDivX (MPEG-4 v2)) >BENCHMARKs: V: 13.281s VO: 3.889s A: 0.000s Sys: 0.344s = 17.514s >BENCHMARK%: V: 75.8326% VO: 22.2039% A: 0.0000% Sys: 1.9635% = 100.0000% > >Forcing video codec: [divxds] drv:4 (DivX ;-) (MS MPEG-4 v3)) >BENCHMARKs: V: 19.906s VO: 4.945s A: 0.000s Sys: 0.338s = 25.189s >BENCHMARK%: V: 79.0280% VO: 19.6300% A: 0.0000% Sys: 1.3420% = 100.0000% > >Forcing video codec: [divx] drv:2 (DivX ;-) (MS MPEG-4 v3)) >BENCHMARKs: V: 19.341s VO: 4.852s A: 0.000s Sys: 0.342s = 24.535s >BENCHMARK%: V: 78.8304% VO: 19.7760% A: 0.0000% Sys: 1.3936% = 100.0000% > >Forcing video codec: [ffdivx] drv:5 (FFmpeg DivX ;-) (MS MPEG-4 v3)) >BENCHMARKs: V: 22.831s VO: 3.821s A: 0.000s Sys: 0.340s = 26.992s >BENCHMARK%: V: 84.5855% VO: 14.1564% A: 0.0000% Sys: 1.2582% = 100.0000% > >Strange results. I can't imagine how can it be so fast. >Btw their binary (it is binary-only, and symbols stripped;() has lot's >of mmx/sse code. And _maybe_ they used some optimizing compiler for >compiling (Intel's or visual c), not gcc... > I've done some "reverse engeered" analysis and found that win32-divx codec a lot optimized for MMX/SSE support. Indeed it's MMX2 optimization by I guess that in this case it's useless for K7 as in most commercial software. Yes you could find out MMX/"SSE" opcodes in divx* files but not in l3codeca. >From this point comparision of ffdivx with win32divx is incorrect since we have in most functions "C" optimization. So maybe later - ffdivx will fast of win32 competitors. What about odivx succesor - it's very strange - why they closed the sources. The fact that they used some commercial tables is not argument since it can be found during 5 minutes. In this connexion it would be strange if they will open the sources in the future. And the last - if odivx codec will not support YV42 output it will useless since ffdivx codec has a lot of possibilities to be optimized. Best regards! Nick (2001-07-18 13:34:36) _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

1 0

compile error asf_streaming
by Balazs Tibor 17 Jul '01

17 Jul '01

asf_streaming.o: In function `asf_http_request': asf_streaming.o(.text+0x5b9): undefined reference to `demuxer' asf_streaming.o(.text+0x5ec): undefined reference to `demuxer' collect2: ld returned 1 exit status make: *** [mplayer] Error 1 (I used --enable-streaming a month ago with success, now I tried it with today's CVS, but something went wrong) -=+=- Tibcu -=+=- _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

3 3

Re: Re[2]: [Mplayer-dev-eng] plans ?
by Nick Kurshev 17 Jul '01

17 Jul '01

Hi, Felix Bьnemann! On 2001-07-10 23:40:27 you wrote: >>>What are the plans for the 0.18 release ? >>>I thought it was to have it out as soon as possible. >>>But at the moment it looks like more and more new features get in. >>>An example is the ffmpeg divx codec. I like it very much but >>>I would have waited for the next release. >>> >NK> Yes, since Arpi have added libavcodec - release should be >NK> delayed. I plan to add some optimizations to new stuff. >NK> They should be tested. I guess that 0.18-pre.5 must >NK> have enabled ffmepg-divx codec by default for better >NK> testing. >good idea, but imo we'll get loads of mails from users complaining >bout mplayer being slower (cause they don't neccessarily get it's new >codec). > Are you sure? I've found that new codec is much faster of M$. With M$ stuffs mplayer lose frames on my HW but with new codec I have 0 frames lost (according to mplayer indicators per 2000 frames). So this question is very disputable. Yes, there were reports that new stuffs is slower on P1-MMX but I already have done some optimization which speedups mplayer on 8-9% on my CPU. And there is possibility to speedup decoding more. But Gerald Lantau prefers "C" optimization against MMX. So I can wait while such optimization will be developed before I start to code MMX routines. Anyway this question should be discussed. Best regards! Nick (2001-07-11 13:30:22) _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

7 16

Re: Re: [Mplayer-dev-eng] projectmayo's divx codec...
by Christoph Lampert 17 Jul '01

17 Jul '01

>The encoder engine is based on Eugene's "Sparky" codec. I haven't tested it >yet but seems to be nice, at least has many tuneable parameters :) >(even the behaviour of the quantization and bitrate control is >tunable with many parameters) I guess the encoder is non-open-source, too? So much for the copyright argument... gruel -- Dipl. math. Christoph Lampert (complex analysis, integral formulae) Email: gruel(a)gmx.de | Email: lampert(a)math.chalmers.se _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

1 0

Re: Re: [Mplayer-dev-eng] projectmayo's divx codec...
by Christoph Lampert 17 Jul '01

17 Jul '01

>The encoder engine is based on Eugene's "Sparky" codec. I haven't tested it >yet but seems to be nice, at least has many tuneable parameters :) >(even the behaviour of the quantization and bitrate control is >tunable with many parameters) Aha... so that was the "great secret"... can you 1) force keyframes by a parameter? 2) change bitrate or quantizers "on-the-fly" (without restarting codec?) 3) modify the internal buffer where the last frame was backuped? 4) influence the error measure like SAD? gruel -- Dipl. math. Christoph Lampert (complex analysis, integral formulae) Email: gruel(a)gmx.de | Email: lampert(a)math.chalmers.se _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

1 0

Re: [Mplayer-dev-eng] projectmayo's divx codec...
by Christoph Lampert 17 Jul '01

17 Jul '01

>Hi, > >Just tested the first beta of Projectmayo's new divx 3.11 (ms-mpeg4v3) and >4.0 (opendivx 0.48) codec: What? Where? How? When? Why? Did I miss anything? gruel -- Dipl. math. Christoph Lampert (complex analysis, integral formulae) Email: gruel(a)gmx.de | Email: lampert(a)math.chalmers.se _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

2 1

projectmayo's divx codec...
by Arpi 17 Jul '01

17 Jul '01

Hi, Just tested the first beta of Projectmayo's new divx 3.11 (ms-mpeg4v3) and 4.0 (opendivx 0.48) codec: Coyote.Ugly.Sample-highbitrate-atmos.avi VIDEO: [DIV3] 640x480 24bpp 25.00 fps 1995.1 kbps (243.5 kbyte/s) Forcing video codec: [odivx] drv:3 (OpenDivX (MPEG-4 v2)) BENCHMARKs: V: 13.281s VO: 3.889s A: 0.000s Sys: 0.344s = 17.514s BENCHMARK%: V: 75.8326% VO: 22.2039% A: 0.0000% Sys: 1.9635% = 100.0000% Forcing video codec: [divxds] drv:4 (DivX ;-) (MS MPEG-4 v3)) BENCHMARKs: V: 19.906s VO: 4.945s A: 0.000s Sys: 0.338s = 25.189s BENCHMARK%: V: 79.0280% VO: 19.6300% A: 0.0000% Sys: 1.3420% = 100.0000% Forcing video codec: [divx] drv:2 (DivX ;-) (MS MPEG-4 v3)) BENCHMARKs: V: 19.341s VO: 4.852s A: 0.000s Sys: 0.342s = 24.535s BENCHMARK%: V: 78.8304% VO: 19.7760% A: 0.0000% Sys: 1.3936% = 100.0000% Forcing video codec: [ffdivx] drv:5 (FFmpeg DivX ;-) (MS MPEG-4 v3)) BENCHMARKs: V: 22.831s VO: 3.821s A: 0.000s Sys: 0.340s = 26.992s BENCHMARK%: V: 84.5855% VO: 14.1564% A: 0.0000% Sys: 1.2582% = 100.0000% Strange results. I can't imagine how can it be so fast. Btw their binary (it is binary-only, and symbols stripped;() has lot's of mmx/sse code. And _maybe_ they used some optimizing compiler for compiling (Intel's or visual c), not gcc... A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

1 0

Re: Re: ffmpeg optimization
by Arpi 16 Jul '01

16 Jul '01

Hi, Gerard (ffmpeg/libavcodec author) sent me this, i think you are also interested: (note the latest 2 lines, about WMA codec :)) > I grabbed the latest version and saw the work Nick did. Very good! I will merge > it in next version and try this time to include all the little details so that > you can include it in mplayer without doing any patch. I will add a configure > so that no config option needs to be modified in the Makefile. > > I also integrated CPU test in 0.4.4, but I did not test it on non MMX cpus. [I > will soon try to compile it on SPARC and iPAQ to check that everything is > really portable.] > > Note that ffmpeg now can demux real media files, and you could now play the > audio track of old rm files encoded with AC3 (new ones use the G2 codec). The > libac3 in ffmpeg was tweaked by Michel Lespinasse (it should be in latest > libac3 CVS) so that it can handle the "low bitrate" AC3 extensions I added in > my AC3 encoder to be compatible with the real media format. > > I cannot resist to looking at the WMA V2 codec - expect some progress there if > I find some more nights :-) > > Gerard. > A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

1 0

Small patches for FreeBSD
by Vladimir Kushnir 12 Jul '01

12 Jul '01

Hello, Atached are 2 small patches: a little bit cleanup for vcd_read_fbsd.c (no new functionality) and some support for DVD under FreeBSD (for those who got libcss installed). This last compiles but I couldn't test if it works. Please test it. Regards, Vladimir -- Vladimir Kushnir - vkushnir(a)Alfacom.net

2 1