Closed GoogleCodeExporter closed 8 years ago
There's an SkCanvasVideoRenderer unittest in media_blink_unittests
Original comment by dalecurtis@chromium.org
on 24 Jul 2015 at 10:00
Theres 3 ways to implement this:
1. Caller can do 2 steps: I420ToARGB and ARGBCopyYToAlpha
ARGBCopyYToAlpha takes a plane of data and copies it to the 4th byte of ARGB.
See planarfunctions.h
LIBYUV_API
int ARGBCopyYToAlpha(const uint8* src_y, int src_stride_y,
uint8* dst_argb, int dst_stride_argb,
int width, int height);
Advantages:
a. Allows any form of I420 conversion, including I422, J420 and ABGR
destination. b. works with existing libyuv.
c. both functions are highly optimized including AVX2.
Disadvantage:
a. less cache/memory friendly for large images where ARGB destination doesnt
fit cache.
2. Implement A420ToARGB (I420 with alpha), internally doing 2 steps per row.
Advantages:
a. faster - using a row buffer for intermediate ARGB is cache friendly.
b. abstracts implementation, which can be improved in future.
Disadvantage:
a. implements a specific color space. less flexible.
3. Implement optimized A420ToARGB.
Internally the I420ToARGB is done with 3 macros to implement the I420 fetch,
YUV conversion, and ARGB storing. The ARGB storing fills in 255. This macro
could implement a variation that fetches alpha from another pointer.
Advantage: fastest
Disadvantage: most complex, least flexible.
Original comment by fbarch...@chromium.org
on 11 Aug 2015 at 6:03
I420AlphaToARGB implemented in r1466
I420AlphaToARGB_Any (1373 ms)
I420AlphaToARGB_Unaligned (1625 ms)
I420AlphaToARGB_Invert (1303 ms)
I420AlphaToARGB_Opt (1302 ms)
I420ToARGB_Any (660 ms)
I420ToARGB_Unaligned (637 ms)
I420ToARGB_Invert (615 ms)
I420ToARGB_Opt (542 ms)
Original comment by fbarch...@chromium.org
on 18 Aug 2015 at 6:25
change is integrated into chrome.
a followup improvement would be I420AlphaToABGR and some performance
improvements.
Original comment by fbarch...@chromium.org
on 20 Aug 2015 at 11:32
This is the CL that switches to libyuv::I420AlphaToARGB
https://codereview.chromium.org/1293293003/
Original comment by fbarch...@chromium.org
on 21 Aug 2015 at 12:49
Starting ABGR version.
Original comment by fbarch...@chromium.org
on 21 Aug 2015 at 1:07
Performance went from 2 steps (for android)
SkCanvasVideoRendererTest.TransparentFrame (1610 ms)
to 1 step:
SkCanvasVideoRendererTest.TransparentFrame (1256 ms)
Original comment by fbarch...@chromium.org
on 27 Aug 2015 at 1:25
ABGR integrated into skcanvas.
consider merging ARGB and ABGR functions into a single function and exposing
other color spaces - BGRA, J420 etc.
consider removing premultiplication and have renderer do unattenuated alpha
blend.
consider implmenting I420AlphaToARGB internally as a single assembly function,
which fills in alpha as it goes, instead of filling in 255 and then doing 2nd
step to copy, and/or third step to attenuate RGB by alpha.
Original comment by fbarch...@chromium.org
on 27 Aug 2015 at 1:40
3 followup changes under consideration
1. refactor I420AlphaToABGR to use I420AlphaToARGB internally, but swap U and V
and transpose conversion matrix, so I420AlphaToARGB and I420AlphaToABGR share
low level code.
2. Port to ARMv7 Neon and aarch64 Neon
3. Now that row function is similar to old mmx code, introduce benchmark in
chromium media.
Original comment by fbarch...@chromium.org
on 27 Oct 2015 at 5:55
Original comment by fbarch...@chromium.org
on 10 Nov 2015 at 7:49
Original issue reported on code.google.com by
dalecurtis@chromium.org
on 24 Jul 2015 at 9:47