[XviD-devel] A SSIM Plugin for XviD

[skal]

   Hi Johannes and all,

> Message du 10/10/06 17:45
> De : "Johannes Reinhardt" <Johannes.Reinhardt at uni-konstanz.de>
> Objet : [XviD-devel] A SSIM Plugin for XviD


> I hacked together a plugin that calculates the ssim quality metric
> (http://www.cns.nyu.edu/~lcv/ssim/) for every encoded frame and outputs
> a summary for every frame and at the end. The ssim stats can be written
> into a file.
 [...]

   thanks, committed (with minor modifs).

> 
> The computation of ssim is slow. I tried to speed it up with a bit asm,
> but I have not coded in asm before. It would be great if some of the asm
> wizards could comment. It can be sped up more by reducing accuracy, by
> changing GRID to 2 or 4. But there seems to lurks a bug, as this 
> sometimes gives strange results. I will look into this.

  also: since MMX is mixed with floats, i fear some emms() were
  required, which i added. Could be an explanation for the strange
  behaviour.
 
> The calculated ssim values can differ from the ones avisynth or x264
> calculates, so only use them to compare different xvid settings.

  One remark: like most of the SSIM codes around, you're using 
  a square window for averaging. Now, i fear this might lead to 
  spurious resonance with the fact MPEG compression is also
  block-based (this is mentioned in Wang/Bovik's paper).
  I think a gaussian filter really is required, which would
  make things even slower...

> I call check_cpu_features() in order to turn the sse/mmx code on. What
> about adding things cpu features and number of threads to
> xvid_plg_create_t. 

   i'd say calling check_cpu_features() a init time is ok.

> I think about threading the ssim calculation. What would be the best way
> doing this? Using the macros from motion_smp?

   sure. And if they prove useful, might be a good idea to bubble
   them up to a hight-level header...
 
  bye!
Skal