Use libyuv for non-scaling RGB<->YUV conversions.

Use libyuv for non-scaling RGB<->YUV conversions.

This switches Chromoting hosts to use libyuv for RGB->YUV and clients
to use libyuv for non-scaling rendering.

TEST=remoting_unittests
BUG=145561
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=195268

[Wez, 2013-04-08 21:19:19]

Frank, FYI - see the Gradient test failure.

[Wez, 2013-04-08 21:32:10]

PTAL; aim is to take advantage of libyuv, which is in active development, and in
particular being optimized to better use specific instruction sets.

[Sergey Ulanov, 2013-04-10 03:17:09]

LGTM, but it looks like this change degrades quality and breaks VP8 test. is
that expected?

[fbarchard1, 2013-04-10 08:21:36]

LGTM but you'll need to add tolerance to the tests.

I420ToARGB is done via 9.7 bit fixed point SSSE3 in libyuv with 16 bit
accumulators.  media used 8 bit table lookups with 8 bit accumulators.  Both
point sampled UV.  Basically equal precision, but different.

ARGBToI420 is subsampled using 2 rounding pavgb.  The C version mimics this. 
And then 9.7 bit fixed point rgb to yuv with 16 bit accumulators.  I dont know
hbono's implementation, but its likely different in the subsampling.

Its likely the ARGBToI420 has the larger difference.

[Wez, 2013-04-10 18:17:35]

Translation: the quality isn't visually worse, but the output has different
bit errors to the old algorithms.

Frank, would libyuv's compare PSNR routines make sense to use for these
tests?
On 10 Apr 2013 01:21, <fbarchard@google.com> wrote:

> LGTM but you'll need to add tolerance to the tests.
>
> I420ToARGB is done via 9.7 bit fixed point SSSE3 in libyuv with 16 bit
> accumulators.  media used 8 bit table lookups with 8 bit accumulators.
>  Both
> point sampled UV.  Basically equal precision, but different.
>
> ARGBToI420 is subsampled using 2 rounding pavgb.  The C version mimics
> this.
> And then 9.7 bit fixed point rgb to yuv with 16 bit accumulators.  I dont
> know
> hbono's implementation, but its likely different in the subsampling.
>
> Its likely the ARGBToI420 has the larger difference.
>
>
https://codereview.chromium.**org/13474013/<https://codereview.chromium.org/1...
>

[fbarchard, 2013-04-14 19:29:53]

Correct.  libyuv's conversions are similar precision, but different than
the old ones.

Yes PSNR (MSE) would be best for unittests to allow small changes for
platform/CPU.



On Wed, Apr 10, 2013 at 11:17 AM, Wez <wez@chromium.org> wrote:

> Translation: the quality isn't visually worse, but the output has
> different bit errors to the old algorithms.
>
> Frank, would libyuv's compare PSNR routines make sense to use for these
> tests?
> On 10 Apr 2013 01:21, <fbarchard@google.com> wrote:
>
>> LGTM but you'll need to add tolerance to the tests.
>>
>> I420ToARGB is done via 9.7 bit fixed point SSSE3 in libyuv with 16 bit
>> accumulators.  media used 8 bit table lookups with 8 bit accumulators.
>>  Both
>> point sampled UV.  Basically equal precision, but different.
>>
>> ARGBToI420 is subsampled using 2 rounding pavgb.  The C version mimics
>> this.
>> And then 9.7 bit fixed point rgb to yuv with 16 bit accumulators.  I dont
>> know
>> hbono's implementation, but its likely different in the subsampling.
>>
>> Its likely the ARGBToI420 has the larger difference.
>>
>>
https://codereview.chromium.**org/13474013/<https://codereview.chromium.org/1...
>>
>

[Wez, 2013-04-15 17:15:43]

On 2013/04/14 19:29:53, fbarchard wrote:
> Correct.  libyuv's conversions are similar precision, but different than
> the old ones.
> 
> Yes PSNR (MSE) would be best for unittests to allow small changes for
> platform/CPU.

OK, I'll update this CL to switch the remoting/ unit-tests to use that.

Do either of you have any thoughts on suitable PSNR thresholds?

> On Wed, Apr 10, 2013 at 11:17 AM, Wez <mailto:wez@chromium.org> wrote:
> 
> > Translation: the quality isn't visually worse, but the output has
> > different bit errors to the old algorithms.
> >
> > Frank, would libyuv's compare PSNR routines make sense to use for these
> > tests?
> > On 10 Apr 2013 01:21, <mailto:fbarchard@google.com> wrote:
> >
> >> LGTM but you'll need to add tolerance to the tests.
> >>
> >> I420ToARGB is done via 9.7 bit fixed point SSSE3 in libyuv with 16 bit
> >> accumulators.  media used 8 bit table lookups with 8 bit accumulators.
> >>  Both
> >> point sampled UV.  Basically equal precision, but different.
> >>
> >> ARGBToI420 is subsampled using 2 rounding pavgb.  The C version mimics
> >> this.
> >> And then 9.7 bit fixed point rgb to yuv with 16 bit accumulators.  I dont
> >> know
> >> hbono's implementation, but its likely different in the subsampling.
> >>
> >> Its likely the ARGBToI420 has the larger difference.
> >>
> >>
>
https://codereview.chromium.**org/13474013/%3Chttps://codereview.chromium.org...>
> >>
> >

[Sergey Ulanov, 2013-04-15 17:38:52]

On Mon, Apr 15, 2013 at 10:15 AM, <wez@chromium.org> wrote:

> On 2013/04/14 19:29:53, fbarchard wrote:
>
>> Correct.  libyuv's conversions are similar precision, but different than
>> the old ones.
>>
>
>  Yes PSNR (MSE) would be best for unittests to allow small changes for
>> platform/CPU.
>>
>
> OK, I'll update this CL to switch the remoting/ unit-tests to use that.
>

It might be easier to just update test expectations for this CL and switch
to PSNR later.



>
> Do either of you have any thoughts on suitable PSNR thresholds?
>
>
>  On Wed, Apr 10, 2013 at 11:17 AM, Wez <mailto:wez@chromium.org> wrote:
>>
>
>  > Translation: the quality isn't visually worse, but the output has
>> > different bit errors to the old algorithms.
>> >
>> > Frank, would libyuv's compare PSNR routines make sense to use for these
>> > tests?
>> > On 10 Apr 2013 01:21, <mailto:fbarchard@google.com> wrote:
>> >
>> >> LGTM but you'll need to add tolerance to the tests.
>> >>
>> >> I420ToARGB is done via 9.7 bit fixed point SSSE3 in libyuv with 16 bit
>> >> accumulators.  media used 8 bit table lookups with 8 bit accumulators.
>> >>  Both
>> >> point sampled UV.  Basically equal precision, but different.
>> >>
>> >> ARGBToI420 is subsampled using 2 rounding pavgb.  The C version mimics
>> >> this.
>> >> And then 9.7 bit fixed point rgb to yuv with 16 bit accumulators.  I
>> dont
>> >> know
>> >> hbono's implementation, but its likely different in the subsampling.
>> >>
>> >> Its likely the ARGBToI420 has the larger difference.
>> >>
>> >>
>>
>
> https://codereview.chromium.****org/13474013/%3Chttps://codere**
> view.chromium.org/13474013/ <http://codereview.chromium.org/13474013/>>
>
>> >>
>> >
>>
>
>
>
>
https://codereview.chromium.**org/13474013/<https://codereview.chromium.org/1...
>

[Alpha Left Google, 2013-04-15 17:53:18]

Have you guys ran tests to prove this is a win in perf?

[Wez, 2013-04-17 02:55:42]

On 2013/04/15 17:53:18, Alpha wrote:
> Have you guys ran tests to prove this is a win in perf?

Just some 100-iteration runs of stuff like VideoEncodeAndDecode, which shows a
~10% performance improvement.

You're right, though; we should have a dedicated performance test for the
conversion stage on its own.

[Wez, 2013-04-17 05:59:58]

FYI, have just increased the Gradient test thresholds.

[fbarchard1, 2013-04-17 06:17:00]

LGTM
Can you provide details on how I can build and run this unittest manually when
updating libyuv?

[Wez, 2013-04-17 16:20:47]

On 2013/04/17 06:17:00, fbarchard1 wrote:
> LGTM
> Can you provide details on how I can build and run this unittest manually when
> updating libyuv?

I've added a TEST line - basically just build and run remoting_unittests.  Note
that the test(s) are testing RGB->RGB convert/encode/decode/convert, not just
RGB->YU12->RGB conversion.

[commit-bot: I haz the power, 2013-04-18 22:55:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/13474013/12001

[commit-bot: I haz the power, 2013-04-18 22:57:53]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=ios_dbg_si...

[commit-bot: I haz the power, 2013-04-18 23:34:03]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/13474013/12001

[commit-bot: I haz the power, 2013-04-19 00:13:00]

Retried try job too often on ios_dbg_simulator for step(s) base_unittests,
compile, content_unittests, crypto_unittests, googleurl_unittests,
media_unittests, net_unittests, sql_unittests, ui_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=ios_dbg_si...

[commit-bot: I haz the power, 2013-04-19 17:53:10]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/13474013/12001

[commit-bot: I haz the power, 2013-04-19 20:46:39]

Change committed as 195268