My intensity metric is mean pixel value after converting to 8u grayscale.

Here are some stats on per-frame mean pixel value differences for a short clip. So for 327 frames I compared the original to the transcoded frame. I converted both frames to grayscale, then computed the mean ofeach image, and the subtracted (originalMean - transcodedMean):

Mean 1.912494914

Standard Error 0.056628696

Median 1.742355

Mode #N/A

Standard Deviation 1.024024712

Sample Variance 1.048626612

Kurtosis -0.510323895

Skewness 0.102027743

Range 5.714798

Minimum -0.827156

Maximum 4.887642

Sum 625.385837

Count 327

Sofor theaverage frame, its grayscale mean intensity dropped by 1.9.For one frame,its grayscale meanintensity dropped by 4.88.

A different encoder has a nearly identical range magnitude, but the range is close to centered around 0, so the mean is near 0. Its standard deviation is 0.7, so a little lower but same ballpark.

For your second question, here are stats for a different clip:

Mean 1.036684283

Standard Error 0.062302422

Median 1.271118

Mode #N/A

Standard Deviation 0.861036598

Sample Variance 0.741384023

Kurtosis -0.191864263

Skewness -0.262728729

Range 4.726814

Minimum -1.107979

Maximum 3.618835

Sum 198.006698

Count 191

I understand your last question but haven't run that test yet.

For the last question, when I use IPP for the RGB to YUV colorspace conversion (to avoid using VPP), the intensity is greatly increased in the output. So IPP and Quicksync seem to have a different RGB->YUV conversion regarding intensity so this isolation is not instructive.

Here is a fairly high bitrate encode using x264:
http://dl.dropbox.com/u/62496791/x264_3000_h.264
This is not identical to what I'm running (because I'm running from the original, uncompressed rgb3), but should be close enough.

My input file is RGB3, I am converting to RGB4 manually during AVI read so VPP is receiving RGB4. RGB3 is apparently not supported by VPP in version 1.3 API, judging by the MFX_ERR_UNSUPPORTED code I get.

I am using ffmpeg toextract frames fromthe transcoded mp4 (so that is where theresulting h.264 is decoded), and am using the same command for both quicksync and x264 transcodes, so I wouldn't think they would be different, but could be.

I'll post again if I get any more relevant results.

Ryan

I ran the processing (both VPP and encode) using sw 1.4 and hw 1.3 implementations, and compared them.

Here is (original - sw):
Mean -0.474762046 Standard Error 0.038104205 Median -0.466354 Mode #N/A Standard Deviation 0.689043729 Sample Variance 0.474781261 Kurtosis 2.310864995 Skewness -0.007642003 Range 5.659698 Minimum -3.123901 Maximum 2.535797 Sum -155.247189 Count 327

Sothe sw range is fairly balanced around 0, so mean is near 0, and in this case the output is a little bit brighter on average.

Here is (sw - hw):
Mean 2.294726037 Standard Error 0.024461352 Median 2.075493 Mode #N/A Standard Deviation 0.442338092 Sample Variance 0.195662987 Kurtosis -1.357276659 Skewness 0.371498899 Range 1.679047 Minimum 1.452484 Maximum 3.131531 Sum 750.375414 Count 327

Thisreconfirms the previous resultbydirectly comparingthe sw and hw outputs. The sw implementation makes the content alittle brighter and the hw implementation makes the content aboutdarker.

I think my hw and sw code paths are supplying the same params.

Ryan