[XviD-devel] PATCH: Per slices rendering

Michael Militzer xvid-devel@xvid.org
Mon, 8 Jul 2002 01:27:29 +0200


----- Original Message -----
From: "peter ross" <suxen_drol@hotmail.com>
To: <xvid-devel@xvid.org>
Sent: Monday, July 08, 2002 12:26 AM
Subject: Re: [XviD-devel] PATCH: Per slices rendering


> hey all,
>
> how about adding a 'dirty' field for each macroblock, which is set if the
> macroblock has changed? then at the image_output stage, perform some
> macroblock checking and call slice_copy.
>
> out of curiosity, have you tried rending at the macroblock/block level?

yes, this was my first idea. Bad is that this 'dirty' field is only used for
the slice_copy and for nothing else. Then I thought a bit about it and came
to this idea: The idct data is currently stored in a int16_t data[64 * 6]
for a MB. Why not make one big array [64*6*mb_width*mb_height] for all MBs
and additionally one status variable for every MB? It should be possible
then to skip the final transfer step in mb_intra and mb_inter and instead
perform the transfer at once at the end of decoder_iframe and
decoder_pframe. Advantage would be that non coded blocks doesn't need to be
copied from ref to current frame, only MBs that have changed (intra/inter)
need to be copied directly over the ref frame.

Also with the help of the status variable, the "dirty" blocks could then be
copied during image_output using a copy_slice like function...

Again: I didn't test this yet, maybe I missed something and it won't work. I
have still some uni work to do now and tomorrow before I can test this.

btw: pete, you wrote that you wanted to rewrite the bframe decoding
support - anything done already?

> btw, iam quite pleased to here xvid's decoder is fast.

yesterday I committed some additional asm code that was again tweaked by
Skal. He especially enhanced the dequant4_mmx code, it's now nearly twice as
fast than before (!!). I think we should now always beat ffmpeg and there
still seems to be some space left for improvements :-)

bye
Michael