lemoon / libyuv Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/libyuv
License: BSD 3-Clause "New" or "Revised" License
Automatically exported from code.google.com/p/libyuv
License: BSD 3-Clause "New" or "Revised" License
See patch attached.
Original issue reported on code.google.com by lemenkov
on 29 Jan 2012 at 12:43
Attachments:
See how webrtc does it
https://webrtc-codereview.appspot.com/516001/
Original issue reported on code.google.com by [email protected]
on 24 Apr 2012 at 5:24
../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
Original issue reported on code.google.com by [email protected]
on 17 May 2012 at 9:57
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
Original issue reported on code.google.com by [email protected]
on 12 Mar 2012 at 4:53
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.
Original issue reported on code.google.com by [email protected]
on 22 Mar 2012 at 6:24
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]
Original issue reported on code.google.com by [email protected]
on 19 Mar 2012 at 4:11
See patch attached.
Original issue reported on code.google.com by lemenkov
on 16 Feb 2012 at 9:47
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 12 Mar 2012 at 12:02
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.
Original issue reported on code.google.com by [email protected]
on 29 Feb 2012 at 9:10
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.
Original issue reported on code.google.com by [email protected]
on 20 Jun 2012 at 1:41
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 [email protected]
on 1 Jun 2012 at 6:51
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
);
}
Original issue reported on code.google.com by [email protected]
on 26 Mar 2012 at 2:45
libyuv code does not cleanly build with cl /CLR
CLR is an indication of general purpose C++ without assembly.
Original issue reported on code.google.com by [email protected]
on 12 Jun 2012 at 1:50
bilinear scaling up seems to produce purple lines sometimes.
See b/5230811
Original issue reported on code.google.com by [email protected]
on 8 Nov 2011 at 6:31
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);
}
Original issue reported on code.google.com by [email protected]
on 26 Apr 2012 at 1:57
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.
Original issue reported on code.google.com by [email protected]
on 7 Jun 2012 at 2:59
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.
Original issue reported on code.google.com by [email protected]
on 26 Apr 2012 at 5:56
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]
Original issue reported on code.google.com by [email protected]
on 19 Mar 2012 at 4:14
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
Original issue reported on code.google.com by [email protected]
on 2 Mar 2012 at 1:07
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.
Original issue reported on code.google.com by [email protected]
on 4 Nov 2011 at 4:36
subj.
Original issue reported on code.google.com by lemenkov
on 26 Jan 2012 at 9:47
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
Original issue reported on code.google.com by [email protected]
on 11 Jul 2012 at 6:35
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.
Original issue reported on code.google.com by [email protected]
on 11 Jul 2012 at 6:40
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
Original issue reported on code.google.com by [email protected]
on 1 Jun 2012 at 3:04
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:
Original issue reported on code.google.com by [email protected]
on 6 Mar 2012 at 11:59
Subj
Original issue reported on code.google.com by lemenkov
on 26 Jan 2012 at 9:44
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.
Original issue reported on code.google.com by [email protected]
on 15 Jun 2012 at 11:39
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);
Original issue reported on code.google.com by [email protected]
on 15 Mar 2012 at 10:29
Removing unneeded include of sstream.
Original issue reported on code.google.com by [email protected]
on 2 Mar 2012 at 1:06
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 13 Oct 2011 at 6:25
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.)
Original issue reported on code.google.com by [email protected]
on 3 Apr 2012 at 10:01
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.
Original issue reported on code.google.com by [email protected]
on 12 Jul 2012 at 6:07
asm is okay, but using the C version of these, the alpha is wrong.
Original issue reported on code.google.com by [email protected]
on 1 Jun 2012 at 3:09
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.
Original issue reported on code.google.com by [email protected]
on 26 Mar 2012 at 2:53
Attachments:
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.
Original issue reported on code.google.com by lemenkov
on 29 Jan 2012 at 12:53
Attachments:
row_common.cc 474
row_common.cc 492
row_common.cc 515
should be *reinterpret_cast<const uint32*> instead of *reinterpret_cast<uint32*>
Original issue reported on code.google.com by [email protected]
on 29 Mar 2012 at 4:39
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.
Original issue reported on code.google.com by [email protected]
on 3 Apr 2012 at 8:03
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
Original issue reported on code.google.com by [email protected]
on 18 May 2012 at 8:35
Unfortunately an undeclared variable was introduced after rename in r167. This
patch fixes this issue.
Original issue reported on code.google.com by lemenkov
on 7 Feb 2012 at 8:42
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 8 Nov 2011 at 7:00
[ 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)
Original issue reported on code.google.com by [email protected]
on 9 May 2012 at 8:27
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.
Original issue reported on code.google.com by [email protected]
on 12 Jul 2012 at 6:06
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
Original issue reported on code.google.com by [email protected]
on 10 Dec 2011 at 1:00
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
Original issue reported on code.google.com by [email protected]
on 17 May 2012 at 4:31
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
Original issue reported on code.google.com by [email protected]
on 23 Mar 2012 at 12:49
../../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
Original issue reported on code.google.com by [email protected]
on 5 Jun 2012 at 5:15
r277 introduces argb/yuv unaligned error
Original issue reported on code.google.com by [email protected]
on 5 Jun 2012 at 5:41
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
Original issue reported on code.google.com by [email protected]
on 2 Jun 2012 at 12:30
build 64 bit version of libyuv
benchmarks show it is slow compared to 32 bit version.
requires assembly be converted to 64 bit.
Original issue reported on code.google.com by [email protected]
on 13 Oct 2011 at 6:28
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 [email protected]
on 8 Nov 2011 at 6:28
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.