[MPlayer-dev-eng] Postprocessing in GPL
Arpi
arpi at thot.banki.hu
Thu Oct 11 11:54:36 CEST 2001
Hi,
> 1. IMHO C++ dependancy is a bad thing and unneeded in this case:
> the only real cpp thing iss the bool type, same thing can be achieved in C
we already discussed it, code will be soon changed to C.
he has already cvs account to mphq...
> with something like typedef enum boolean {false,true} boolean.
good idea.
> 2. What is the brightness filter good for? In some of my movie samples it
> actually degraded image quality by making it too bright.
same for me :(
it will be optional, so users can enable if they need it.
> 2b. On another movie that I used to check how good deblocking works, I can
> see that the brightness filter is only used on 236 of 240 vertical pixels so
> there stays a 4 pixel high dark band on the bottom of the picture,I guess
> also a bug.
yes, it's a bug. somewhere i saw a 4-line memcpy(). as memcpy just copies,
it won't scale brightness.
> 3. Great Work! =) MPlayer always needs asm coders.
Agree! :)
> 4. To Arpi: now we need access to the qscale arrays for libavcodec, maybe you
> can hack it in (or junto or gerard) and isit possible to also use the pp
> filters together with divx4?
I'll add this to libavcodec very soon.
btw, junto is the webmaster at divx4, he know nothing about libavcodec or
even the divx4 code :)
afaik Eugene added the qscale exporting to libdivxdecore, at least he
promised. as he finally enabled their postprocess code, i've never tried
it.
btw speed of new postprocess is very good, compared to old opendivx
postprocess.c
A'rpi / Astral & ESP-team
--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu
More information about the MPlayer-dev-eng
mailing list