[XviD-devel] question about the decoder+slice rendering
michael at xvid.org
Wed Dec 10 19:30:44 CET 2003
Quoting skal <skal at planet-d.net>:
> Howdy everybody
> On Wed, 2003-12-10 at 16:16, Edouard Gomez wrote:
> > Edouard Gomez (ed.gomez at free.fr) wrote:
> > > i'm merging the deblocking filtering code into my branch, and i
> > > deblocking is only applied on complete images.
> > Another sidenote to the postprocessing merging. The header file
> > copyright was a bit ... strange ... skal email but michael name.
> > Fix it if i was wrong and it was skal code.
> ?!? I hereby swear i've nothing to do with
> the filtering, Your Honor. I was in another
> city when this code was committed, Your Highness!
> I swear!!
;-))) hehe, copy&paste is something evil, especially when I'm too tired
to also change the e-mail address besides just the name ;-)
> What is slice rendering support ? Is deblocking planed for slice
> rendering (would be limited to horizontal deblocking or something like
> that) ?
Slice rendering? I suppose that's the code that copies only those blocks
that have actually changed between ref and current frame, rather than
copying the whole frame, right?
Well, I've been thinking whether deblocking could be sped up by only
processing blocks that have actually changed (mv != zero_mv or cbp != 0).
While this seemed a nice idea at first glance, I'm not so sure anymore
now if it would really pay off: In order to not apply the filtering, we'd
need two neighbouring not coded blocks (top and bottom neighbour, for
example; then we could skip horizontal deblocking). However between
neighbouring already filtered (blocks from ref frame) and not yet filtered
blocks (coded blocks in cur), it would become difficult to apply the de-
blocking. The low-pass filter in DC offset mode for example would then
in one block filter samples that were already filtered and in the other
block would filter still unfiltered samples just as it should. Now this
gives different results than applying the deblocking on a whole unfiltered
image and I think that blocks that are several times filtered will look
bad over time.
However maybe I missed something or overlooked a simple solution to this
problem. So if you have any ideas, you're welcome. I like the idea of
sliced deblocking - I just don't see yet how it should work (and give a
speed improvement of course).
PS: Please note that I've not yet checked whether the deblocking filter
provides visually pleasing results (I was just working on speed-up only
yesterday). However (if I didn't break something) the filter should
give better results than Nic's or Mplayer deblocking (at least this was
my personal impression when I was developing the code for doom9's codec
comparison in May) - but as a drawback: the code is also slower...
More information about the XviD-devel