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

Divx4Linux
by Arpi 20 Jul '01

20 Jul '01

Hi, I've commited changes for supporting DivX4Linux library. Read DOCS/DivX4Linux for details. I'm interested in the benchmark reslts, comparing divxds, divx, ffdivx and divx4 speed & quality. We still have to develop and improve ffmpeg's libavcodec, because it's opensource, so we can add extra features, cache optimization (like video blitting of slices, like in libmpeg2), better postprocessing algos and so. Btw, is there anybody interested in postprocessing algorithms? Gruel? There is postprocess.c in the opendivx directory. Currently it's used for mpeg 1/2 files too, and it will be used for ffmpeg's divx too. We should improve its quality and speed. It's full C yet :( (it's based on ProjectMayo's code, but I spent a lots of time optimizing and improving it at C-level) Or even better: write a better code from scratch (to avoid licensing probs) Postprocessing filter is very very important thing, at least for people with fast enough CPU. It improves image quality a lot. 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

3 6

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

20 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

3 2

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

20 Jul '01

> >Btw. Arpi, can you send me MPlayer patch to use linux divx 4.0 codec >with mplayer? > Change this into "Upload to CVS" :-) 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

MPlayer system-wide installation: 2nd attempt :-)
by Vladimir Kushnir 20 Jul '01

20 Jul '01

Hello, Here goes my 2nd attempt to make MPlayer installed system-wide. What is here: i) It looks for codecs.conf (font/font.desc) in $HOME/.mplayer, failing that looks at DATADIR (new option to configure, defaults to /usr/local/share/mplayer) ii) A new section to font.desc (and new field to font_desc_t) added - fpath (directory where fonts are stored). I did not touch Makefile yet, but that should be easy. BTW, "install -D" isn't portable - our BSD install does not know of this flag. We got to either "mkdir -p <some_dir>" or "install -d <some_dir>" first to create directories as needed. Regards, Vladimir -- Vladimir Kushnir - vkushnir(a)Alfacom.net

2 3

long file support patch
by Arpi 20 Jul '01

20 Jul '01

Hi, Can you make the patch up-to-date with CVS? I'll apply it. But please change one thing: printf's should use 32 bit values. Simply truncate 64bit offsets, I mean: off_t x; ... printf("x=0x%X\n",(unsigned int)x); Those printf's are there for debugging purposes only, and it's ok if they show truncated values. (we are using small files for debugging problems...) This way it stay more portable, and less messy. 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

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 19 Jul '01

19 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 19 Jul '01

19 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 19 Jul '01

19 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