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

patch refused
by Arpi 19 Jul '01

19 Jul '01

Hi, Please do not change indenting of the code!!! I've reversed this commit. Modify only lines you need, and leave the others alone. > Update of /cvsroot/mplayer/main/linux > In directory mplayer:/var/tmp.root/cvs-serv27987/linux > > Modified Files: > shmem.c > Log Message: > Solaris 2.6 and older do not support MAP_ANON, just fail the mmap MAP_ANON > attempt on such a system. The code tries mmap with /dev/zero and MIT-shm next. > > > Index: shmem.c > =================================================================== > RCS file: /cvsroot/mplayer/main/linux/shmem.c,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- shmem.c 18 Apr 2001 01:25:09 -0000 1.2 > +++ shmem.c 19 Jul 2001 18:49:13 -0000 1.3 > @@ -33,51 +33,57 @@ > > static int shmem_type=0; > > -void* shmem_alloc(int size){ > -void* p; > -int devzero; > -while(1){ > - switch(shmem_type){ > - case 0: // ========= MAP_ANON|MAP_SHARED ========== > - p=mmap(0,size,PROT_READ|PROT_WRITE,MAP_ANON|MAP_SHARED,-1,0); > - if(p==MAP_FAILED) break; // failed > -// printf("shmem: %d bytes allocated using mmap anon (%X)\n",size,p); > - return p; > - case 1: // ========= MAP_SHARED + /dev/zero ========== > - if ((devzero = open("/dev/zero", O_RDWR, 0)) == -1) break; > - p=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,devzero,0); > - if(p==MAP_FAILED) break; // failed > -// printf("shmem: %d bytes allocated using mmap /dev/zero (%X)\n",size,p); > - return p; > - case 2: { // ========= shmget() ========== > - struct shmid_ds shmemds; > - int shmemid; > - if ((shmemid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600)) == -1) break; > - if ((int)(p = shmat(shmemid, 0, 0)) == -1){ > - perror ("shmat()"); > - shmctl (shmemid, IPC_RMID, &shmemds); > +void* shmem_alloc(int size) { > + void* p; > + static int devzero = -1; > + while(1) { > + switch(shmem_type) { > + case 0: > +#ifdef MAP_ANON > + // ========= MAP_ANON|MAP_SHARED ========== > + p=mmap(0,size,PROT_READ|PROT_WRITE,MAP_ANON|MAP_SHARED,-1,0); > + if(p==MAP_FAILED) break; // failed > + //printf("shmem: %d bytes allocated using mmap anon (%X)\n",size,p); > + return p; > +#else > + //system does not support MAP_ANON at all (e.g. solaris 2.5.1/2.6), just fail > break; > +#endif > + case 1: // ========= MAP_SHARED + /dev/zero ========== > + if (devzero == -1 && (devzero = open("/dev/zero", O_RDWR, 0)) == -1) break; > + p=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,devzero,0); > + if(p==MAP_FAILED) break; // failed > + //printf("shmem: %d bytes allocated using mmap /dev/zero (%X)\n",size,p); > + return p; > + case 2: { // ========= shmget() ========== > + struct shmid_ds shmemds; > + int shmemid; > + if ((shmemid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600)) == -1) break; > + if ((int)(p = shmat(shmemid, 0, 0)) == -1) { > + perror ("shmat()"); > + shmctl (shmemid, IPC_RMID, &shmemds); > + break; > + } > + if (shmctl(shmemid, IPC_RMID, &shmemds) == -1) { > + perror ("shmctl()"); > + if (shmdt(p) == -1) perror ("shmdt()"); > + break; > + } > + //printf("shmem: %d bytes allocated using shmget() & shmat() (%X)\n",size,p); > + return p; > } > - if (shmctl(shmemid, IPC_RMID, &shmemds) == -1) { > - perror ("shmctl()"); > - if (shmdt(p) == -1) perror ("shmdt()"); > - break; > + default: > + printf("FATAL: Cannot alloate %d bytes shared memory :(\n",size); > + return NULL; > } > -// printf("shmem: %d bytes allocated using shmget() & shmat() (%X)\n",size,p); > - return p; > - } > - default: > - printf("FATAL: Cannot alloate %d bytes shared memory :(\n",size); > - return NULL; > + ++shmem_type; > } > - ++shmem_type; > -} > } > > -void shmem_free(void* p){ > - switch(shmem_type){ > - case 2: > - if (shmdt(p) == -1) perror ("shmdt()"); > - break; > +void shmem_free(void* p) { > + switch(shmem_type) { > + case 2: > + if (shmdt(p) == -1) perror ("shmdt()"); > + break; > } > } > > _______________________________________________ > Mplayer-cvslog mailing list > Mplayer-cvslog(a)mplayer.dev.hu > http://mplayer.dev.hu/mailman/listinfo/mplayer-cvslog > > 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: [Mplayer-dev-eng] projectmayo's divx codec...
by Eugene Kuznetsov 18 Jul '01

18 Jul '01

Hello Christoph, >>> 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. I haven't heard about it from eagle, and I still don't get the point. To obtain parallelisation, IMHO the best you can do is to encode different fragments of stream using different processors. I don't know about any programs which can do that, but it should be possible to do without any modifications of the encoder. >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). Error levels are normally not calculated at all, because they are not needed. Usually they are about constant for the fixed quantizer. >>> 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? It _is_ "encore2" that was removed from PMs CVS in the end of April, with some performance improvements and added features. BTW you can take current binaries for Linux ( linked against glibc 2.1.2 ) here: http://www.projectmayo.com/projects/subproject.php?projectID=3&subprojectID= 4 There may be small updates to that package during next days as we do more testing of codec in Linux. Arpi seems to have its support in mplayer already, though it's not in CVS yet. -- Best regards, Eugene _______________________________________________ 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 Eugene Kuznetsov 18 Jul '01

18 Jul '01

Hello Andrй, >Like Arpi mentioned there are disassemblers. They can't only be used to >steal code, but also to find out if someone else has stolen your code... >I remember reading about that happening to some free software and if I'm >not misstaking the FSF is taking it to court. This may be too complicated, since we can't spend all the time disassembling our competitors' projects and looking for similarities to our code. They can also take _ideas_ without stealing the code explicitly. If you want to argue with somebody whose opinion is more important than mine, go here: http://forums.projectmayo.com/viewtopic.php?topic=2431&forum=3 -- Best regards, Eugene _______________________________________________ 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 Nick Kurshev 18 Jul '01

18 Jul '01

Hi! On 2001-07-18 05:58:43 Eugene Kuznetsov wrote: [snipped out] > >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. It's unbelievable - ffmpeg guys will steal their sources to put into closed projects? IMHO talk was about decoder(s) which is(are) too open in ffmpeg together with encoders. Yea - soon mplayer will become a competitor too! ;) [snipped out] Best regards! Nick (2001-07-19 01:02:00) _______________________________________________ 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 Eugene Kuznetsov 18 Jul '01

18 Jul '01

Hello Gabor, > 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 :) But if they do build closed source products using our GPL code, we won't ever find out. -- Best regards, Eugene _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng(a)lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng

2 1

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