Android video rendering: Fix texture matrix multiplication order

Android video rendering: Fix texture matrix multiplication order

This CL should fix the issue where pixels at one of the edges look stretched out and repeated. It is a bugfix for CL: https://codereview.webrtc.org/1318153007/

BUG=webrtc:4968, webrtc:4742
R=hbos@webrtc.org, pbos@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/8ce0bd54e9b603750cdc2246add1388b046f2182

[magjed_webrtc, 2015-09-09 12:09:41]

magjed@webrtc.org changed reviewers:
+ hbos@webrtc.org, pbos@webrtc.org

[magjed_webrtc, 2015-09-09 12:12:09]

I introduced a bug in the savant matrices in the last CL. hbos - please review
more carefully this time so you don't miss such simple mistakes.

[hbos, 2015-09-09 12:31:49]

lgtm :P

[pbos-webrtc, 2015-09-09 12:32:56]

Fixes rendering issue when scaling encoded input on Nexus 6. rs-lgtm for
functional change. I have no idea how to matrices. :)

[magjed_webrtc, 2015-09-09 12:58:09]

The CQ bit was checked by magjed@webrtc.org

[commit-bot: I haz the power, 2015-09-09 12:58:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1314163008/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1314163008/1

[commit-bot: I haz the power, 2015-09-09 14:10:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-09 14:10:02]

Try jobs failed on following builders:
  android on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  mac_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[magjed_webrtc, 2015-09-09 16:51:24]

Committed patchset #1 (id:1) manually as
8ce0bd54e9b603750cdc2246add1388b046f2182 (presubmit successful).

[stefan-webrtc, 2015-09-09 16:56:55]

Could you comment on what the issue was? Is this related to the scaling issue
where pixels are repeated at the top row look repeated?

[magjed_webrtc, 2015-09-10 07:41:02]

On 2015/09/09 16:56:55, stefan-webrtc (holmer) wrote:
> Could you comment on what the issue was? Is this related to the scaling issue
> where pixels are repeated at the top row look repeated?

I added a description to the CL. Yes, it should fix the issue you describe.
SurfaceTextures contain a 4x4 transformation matrix that specifies what part of
the texture you should sample. We have previously ignored this, and instead used
a hardcoded matrix. This is the first case I have seen where the transformation
matrix differs from our hardcoded matrix. Your scaling feature triggers a
transformation matrix where about 7% of the texture should be ignored from one
of the edges.