Bayer Odd height has last row blue

[GoogleCodeExporter]

Bayer has off by one on height for odd sizes images.
Talk's unittests reproduce it like this:

Steps to repro
build\dbg\tests\media_unittest.exe --gunit_filter=BayerRGB.* --bayer_dump
ffmpeg -s 240x135 -i 
ConvertI420ToARGBToGRBGToI420At240x135Unaligned.240x135_P420.yuv 
bayer240x135.png
View the bayer240x135.png

For GRBG the pattern is
GR
BG

This should be considered a subsampled format.  So when allocating, the size 
needs to be rounded up.
When converting from ARGB, one row of ARGB will produce 2 rows of Bayer.
When converting from Bayer, 2 rows will be read, but only one row of ARGB 
written.
When converting from Bayer to I420, 2 rows of bayer produces one of ARGB and 
then one Y row and one of each U and V, using the single ARGB row for 
subsampling instead of 2.

Original issue reported on code.google.com by fbarch...@google.com on 8 Nov 2011 at 6:28

[GoogleCodeExporter]

Bayer conversion verified ok for BA81.
The issue here is simply a unittest that under allocates BA81 source for odd 
height.
Like subsampling, you need to allocate enough memory for all components.  For 1 
row of BA81 requires 2 rows of content, but will decode to one row of RGB.
To help with issues like this, I propose helper functions for determining how 
much memory/pixels a format needs.

Original comment by fbarch...@google.com on 5 Apr 2012 at 9:36

• Changed state: Invalid