julee / libyuv Goto Github PK

asm is okay, but using the C version of these, the alpha is wrong.

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.

What steps will reproduce the problem?
1. create a CL with BUG=42 (any bug number)
2. in the code review, click the number

What is the expected output?
See libyuv bug # 42
What do you see instead?
Webrtc bug #42

This was introduced in r99.

On Linux, running:
./build/gyp_chromium --depth=. libyuv.gyp -Dtarget_arch=ia32
make

results in:
CXX(target) out/Debug/obj.target/libyuv/source/scale.o
source/rotate.cc:385: error: expected ‘)’ before ‘TransposeUVWx8_SSE2’
make: *** [out/Debug/obj.target/libyuv/source/rotate.o] Error 1
make: *** Waiting for unfinished jobs....
source/scale.cc:1635: error: expected ‘)’ before ‘ScaleRowDown8Int_SSE2’
source/scale.cc:1967: error: expected ‘)’ before ‘ScaleAddRows_SSE2’
source/scale.cc:2011: error: expected ‘)’ before ‘ScaleFilterRows_SSE2’
source/scale.cc:2099: error: expected ‘)’ before ‘ScaleFilterRows_SSSE3’
make: *** [out/Debug/obj.target/libyuv/source/scale.o] Error 1

r277 introduces argb/yuv unaligned error

The interpolation extrudes the last pixel of a row, as it was intended for 
filtering.
Solution is to do a custom function, or preserve the last 16 bytes somehow.

As a work around/optimization, if all 3 images are the same size, call the 
function with width * height, 1 for dimensions and provide 16 extra bytes at 
the end of buffer.

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.

What steps will reproduce the problem?
1. Call ConvertFromI420 with FOURCC_BGRA.
2.
3.

What is the expected output? What do you see instead?
The frame should be normal. The frame is blue/purple.

What version of the product are you using? On what operating system?
Possibly Windows bu confirmed on Mac OS X and iOS.

Please provide any additional information below.
Attached is a screenshot.

See patch attached.

What steps will reproduce the problem?
1. Call ConvertFromI420
2. ConvertFromI420 calls I420ToBGRARow
3. I420ToBGRARow calls I420ToBGRARow_NEON

What is the expected output? What do you see instead?
GDB lands on asm volatile ( with EXC_BAD_ACCESS

What version of the product are you using? On what operating system?
Latest on iOS 5.1 arm7.

Please provide any additional information below.

y_buf   const uint8 *   0x582d000
*y_buf  unsigned char   94 '^'
u_buf   const uint8 *   0x5857300
v_buf   const uint8 *   0x5861bc0
rgb_buf uint8 * 0x586d000
width   int 480

What steps will reproduce the problem?
1. run libyuv use on android galaxy S2
2. make sure NV21 format is used
3.

What is the expected output? What do you see instead?
expect to see color as needed, actually see mostly blue. for instance human 
skin is blue.

What version of the product are you using? On what operating system?
android 2.3.3
watch code at:
http://code.google.com/p/libyuv/source/browse/trunk/source/convert.cc?spec=svn17
0&r=170


Please provide any additional information below.
the code problem is that there is a comment to swap the u and v but they are 
not swapped:

    case FOURCC_NV21:
      src = sample + (src_width * crop_y + crop_x);
      src_uv = sample + aligned_src_width * (src_height + crop_y / 2) + crop_x;
      // Call NV12 but with u and v parameters swapped.
      NV12ToI420Rotate(src, src_width,
                       src_uv, aligned_src_width,
                       y, y_stride,
                       u, u_stride,
                       v, v_stride,
                       dst_width, inv_dst_height, rotation);

should be:

    case FOURCC_NV21:
      src = sample + (src_width * crop_y + crop_x);
      src_uv = sample + aligned_src_width * (src_height + crop_y / 2) + crop_x;
      // Call NV12 but with u and v parameters swapped.
      NV12ToI420Rotate(src, src_width,
                       src_uv, aligned_src_width,
                       y, y_stride,
                       v, v_stride,
                       u, u_stride,
                       dst_width, inv_dst_height, rotation);

../third_party/libyuv/files/source/scale.cc: In function 'void 
libyuv::ScaleRowDown38_3_Int_NEON(const uint8*, int, uint8*, int)':
../third_party/libyuv/files/source/scale.cc:410:4: error: can't find a register 
in class 'GENERAL_REGS' while reloading 'asm'
../third_party/libyuv/files/source/scale.cc:410:4: error: 'asm' operand has 
impossible constraints

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

See patch attached.

What steps will reproduce the problem?
1. Usual Xcode build
2.
3.

What is the expected output? What do you see instead?
macro YANY has 4 args, calls for neon have 3 args

What version of the product are you using? On what operating system?
287 on os x 10.7.3

Please provide any additional information below.

http://s390pkgs.fedoraproject.org/packages/libyuv/0/0.5.20120308svn209.fc17/data
/logs/s390/build.log

planar_test.cc: In member function 'virtual void 
libyuv::libyuvTest_I420ToARGB_CvsOPT_Test::TestBody()':
planar_test.cc:115:1: warning: unused variable 'i' [-Wunused-variable]

../../third_party/gold/gold64: 
obj/third_party/libyuv/libyuv.a(obj/third_party/libyuv/source/libyuv.mjpeg_decod
er.o): in function 
libyuv::MJpegDecoder::MJpegDecoder():../../third_party/libyuv/source/mjpeg_decod
er.cc:50: error: undefined reference to 'jpeg_std_error'

detail unknown.
platform linux
likely an external issue as libyuv requires libjpeg_turbo

Sometimes the position for blending changes alot, and calling this function is 
slow.  The underlying code also is slow when unaligned or small.  Better to 
make a single function that handles any size/position.

GetARGBBlend can still be used to find a function for the CPU since that never 
changes.

Removing unneeded include of sstream.

webcam's product MJPG
A function to convert MJPGToI420 is needed.
It should be optional, as the code is complex, large and slow.
Use libjpeg_turbo for x86/x64
Resample 422/444/400 to 420.

ARGBInterpolate fails when using SSE2 version of interpolation.  This will be 
crippled for now, but the implication is ARGBScale with bilinear has the same 
issue.

Building for -m64 on OSX does not work in current r233 version.
/DYUV_DISABLE_ASM resolves asm but has a build error
details unanavailable at this time.

What steps will reproduce the problem?
1. Run webrtc video test app on android


What is the expected output? What do you see instead?
I got crash, callstack is shown below. This happened with r204.

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 012aa028
Stack frame #00  pc 000cf982  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
TransposeUVWx8_C in third_party/libyuv/source/rotate.cc:891
Stack frame #01  pc 000cfa74  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
TransposeUV in third_party/libyuv/source/rotate.cc:924
Stack frame #02  pc 000cfac0  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
RotateUV90 in third_party/libyuv/source/rotate.cc:981
Stack frame #03  pc 000cfc2a  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
NV12ToI420Rotate in third_party/libyuv/source/rotate.cc:1140
Stack frame #04  pc 000cc4fe  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
ConvertToI420 in third_party/libyuv/source/convert.cc:1770
Stack frame #05  pc 000ca1da  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
ConvertToI420 in src/common_video/libyuv/libyuv.cc:293
Stack frame #06  pc 0005cb64  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
IncomingFrame in src/modules/video_capture/main/source/video_capture_impl.cc:301
Stack frame #07  pc 0005d588  
/data/data/org.webrtc.videoengineapp/lib/libwebrtc-video-demo-jni.so: Routine 
ProvideCameraFrame in 
/usr/local/google/bin/android-ndk-r7/platforms/android-9/arch-arm/usr/include/jn
i.h:919

http://s390pkgs.fedoraproject.org/packages/libyuv/0/0.5.20120308svn209.fc17/data
/logs/s390/build.log

compare_test.cc: In member function 'virtual void 
libyuv::libyuvTest_BenchmarkPsnr_C_Test::TestBody()':
compare_test.cc:149:10: warning: unused variable 'c_time' [-Wunused-variable]

In r245 a new unittest is indicating a difference between C and SSE2 code.

c:\src\libyuv\trunk>build\release\libyuv_unittest.exe  
--gtest_catch_exceptions=0 --gtest_filter=*565*
Note: Google Test filter = *565*
[==========] Running 3 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 3 tests from libyuvTest
[ RUN      ] libyuvTest.I420ToRGB565_CvsOPT
[       OK ] libyuvTest.I420ToRGB565_CvsOPT (25724 ms)
[ RUN      ] libyuvTest.ARGBToRGB565_CvsOPT
[       OK ] libyuvTest.ARGBToRGB565_CvsOPT (2491 ms)
[ RUN      ] libyuvTest.RGB565ToARGB_CvsOPT
[       OK ] libyuvTest.RGB565ToARGB_CvsOPT (4363 ms)
[----------] 3 tests from libyuvTest (32585 ms total)

[----------] Global test environment tear-down
[==========] 3 tests from 1 test case ran. (32589 ms total)
[  PASSED  ] 3 tests.

c:\src\libyuv\trunk>set LIBYUV_DISABLE_ASM=

c:\src\libyuv\trunk>build\release\libyuv_unittest.exe  
--gtest_catch_exceptions=0 --gtest_filter=*565*
Note: Google Test filter = *565*
[==========] Running 3 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 3 tests from libyuvTest
[ RUN      ] libyuvTest.I420ToRGB565_CvsOPT
[       OK ] libyuvTest.I420ToRGB565_CvsOPT (1639 ms)
[ RUN      ] libyuvTest.ARGBToRGB565_CvsOPT
[       OK ] libyuvTest.ARGBToRGB565_CvsOPT (795 ms)
[ RUN      ] libyuvTest.RGB565ToARGB_CvsOPT
.\unit_test\planar_test.cc(181): error: Value of: 0
Expected: err
Which is: 230561
[  FAILED  ] libyuvTest.RGB565ToARGB_CvsOPT (559 ms)
[----------] 3 tests from libyuvTest (3003 ms total)

[----------] Global test environment tear-down
[==========] 3 tests from 1 test case ran. (3007 ms total)
[  PASSED  ] 2 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] libyuvTest.RGB565ToARGB_CvsOPT

build 64 bit version of libyuv
benchmarks show it is slow compared to 32 bit version.
requires assembly be converted to 64 bit.

What steps will reproduce the problem?
1. Compile for Arm7 iOS via Xcode
2.
3.

What is the expected output? What do you see instead?
/var/folders/vn/zbvdx9z91vz9lgry_3p1v7lh0000gn/T/row_neon-BZaX9N.s:388:error 
parsing element/structure list -- `vld1.u8 {q0,q1,q2,q3},[r0]!'
/var/folders/vn/zbvdx9z91vz9lgry_3p1v7lh0000gn/T/row_neon-BZaX9N.s:390:error 
parsing element/structure list -- `vst1.u8 {q0,q1,q2,q3},[r1]!'
clang: error: assembler command failed with exit code 1 (use -v to see 
invocation)
Command 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/clang failed with exit code 1


What version of the product are you using? On what operating system?
Mac OS X 10.7.3

Please provide any additional information below.

libyuv r233:

Note: Google Test filter = -ViEVideoVerificationTest.RunsFullStackWithoutErrors
[==========] Running 37 tests from 6 test cases.
[----------] Global test environment set-up.
[----------] 1 test from FrameDropPrimitivesTest
[ RUN      ] FrameDropPrimitivesTest.FixOutputFileForComparison
[       OK ] FrameDropPrimitivesTest.FixOutputFileForComparison (0 ms)
[----------] 1 test from FrameDropPrimitivesTest (1 ms total)

[----------] 2 tests from ViEVideoVerificationTest
[ RUN      ] ViEVideoVerificationTest.RunsBaseStandardTestWithoutErrors
[New Thread 0x7ffff7f9b700 (LWP 1113)]
[New Thread 0x7ffff6114700 (LWP 1114)]
[New Thread 0x7ffff5be4700 (LWP 1115)]
[New Thread 0x7ffff561d700 (LWP 1116)]
[New Thread 0x7ffff551c700 (LWP 1117)]
[New Thread 0x7ffff541b700 (LWP 1118)]
[New Thread 0x7ffff531a700 (LWP 1119)]
[New Thread 0x7ffff5219700 (LWP 1120)]
[New Thread 0x7ffff5118700 (LWP 1121)]

Using WebRTC Video Engine version: VideoEngine 3.2.0
Build: Apr  2 2012 15:08:41 d

[New Thread 0x7ffff6013700 (LWP 1122)]
Call started
[Thread 0x7ffff6013700 (LWP 1122) exited]
[Thread 0x7ffff5118700 (LWP 1121) exited]
[Thread 0x7ffff5219700 (LWP 1120) exited]
[Thread 0x7ffff531a700 (LWP 1119) exited]
[Thread 0x7ffff541b700 (LWP 1118) exited]
[Thread 0x7ffff551c700 (LWP 1117) exited]
[Thread 0x7ffff561d700 (LWP 1116) exited]
[Thread 0x7ffff5be4700 (LWP 1115) exited]
[Thread 0x7ffff6114700 (LWP 1114) exited]
[Thread 0x7ffff7f9b700 (LWP 1113) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00000000005c6e17 in libyuv::SumSquareError_SSE2 (
    src_a=0xe334e8 "\206\226\230\231\222\216F\020F(\020b\177w{z{vv|zuvz}\177zyx\200\200x|\201\177~\200\204\212\201mpvjpv|zsv\224\241\230x{\200}~v\201\230{uwskAhx+\203\260\210op{\233\237\224ttp\177zqwvv\202\225\230\230\227\224O\020?,\020]|vzz{vv|{suz}~zzy\201\210x|\202\201\177\201\205\215\203moumnmopkk{\201yooopqpqxpkmmfi\204wUt\202rknnssoghfiiffhh\202\221\227\226\224\223R\020\064&\020\\|u{{|wv{yru|"..., 
    src_b=0xdae7f8 "\206\235\237\237\231\225C\020C(\020Z\177y||~wv}xrry|\200zvw\200\177x}\200\177~\200\203\214\200imtclw}|pt\231\244\237xz\200}~x\201\237}txnjAev+\203\265\212jl}\241\247\232rrk\177|nwtu\202\235\237\237\236\232J\020>-\020V~tz{}wv}zqqy|~yww\202\211x}\200\200\177\202\207\221\201hjregijlee}\200xijjjmjmxmegfad\204vRr\202pfijooj`b_ab_`b`\201\230\236\234\232\232L\020\064'\020T~v}|}yu|wpqz"..., count=88)
    at third_party/libyuv/source/compare.cc:162
162   );
(gdb) bt
#0  0x00000000005c6e17 in libyuv::SumSquareError_SSE2 (
    src_a=0xe334e8 "\206\226\230\231\222\216F\020F(\020b\177w{z{vv|zuvz}\177zyx\200\200x|\201\177~\200\204\212\201mpvjpv|zsv\224\241\230x{\200}~v\201\230{uwskAhx+\203\260\210op{\233\237\224ttp\177zqwvv\202\225\230\230\227\224O\020?,\020]|vzz{vv|{suz}~zzy\201\210x|\202\201\177\201\205\215\203moumnmopkk{\201yooopqpqxpkmmfi\204wUt\202rknnssoghfiiffhh\202\221\227\226\224\223R\020\064&\020\\|u{{|wv{yru|"..., 
    src_b=0xdae7f8 "\206\235\237\237\231\225C\020C(\020Z\177y||~wv}xrry|\200zvw\200\177x}\200\177~\200\203\214\200imtclw}|pt\231\244\237xz\200}~x\201\237}txnjAev+\203\265\212jl}\241\247\232rrk\177|nwtu\202\235\237\237\236\232J\020>-\020V~tz{}wv}zqqy|~yww\202\211x}\200\200\177\202\207\221\201hjregijlee}\200xijjjmjmxmegfad\204vRr\202pfijooj`b_ab_`b`\201\230\236\234\232\232L\020\064'\020T~v}|}yu|wpqz"..., count=88)
    at third_party/libyuv/source/compare.cc:162
#1  0x00000000005c70c4 in libyuv::ComputeSumSquareErrorPlane (
    src_a=0xe334e8 "\206\226\230\231\222\216F\020F(\020b\177w{z{vv|zuvz}\177zyx\200\200x|\201\177~\200\204\212\201mpvjpv|zsv\224\241\230x{\200}~v\201\230{uwskAhx+\203\260\210op{\233\237\224ttp\177zqwvv\202\225\230\230\227\224O\020?,\020]|vzz{vv|{suz}~zzy\201\210x|\202\201\177\201\205\215\203moumnmopkk{\201yooopqpqxpkmmfi\204wUt\202rknnssoghfiiffhh\202\221\227\226\224\223R\020\064&\020\\|u{{|wv{yru|"..., stride_a=88, 
    src_b=0xdae7f8 "\206\235\237\237\231\225C\020C(\020Z\177y||~wv}xrry|\200zvw\200\177x}\200\177~\200\203\214\200imtclw}|pt\231\244\237xz\200}~x\201\237}txnjAev+\203\265\212jl}\241\247\232rrk\177|nwtu\202\235\237\237\236\232J\020>-\020V~tz{}wv}zqqy|~yww\202\211x}\200\200\177\202\207\221\201hjregijlee}\200xijjjmjmxmegfad\204vRr\202pfijooj`b_ab_`b`\201\230\236\234\232\232L\020\064'\020T~v}|}yu|wpqz"..., stride_b=88, width=88, 
    height=72) at third_party/libyuv/source/compare.cc:236
#2  0x00000000005c72cd in libyuv::I420Psnr (
    src_y_a=0xe2d190 "\201\201\205bn\214\236\244pr\226\271\202\302\304\337\275\262\323\310\327\254\337Ę\341\353\264\324\353\327\257\343\340и\260\254\321zY}ef_fafefXdeiglhH\264\271\275ϧ\336\263\353rf\220|ne{\204b^\212sL\266\252\254ƃ!\230\223\220\246kd\231\231]\240\234\312]a\201rf\177?hWNtI\252NP\205\261u\217փ\240\210?o\317Ƚ\223˱\317\305ex|\242\257\262r~}\234\261<C;{\353\335\335\335\334\353z;TMNDF\266\232=\316\\.@\207{\243\206\242n\276\254u\204\210\205\205\203fj\204\242\244fe\226\314|\300\307\330n[\314\332ϯ\333", <incomplete sequence \327>..., stride_y_a=176, 
    src_u_a=0xe33490 "\213\214\205\232\202\210B\020;\036\020e~wyzyvwzvrsz~yvwx\201~w|\201\177~~\203\207\177npujpvzyru\222\242\233tywv\201w\200\234xsxnl=#rR|\276\215nny\231\237\230uts\202}uzz~\206\226\230\231\222\216F\020F(\020b\177w{z{vv|zuvz}\177zyx\200\200x|\201\177~\200\204\212\201mpvjpv|zsv\224\241\230x{\200}~v\201\230{uwskAhx+\203\260\210op{\233\237\224ttp\177zqwvv\202\225\230\230\227\224O\020?,\020]|vzz{vv|{suz"..., 
    stride_u_a=88, 
    src_v_a=0xe34d50 "q\215\220u\241\213\220\231\202\220\231\203\177\200~\177}~\203{d^bb`fc]ay\204\206\202\202\207\210\207\203\200\177\200\206\202\204\207\204\201\200\207\210f^u\232\221\237\214ow\211\212\201\210\200\217\273\276Ϣ\261\222py\205\205\204ups\202\202\207|\177\204\202\206\177ysrs}}\216\226\204\215\231\203~\200\177\201\177\200\202~lggcegfdgz\202\204\203\202\205\207\207\204\200~\200\205\201\205\207\204\201\177\212\213e]{\227\214\210\204y~\206\211{\177\177\207\260\277\246\232\302\214sz\203\203\203vtx\205\204\213\200\201\207\203\210\207}rqqpv\215\227\203\214\230\205\201\200\201\201\177\202\202}keed"..., stride_v_a=88, 
    src_y_b=0xda84a0 "\201\201\204an\213\236\243pq\225\273\200\301\304ݿ\262\322\307֬\337ė\341\353\263\325\353װ\343\340Ѹ\260\255\320{W~ff^fagfgXcfigliH\264\271\274Щݳ\353qg\221~me{\204b^\211sL\267\252\253Ń!\231\223\220\246ld\231\232\\\237\235\311[a\202qf~>gVNvG\253PP\203\260u\217ր\240\214>o\316Ⱦ\224˱\317\305fw|\242\257\263r~}\233\263;C;z\353\336\337\335\334\353y<TLNEF\265\232<\317]-@\206{\244\206\243o\276\254v\203\210\205\205\203fj\204\242\244fe\226\313|\300\306\330n[\314\333Ю\332", <incomplete sequence \326>..., 
    stride_y_b=176, 
    src_u_b=0xdae7a0 "\217\220\210\241\203\214@\020\071\036\020]\177yz||vz{topy\177wtuv\202~v~\201\177}}\202\206\177iltdlu|{pr\226\246\243sxvs\200v\200\243xpyhk>$qRz\277\222gix\240\247\237utp\200~u{{\177\206\235\237\237\231\225C\020C(\020Z\177y||~wv}xrry|\200zvw\200\177x}\200\177~\200\203\214\200imtclw}|pt\231\244\237xz\200}~x\201\237}txnjAev+\203\265\212jl}\241\247\232rrk\177|nwtu\202\235\237\237\236\232J\020>-\020V~tz{}wv}zqqy"..., stride_u_b=88, 
    src_v_b=0xdb0060 "m\220\225r\250\216\217\230\203\220\231\205\177\177}~~~\202{]WZZX_[UYz\201\207\200\201\205\207\207\202\200\177\200\210\201\210\211\205\200\200\212\214`Zq\240\227\247\220jv\210\216\200\211\200\225\274\276ϩ\262\231ow\206\206\204rmp\203\204\212~\177\205\201\203\177yonp|~\217\226\204\216\231\204\177\201~\200\177\201\202~fa_[]a`[`|\200\205\202\201\203\206\210\203\200~\200\210\201\206\211\204\200\200\215\216_Xz\236\217\206\204{~\204\214|~~\213\264\277\254\240\302\215rz\204\204\202trv\206\204\220\177\200\213\203\211\207}nmnlu\216\227\204\214\230\205\177\201\201\200\200\202\202~e^^\\"..., stride_v_b=88, width=176, height=144)
    at third_party/libyuv/source/compare.cc:283
#3  0x00000000005c67d0 in webrtc::I420PSNR (
    ref_frame=0xe2d190 "\201\201\205bn\214\236\244pr\226\271\202\302\304\337\275\262\323\310\327\254\337Ę\341\353\264\324\353\327\257\343\340и\260\254\321zY}ef_fafefXdeiglhH\264\271\275ϧ\336\263\353rf\220|ne{\204b^\212sL\266\252\254ƃ!\230\223\220\246kd\231\231]\240\234\312]a\201rf\177?hWNtI\252NP\205\261u\217փ\240\210?o\317Ƚ\223˱\317\305ex|\242\257\262r~}\234\261<C;{\353\335\335\335\334\353z;TMNDF\266\232=\316\\.@\207{\243\206\242n\276\254u\204\210\205\205\203fj\204\242\244fe\226\314|\300\307\330n[\314\332ϯ\333", <incomplete sequence \327>..., 
---Type <return> to continue, or q <return> to quit--- 
    test_frame=0xda84a0 "\201\201\204an\213\236\243pq\225\273\200\301\304ݿ\262\322\307֬\337ė\341\353\263\325\353װ\343\340Ѹ\260\255\320{W~ff^fagfgXcfigliH\264\271\274Щݳ\353qg\221~me{\204b^\211sL\267\252\253Ń!\231\223\220\246ld\231\232\\\237\235\311[a\202qf~>gVNvG\253PP\203\260u\217ր\240\214>o\316Ⱦ\224˱\317\305fw|\242\257\263r~}\233\263;C;z\353\336\337\335\334\353y<TLNEF\265\232<\317]-@\206{\244\206\243o\276\254v\203\210\205\205\203fj\204\242\244fe\226\313|\300\306\330n[\314\333Ю\332", <incomplete sequence \326>..., width=176, 
    height=144) at src/common_video/libyuv/libyuv.cc:416
#4  0x00000000004ec1df in webrtc::test::CalculateFrame 
(video_metrics_type=webrtc::test::kPSNR, 
    ref=0xe2d190 "\201\201\205bn\214\236\244pr\226\271\202\302\304\337\275\262\323\310\327\254\337Ę\341\353\264\324\353\327\257\343\340и\260\254\321zY}ef_fafefXdeiglhH\264\271\275ϧ\336\263\353rf\220|ne{\204b^\212sL\266\252\254ƃ!\230\223\220\246kd\231\231]\240\234\312]a\201rf\177?hWNtI\252NP\205\261u\217փ\240\210?o\317Ƚ\223˱\317\305ex|\242\257\262r~}\234\261<C;{\353\335\335\335\334\353z;TMNDF\266\232=\316\\.@\207{\243\206\242n\276\254u\204\210\205\205\203fj\204\242\244fe\226\314|\300\307\330n[\314\332ϯ\333", <incomplete sequence \327>..., 
    test=0xda84a0 "\201\201\204an\213\236\243pq\225\273\200\301\304ݿ\262\322\307֬\337ė\341\353\263\325\353װ\343\340Ѹ\260\255\320{W~ff^fagfgXcfigliH\264\271\274Щݳ\353qg\221~me{\204b^\211sL\267\252\253Ń!\231\223\220\246ld\231\232\\\237\235\311[a\202qf~>gVNvG\253PP\203\260u\217ր\240\214>o\316Ⱦ\224˱\317\305fw|\242\257\263r~}\233\263;C;z\353\336\337\335\334\353y<TLNEF\265\232<\317]-@\206{\244\206\243o\276\254v\203\210\205\205\203fj\204\242\244fe\226\313|\300\306\330n[\314\333Ю\332", <incomplete sequence \326>..., width=176, 
    height=144, frame_number=0, result=0x7fffffffda20) at test/testsupport/metrics/video_metrics.cc:42
#5  0x00000000004ec636 in webrtc::test::CalculateMetrics 
(video_metrics_type=webrtc::test::kPSNR, 
    ref_filename=0x94b7c8 "/usr/local/google/users/holmer/code/webrtc-git/trunk/resources/paris_qcif.yuv", 
    test_filename=0x94bd58 "/usr/local/google/users/holmer/code/webrtc-git/trunk/out/RunsBaseStandardTestWithoutErrors-remote.yuv", width=176, height=144, psnr_result=0x7fffffffda20, ssim_result=0x0)
    at test/testsupport/metrics/video_metrics.cc:118
#6  0x00000000004ec8ce in webrtc::test::I420PSNRFromFiles (
    ref_filename=0x94b7c8 "/usr/local/google/users/holmer/code/webrtc-git/trunk/resources/paris_qcif.yuv", 
    test_filename=0x94bd58 "/usr/local/google/users/holmer/code/webrtc-git/trunk/out/RunsBaseStandardTestWithoutErrors-remote.yuv", width=176, height=144, result=0x7fffffffda20)
    at test/testsupport/metrics/video_metrics.cc:171
#7  0x000000000040d732 in (anonymous 
namespace)::ViEVideoVerificationTest::CompareFiles (this=0x94ae20, 
    reference_file="/usr/local/google/users/holmer/code/webrtc-git/trunk/resources/paris_qcif.yuv", 
    test_file=
    "/usr/local/google/users/holmer/code/webrtc-git/trunk/out/RunsBaseStandardTestWithoutErrors-remote.yuv", psnr_result=0x7fffffffdb38, ssim_result=0x7fffffffdb30)
    at src/video_engine/test/auto_test/automated/vie_video_verification_test.cc:82
#8  0x000000000040de3e in (anonymous 
namespace)::ViEVideoVerificationTest_RunsBaseStandardTestWithoutErrors_Test::Tes
tBody (this=0x94ae20)
    at src/video_engine/test/auto_test/automated/vie_video_verification_test.cc:136
#9  0x00000000004cbf9f in 
testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (
    object=0x94ae20, method=&virtual testing::Test::TestBody(), location=0x7d1fb3 "the test body")
    at testing/gtest/src/gtest.cc:2090
#10 0x00000000004c8cb8 in 
testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (
    object=0x94ae20, method=&virtual testing::Test::TestBody(), location=0x7d1fb3 "the test body")
    at testing/gtest/src/gtest.cc:2142
#11 0x00000000004bd17a in testing::Test::Run (this=0x94ae20) at 
testing/gtest/src/gtest.cc:2162
#12 0x00000000004bd99e in testing::TestInfo::Run (this=0x946df0) at 
testing/gtest/src/gtest.cc:2338
#13 0x00000000004be094 in testing::TestCase::Run (this=0x946f50) at 
testing/gtest/src/gtest.cc:2445
#14 0x00000000004c2e6b in testing::internal::UnitTestImpl::RunAllTests 
(this=0x9469e0)
    at testing/gtest/src/gtest.cc:4237
#15 0x00000000004cce43 in 
testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::Uni
tTestImpl, bool> (object=0x9469e0, method=
    (bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x4c2bf2 <testing::internal::UnitTestImpl::RunAllTests()>, 
    location=0x7d2a70 "auxiliary test code (environments or event listeners)")
    at testing/gtest/src/gtest.cc:2090
#16 0x00000000004c95ba in 
testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTe
stImpl, bool> (object=0x9469e0, method=
    (bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x4c2bf2 <testing::internal::UnitTestImpl::RunAllTests()>, 
    location=0x7d2a70 "auxiliary test code (environments or event listeners)")
    at testing/gtest/src/gtest.cc:2142
#17 0x00000000004c1988 in testing::UnitTest::Run (this=0x929ba0) at 
testing/gtest/src/gtest.cc:3874
#18 0x000000000043ffab in ViEAutoTestMain::RunTests (this=0x7fffffffdef0, 
argc=1, argv=0x7fffffffe028)
---Type <return> to continue, or q <return> to quit---
    at src/video_engine/test/auto_test/source/vie_autotest_main.cc:48
#19 0x0000000000465aaa in main (argc=4, argv=0x7fffffffe018)
    at src/video_engine/test/auto_test/source/vie_autotest_linux.cc:141








libyuv r217:

0-7fffefdbe000 r--p 00016000 fc:00 427630                     
/lib/libnsl-2.11.1.so
7fffefdbe000-7fffefdbf000 rw-p 00017000 fc:00 427630                     
/lib/libnsl-2.11.1.so
7fffefdbf000-7fffefdc1000 rw-p 00000000 00:00 0 
7fffefdc1000-7fffefdfe000 r-xp 00000000 fc:00 393423                     
/lib/libdbus-1.so.3.4.0
7fffefdfe000-7fffefffe000 ---p 0003d000 fc:00 393423                     
/lib/libdbus-1.so.3.4.0
7fffefffe000-7fffeffff000 r--p 0003d000 fc:00 393423                     
/lib/libdbus-1.so.3.4.0
7fffeffff000-7ffff0000000 rw-p 0003e000 fc:00 393423                     
/lib/libdbus-1.so.3.4.0
7ffff0000000-7ffff2cf1000 rw-p 00000000 00:00 0 
7ffff2cf1000-7ffff4000000 ---p 00000000 00:00 0 
7ffff4035000-7ffff4036000 ---p 00000000 00:00 0 
7ffff4036000-7ffff4136000 rw-p 00000000 00:00 0 
7ffff4136000-7ffff4194000 r-xp 00000000 fc:00 2100017                    
/usr/lib/libsndfile.so.1.0.21
7ffff4194000-7ffff4394000 ---p 0005e000 fc:00 2100017                    
/usr/lib/libsndfile.so.1.0.21
7ffff4394000-7ffff4396000 r--p 0005e000 fc:00 2100017                    
/usr/lib/libsndfile.so.1.0.21
7ffff4396000-7ffff4397000 rw-p 00060000 fc:00 2100017                    
/usr/lib/libsndfile.so.1.0.21
7ffff4397000-7ffff439b000 rw-p 00000000 00:00 0 
7ffff439b000-7ffff43a4000 r-xp 00000000 fc:00 393751                     
/lib/libwrap.so.0.7.6
7ffff43a4000-7ffff45a3000 ---p 00009000 fc:00 393751                     
/lib/libwrap.so.0.7.6
7ffff45a3000-7ffff45a4000 r--p 00008000 fc:00 393751                     
/lib/libwrap.so.0.7.6
7ffff45a4000-7ffff45a5000 rw-p 00009000 fc:00 393751                     
/lib/libwrap.so.0.7.6
7ffff45a5000-7ffff45a6000 rw-p 00000000 00:00 0 
7ffff45a6000-7ffff45b5000 r-xp 00000000 fc:00 2099752                    
/usr/lib/libXi.so.6.1.0
7ffff45b5000-7ffff47b4000 ---p 0000f000 fc:00 2099752                    
/usr/lib/libXi.so.6.1.0
7ffff47b4000-7ffff47b5000 r--p 0000e000 fc:00 2099752                    
/usr/lib/libXi.so.6.1.0
7ffff47b5000-7ffff47b6000 rw-p 0000f000 fc:00 2099752                    
/usr/lib/libXi.so.6.1.0
7ffff47b6000-7ffff47ba000 r-xp 00000000 fc:00 393260                     
/lib/libuuid.so.1.3.0
7ffff47ba000-7ffff49b9000 ---p 00004000 fc:00 393260                     
/lib/libuuid.so.1.3.0
7ffff49b9000-7ffff49ba000 r--p 00003000 fc:00 393260                     
/lib/libuuid.so.1.3.0
7ffff49ba000-7ffff49bb000 rw-p 00004000 fc:00 393260                     
/lib/libuuid.so.1.3.0
7ffff49bb000-7ffff4a06000 r-xp 00000000 fc:00 2110391                    
/usr/lib/libpulsecommon-0.9.21.so
7ffff4a06000-7ffff4c06000 ---p 0004b000 fc:00 2110391                    
/usr/lib/libpulsecommon-0.9.21.so
7ffff4c06000-7ffff4c07000 r--p 0004b000 fc:00 2110391                    
/usr/lib/libpulsecommon-0.9.21.so
7ffff4c07000-7ffff4c08000 rw-p 0004c000 fc:00 2110391                    
/usr/lib/libpulsecommon-0.9.21.so
7ffff4c08000-7ffff4c0d000 r-xp 00000000 fc:00 2097180                    
/usr/lib/libXtst.so.6.1.0
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff5219700 (LWP 31727)]
0x00007ffff676ea75 in *__GI_raise (sig=<optimized out>) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff676ea75 in *__GI_raise (sig=<optimized out>) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff67725c0 in *__GI_abort () at abort.c:92
#2  0x00007ffff67a874b in __libc_message (do_abort=<optimized out>, 
fmt=<optimized out>)
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007ffff67b2806 in malloc_printerr (action=3, str=0x7ffff68861f8 
"munmap_chunk(): invalid pointer", 
    ptr=<optimized out>) at malloc.c:6266
#4  0x00000000005cc627 in libyuv::ConvertToI420 (
    sample=0x7ffff7fa1000 <Address 0x7ffff7fa1000 out of bounds>, sample_size=202752, 
    y=0xd9f6b0 "xyxyy{wwxxu{yzyzyx{zx{{y{{z|\201\201\177zz{{{{{wz\224\226\224\220\221\222\225\224\225\227\232\233\233\231\235\235\236\240\235\233\232\232\230\232\232\232\227\231\234\232\230\226\230\233\241\242\236\237\237\235\241\240\236\233\237\235\216\214\214\214\211\220\233\227\234\243\217\211\220\221\214\205\204\204\204\212\215\221\216\220\223\221\227\225\227\224\222\224\225\225\226\220\216\207\212\206\205\203\271\270\271\271\272\272\273\272\272\271\270\270\266\251\265\271\270\270\270\272\272\271\271\270\271\270\271\271\270\270\271\271wwwxvuuxyxwwutxyyxuxwuwwzxvyy{xzzxzyyxuy"..., y_stride=352, 
    u=0xdb82b0 "\177\177~}~\200|y\177\204\200}|\202\204~\201z{{~\201\177\177~\201\202\204z\177}~\202}\200\201\203\177~\200\177\200\200||\203~\200\177\177\202\200\177\203\217\202\202~\210\221\204\201\204\201\201\177\177}\200\203\206\177~\201\200\177|\177\202\200~\201\204\177\201\205\201\177~\200\204\203}~{\177\205\205\204\207\201yvwu{\206~{{|~\200~\206z||\200~\177\202}~~\177~\201\200|{~~}\177\177~\202\177\177{\177\202\177~{\201\202}}}\177~}||\203\201}y}{{}|{~xz~y{x}zz|~\200\201\203\201{\200\200|~\201\201\200\177\177|}\202\202\202\200\200\200"..., u_stride=176, 
    v=0xdbe5b0 "|{{\177}||~}{xxxzyx{{zzywvyxzu}yxwvyvwyyxx{xzzxyzzxxz{yxz~zx{xtz}zz}{{yz|~{{{{z{|~y}\177zz|y|{{|yz}zxzx{y{\177\177\200\200\200|z{z{|}y{yw{z|zy{|{zztszzxyxwwyxzuzuovxxwtuvvuwxyuxnkntquvzywyzyyxwwxuryzzz{{zy{|yzxxywywvvwxxv"..., v_stride=176, crop_x=0, crop_y=0, src_width=352, src_height=288, dst_width=352, 
    dst_height=288, rotation=libyuv::kRotate270, format=844715353)
    at third_party/libyuv/source/convert.cc:1913
#5  0x00000000005c6139 in webrtc::ConvertToI420 (src_video_type=webrtc::kYUY2, 
    src_frame=0x7ffff7fa1000 <Address 0x7ffff7fa1000 out of bounds>, crop_x=0, crop_y=0, src_width=352, 
    src_height=288, sample_size=202752, dst_width=352, dst_height=288, dst_stride=352, 
    rotation=webrtc::kRotate270, 
    dst_frame=0xd7a4a0 "\247\246\243\240\243\246\241\244\251\254\256\255\256\255\255\253\253\246\245\253\255\255\256\257\254\255\254\255\256\256\255\255\257\255\254\255\256\256\256\255\255\256\250\243\247\251\246\241\251\255\254\251\247\250\253\256\256\256\256\254\256\256\256\255\256\256\254\253\255\255\254\254\251\251\250\254\252\253\255\256\255\254\255\254\254\256\255\253\255\254\253\254\253\253\254\254\253\253\252\253\252\252\252\252\252\251\252\252\252\251\252\251\251\250\250\250\250\250\250\250\246\227\226\246\247\251\250\250\250\246\247\246\247\245\245\236\224\217\217\205\230\243\243\242\244\245\243\242\242\243\242\241\240\241\242\241\237\241\241\240\235\236\240\236\235\234\227\215\205\216\224\217\222\231\226\230\230\227\227\225\224\224\223\224\222\223\223\222\217\221\220\220\221\220\213\213\216\217\220\216"...) at src/common_video/libyuv/libyuv.cc:293
#6  0x000000000046f700 in 
webrtc::videocapturemodule::VideoCaptureImpl::IncomingFrame 
(this=0x7fffe89dee70, 
    videoFrame=0x7ffff7fa1000 <Address 0x7ffff7fa1000 out of bounds>, videoFrameLength=202752, 
    frameInfo=..., captureTime=0) at src/modules/video_capture/main/source/video_capture_impl.cc:301
#7  0x00000000004726e3 in 
webrtc::videocapturemodule::VideoCaptureModuleV4L2::CaptureProcess (
    this=0x7fffe89dee70) at src/modules/video_capture/main/source/Linux/video_capture_linux.cc:441
#8  0x0000000000472322 in 
webrtc::videocapturemodule::VideoCaptureModuleV4L2::CaptureThread (
    obj=0x7fffe89dee70) at src/modules/video_capture/main/source/Linux/video_capture_linux.cc:376
#9  0x000000000077e59c in webrtc::ThreadPosix::Run (this=0x7fffe8901640)
    at src/system_wrappers/source/thread_posix.cc:310
#10 0x000000000077dbf8 in webrtc::StartThread (lpParameter=0x7fffe8901640)
    at src/system_wrappers/source/thread_posix.cc:37
#11 0x00007ffff6ac49ca in start_thread (arg=<optimized out>) at 
pthread_create.c:300
#12 0x00007ffff6821cdd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

Some functions in convert and perhaps others, have an API with int return where 
0 is success and a non-zero is failure.
-1 should be returned if parameters are bad.  e.g. NULL pointer.
1 should be returned for other fatal errors, such as malloc failure.

The most common errors/bug reports for libyuv are caused by caller passing bad 
parameters.
The low level nature of the API has limitations on what can be checked, but 
most functions don't expect NULL pointers, width <= 0 or height == 0.
Note that stride can be 0 or negative.

webrtc currently has a yuvscaler crash due to a buffer being too small.

If the user allocates too little memory for the UV plane and/or passes bad 
parameters, the yuv scaler can crash because it assumes the width of UV plane 
is (width + 1) / 2
The real issue is the user passing bad parameters, but libyuv could check the 
(width + 1) / 2 is not more than the stride.
stride can be more than width, for alignment, and it may be 0 if the user wants 
to pass 1 row and/or duplicate a row.  But its not normally useful to pass a 
width that is less than stride.
width should normally be respected, but the code could assert, or clamp width.
negative strides are legal, so abs(stride) should be used.

For higher level functions, like ConvertToI420, it may make sense to pass the 
buffer size(s) and compare against stride to ensure pointers wont be used 
outside the buffer.

subj.

Branch name:

Purpose of code changes on this branch:


When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk

Unfortunately an undeclared variable was introduced after rename in r167. This 
patch fixes this issue.

What version of the product are you using? On what operating system?
r216. I tested on android with neon code and c code, both don't work correctly.

I'm pretty sure it's a bug either in webrtc libyuv wrapper or libyuv. 
The following code works fairly good, 
http://blog.tomgibara.com/post/132956174/yuv420-to-rgb565-conversion-in-android.

To reproduce :
Try to use ConvertToI420 with NV21 input.

Observe :
inverted U/V

Version :
Latest trunk (r204) 

Observation :
Indeed, regarding code there is a bug : it even doesn't match with the comment 
:D... I guess some bad copy/paste of the NV12 case.

Quick patch I did that solves the problem.
It's a naive working fix tested in my project - but maybe I have missed 
something, so it should be reviewed :

Index: convert.cc
===================================================================
--- convert.cc  (révision 202)
+++ convert.cc  (copie de travail)
@@ -1746,8 +1746,8 @@
       r = NV12ToI420Rotate(src, src_width,
                            src_uv, aligned_src_width,
                            y, y_stride,
+                           v, v_stride,
                            u, u_stride,
-                           v, v_stride,
                            dst_width, inv_dst_height, rotation);
       break;
     case FOURCC_M420:

libyuv code does not cleanly build with cl /CLR
CLR is an indication of general purpose C++ without assembly.

yuv to rgb table uses 2.6 fixed point times 8.0 = 10.6 signed values.

But 2.018 produces a value out of range:
#define RGBU(i) { \
  static_cast<int16>(2.018 * 64 * (i - 128) + 0.5), \
  static_cast<int16>(-0.391 * 64 * (i - 128) + 0.5), \
  0, \
  0 \
}

For RGBU(0xFF)
Since it only affects 2 values, the best solution is to clamp the table entries.

I get a compile error when the top-level libyuv.h header is included.

[dan@eagle libyuv]$ cat l.cc
#include <libyuv.h>

[dan@eagle libyuv]$ g++ -Wall -I/opt2/src/libyuv/include -c l.cc -o l.o
In file included from /opt2/src/libyuv/include/libyuv.h:23:0,
                 from l.cc:1:
/opt2/src/libyuv/include/libyuv/scale_argb.h:22:6: error: multiple definition 
of ‘enum libyuv::FilterMode’
/opt2/src/libyuv/include/libyuv/scale.h:22:6: error: previous definition here


this is from svn rev 268

What steps will reproduce the problem?
1. Call I420Rotate with kRotate180.
2.
3.

What is the expected output? What do you see instead?
The frame should be rotated 180 degrees. The frame is not rotated.

What version of the product are you using? On what operating system?
Latest SVN. Windows 7, Mac OS X and iOS

Please provide any additional information below.

I have a c++ function that is supposed to rotate the given frame 180 degrees. 
The function is:

bool video_conversion::rotate_180(
    unsigned char * src_frame, int src_stride, int width, int height
    )
{
    unsigned char * src_yplane = src_frame;
    unsigned char * src_uplane = src_yplane + width * height;
    unsigned char * src_vplane = src_uplane + (width * height / 4);

    return libyuv::I420Rotate(
        src_yplane, src_stride, src_uplane, (src_stride + 1) / 2,
        src_vplane, (src_stride + 1) / 2, src_yplane, src_stride, src_uplane,
        (src_stride + 1) / 2, src_vplane, (src_stride + 1) / 2, 0, 0, libyuv::kRotate180  
    );
}

This bug is observed using webRTC calling libyuv through this line :
http://code.google.com/p/webrtc/source/browse/trunk/src/modules/video_capture/ma
in/source/video_capture_impl.cc#292

When rotation is 90 or 270 °

My analysis is that they call ConvertToI420
with type => NV21 --matters because will call transpose UV
source buffer => a valid 352x288 Frame
crop x = crop y = 0
width => 352
height => 288,
size => correct frame size for a 352 288 NV21 frame
rotation => 90 ° --- this matters
targetWidth => 352 --- I think that this is the root cause of the problem, in 
unit tests, in this case, it's always the src height that is used (which is 
more normal if we don't want to loose frame infos ;) )
targetHeight => 288 -- same as previous parameter
dstStride => 352
target buffer =>   a valid 352x288 frame


So libyuv will correctly do its job. 
But, when transpose UV will reach the equivalent of 288 in height instead of 
stopping because actual buffer target height is 288, it will continue because 
it expects to fill until the row 352 : since it's transposing a frame with 352 
width. 
And so it will try to write on invalid space of the target buffer.

So it's maybe a bug in the usage made by webRTC. However, maybe some extra 
check or better some silent cropping would be great.

row_common.cc 474
row_common.cc 492
row_common.cc 515

should be *reinterpret_cast<const uint32*> instead of *reinterpret_cast<uint32*>

Since this file contains "neon" within the "Features" line then the ArmCpuCaps 
must set kCpuHasNEON flag. So correct test assertion would be EXPECT_EQ.

See patch attached.

Measure completeness of conversion from anything to/from I420 and ARGB.

Initial goal would be all YUV formats to/from I420 and all RGB formats to/from 
ARGB
This allows any to any thru 2 or 3 steps
YUV to I420, I420 to ARGB, ARGB to RGB

Subj

mobile needs rotation functionality.
NV12 is the key format on arm devices.  The function should be optimized, as 
profiles on unoptimized code show its a substantial bottleneck.

[ RUN      ] libyuvTest.ScaleDownBy8
filter 0 -       31 us C -       27 us OPT
filter 1 -      838 us C -       82 us OPT
filter 2 -      808 us C -       81 us OPT
[       OK ] libyuvTest.ScaleDownBy8 (1986 ms)

Not sure if there is a bug in libyuv yet, but filing one anyway

via WebRtc, the following produces too little data.

Note that a unittest converts from I420 to 565 and back ok.
The source to I420ToRGB565 looks ok.  Is stride passed in correctly?

#include "common_video/libyuv/include/libyuv.h"
const static int width = 176;
const static int height = 144;
int main(int argc, char** argv) {
 printf("-----main-----\n");
 uint8_t src[width * height / 2 * 3];
 uint8_t dst[width * height * 2];
 FILE * fp;

 // read yuv
 fp = fopen("out.yuv", "r");
 if (!fp) {
   printf("fopen yuv error\n");
   fclose(fp);
   return 0;
 }
 fread(src, width*height*1.5, sizeof(char), fp);

 int ret;
 ret = webrtc::ConvertI420ToRGB565(src, dst, width, height);
 //ret = webrtc::ConvertI420ToARGB4444(src, dst, width, height, width\
);
 if (ret < 0)
   printf("error\n");

 // dump 565
 fp = fopen("out.565", "w");
 if (!fp) {
   printf("fopen 565 error\n");
   fclose(fp);
   return 0;
 }
 fwrite(dst, width*height*2, sizeof(char), fp);
 fclose(fp);
}

bilinear scaling up seems to produce purple lines sometimes.
See b/5230811

See how webrtc does it
https://webrtc-codereview.appspot.com/516001/

What steps will reproduce the problem?
1. build
2. run unit-tests on s390x or ppc64

What is the expected output? What do you see instead?
[ RUN      ] libyuvTest.TestAttenuate
planar_test.cc:158: Failure
Value of: unatten_pixels[2][2]
  Actual: 
Expected: 192u
Which is: 192
[  FAILED  ] libyuvTest.TestAttenuate (8256 ms)

the "Actual" value is 193

What version of the product are you using? On what operating system?
Fedora 16 on s390x

Please provide any additional information below.
I did the computation done in ARGBUnattenuateRow_C() by hand and the result is 
193 which is also what the test-suite returns. It seems to me that the SSE 
optimized and C versions return different results.

And the reason is that "8.16 fixed point inverse table" is different between 
row_common.cc and row_posix.cc (which is the same as row_win.cc, see the value 
for index 255) and also width of numbers used is probably different (I haven't 
studied the algorithms deeply)

  T(0xf8), T(0xf9), T(0xfa), T(0xfb), T(0xfc), T(0xfd), T(0xfe), T(0xff)
vs.
  T(0xf8), T(0xf9), T(0xfa), T(0xfb), T(0xfc), T(0xfd), T(0xfe), 0x100