[XviD-devel] discussion continue...

[Marc FD]

> > For the histogramm based detection, i can write a simple&robust
> > implementation.
> > i could improve it more when B-frames would be widely used.
> > what do you think ?
>
> Would be a very good idea!

Fot that i would need :
- a short example of how the function does look like.
- maybe all the papers you said you have on this subject (compress them, i
don't have DSL)

> > i've a good experience in image-based filtering with my avisynth
plugins.
> > i think i can to do the pre-processing part of XviD.
> >
> > Some ideas to make the better pre-proc possible.
> > - pre-proc should be image-based
> > - pre-proc should work on the reference frame (max quality in input)
> > - pre-proc could use :
> >     Quantizers who will be used for each MBs,
> >     MVs used for each MB
> >     maybe last frame quantizers and MBs too.
> >     last reference frame (HQ temporal filtering)
> >
> > I there any way to separate the Motion Estimation in
> > Fast ME (MVsearch) / Precise ME (refinements,ect..)
>
> This wouldn't be good, because PreciseME of neighbours is needed
> for MVsearch, otherwise quality drops. I tested similar stuff when
> implementing SMP.

too bad.
are you _sure_ it's not preciseME who is needed for preciseME of neighbours
?
i think to do fast ME, since it's less accurate, we don't need very precise
ME
from neighbours. in my idea, fast ME was not very accurate. (over 1-2 pels)

> > I don't know if such an ME will be efficient, but like this we could use
> > pre-proc between Fast an Precise ME,
> > to reduce even more the texture bits (by removing noise) using
information
> > we need to keep an hiqh quality  : Quants used/MVs
> > maybe compensating movement like translations could be possible too.
>
> > I wish XviD could have a Very High Quality pre-proc mode, because after
all
> > it's the best MPEG-4 codec ;)
> > This mode could be used to remove noise a very efficient way, using all
the
> > information we compute during encoding.
> > And we could add more pre-processing modes who would be more aggressive,
ie
> > for low bitrates.
> >
> > I think adaptive quant could be done during pre-processing.
> > The PP algo could raise quants or suggest to skip MBs.
>
> Yes, that's possible. Early SKIP detection I wanted to do anyway (using
> DCT or Hadamard ;-), a combination with adaptive quant is possible.

regarding "Hadamarad ;-)" my stuff was in fact 25% slower than skal's.
I'm not that bad if i can reach a master in the matter ;))

I'm currently testing frame-skip with the Hadamarad stuff, and it seems
promising.
i would give you the final code if it works good.

> But I guess for the beginning, pre-processing before everything else would
> be best. Many decisions depend on the input material itself, it would be
> dangerous to first make decisions (adaptive quant, skip) and _then_
> preprocess input data.
> One day, I'll write a sophisticated "input analysis routine" (maybe
> including foreground/background segmentation etc), but at the moment, we
> have to live with what we have.

The position of pre-processing is _very_ important.
it's a paradox :
if you make it too early, you have a blind pre-proc, and it's really not
what we want for XviD.
if we do it late, me modify the decisions of the codec regarding the input
data.

maybe we need a new approach, more 2 pass based.
someone (syskin if i remember) said he wanted to try more advanced ME for 2
pass.
the best would be to be able to split the ME in two parts who are
independant.
but it seems tricky...

>
> gruel
>
> P.S. We might very well continue discussion at xvid-devel... others might
> be interested in pre-processing etc., too.

here we are ;)

MarcFD  marc.fd@libertysurf.fr