up scaling artifacts

[GoogleCodeExporter]

libyuv scalar in webrtc for upsampling a sequence that was down-sampled from 
CIF to 4/5x4/5 (width=282, height=231).
  The down-sampling is done in libvpx, and they choose 4/5 as scale and output odd size decoded frame.

When viewed the upsampled result (282, 231) - > (352, 288) using libyuv scalar 
with kScaleBox filter i see some color artifacts (also see it for bilinear 
filter). 

Is there an issue with the scalar when the input/output frame size is odd?
Scalar tests in webrtc and third_party/libyuv seem to only consider even frame 
sizes.

Original issue reported on code.google.com by fbarch...@google.com on 1 Jun 2012 at 6:51

[GoogleCodeExporter]

attached screenshot: image is an upsampled frame of a (282,231) size decoded 
output from libvpx. seems like the problem is webrtc libyuv wrapper does not 
support odd size frames.

Original comment by marpan@google.com on 1 Jun 2012 at 9:58

Attachments:

• foreman_upsampled_282_231encoded.png

[GoogleCodeExporter]

notice red blob next to face

Original comment by marpan@google.com on 1 Jun 2012 at 9:59

[GoogleCodeExporter]

This appears to be a problem in the webrtc chroma plane size calculation.
The address of the Y and U are right but the V is miscalculated when the size 
of image is odd.

Original comment by fbarch...@google.com on 2 Jun 2012 at 12:22

[GoogleCodeExporter]

fix for this is here: https://webrtc-codereview.appspot.com/633004/

will update the unittests.

Original comment by marpan@google.com on 2 Jun 2012 at 12:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

fix is verified. can close the issue.

Original comment by mar...@webrtc.org on 4 Jun 2012 at 10:07

[GoogleCodeExporter]

Fix was on webrtc side, allocating enough memory for odd sized images, 
computing size of each plane correctly, and passing correct stride values for 
rows.
No libyuv changes needed.

Original comment by fbarch...@google.com on 4 Jun 2012 at 10:20

• Changed state: Fixed