Thanks, plays normally in <video>, so seems to be some issue with the upload to WebGL.

I can reproduce the GL errors, but likely a bug in the js, not in Chrome.

The condition to generate this code is

offset < 0 || offset + size > imageSize.

Double check if you allocate texImage2D with the big enough size before make texSubImage2D calls.

I can do some debugging if you don't see anything wrong in your code.

I checked on Window 7 Home Chrome Version 59.0.3071.86 (Official Build), (64 bit) and my test-case worked without webgl's error. I think it's error only Mac Os Chrome

I'm pretty sure this is a regression I introduced in the fix for  Issue 701060  and that we're going to have to change the spec for CopySubTextureCHROMIUM to more gracefully handle mismatches between the source and destination textures' sizes.

Taking this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82acdc0cc501e6c772a45334facbef32c261fb1a

commit 82acdc0cc501e6c772a45334facbef32c261fb1a
Author: Jiajia Qin <jiajia.qin@intel.com>
Date: Mon Jul 31 09:55:14 2017

Fixed glTexSubImage2D bad dimensions issue

When TexImageHelperHTMLVideoElement goes to TexImageImpl path,
it will use video's natural size as the image size. However,
we should use the visible size when uploading video data.

Tested with https://github.com/KhronosGroup/WebGL/pull/2464

BUG=733172

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I2265ade9bb14b5c923af634f54116df678f4c224
Reviewed-on: https://chromium-review.googlesource.com/575365
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Jiajia Qin <jiajia.qin@intel.com>
Cr-Commit-Position: refs/heads/master@{#490737}
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/content/renderer/media/webmediaplayer_ms.cc
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/content/renderer/media/webmediaplayer_ms.h
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/content/renderer/media_capture_from_element/html_video_element_capturer_source_unittest.cc
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/third_party/WebKit/Source/core/html/HTMLVideoElement.cpp
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/third_party/WebKit/Source/core/html/HTMLVideoElement.h
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/third_party/WebKit/Source/platform/testing/EmptyWebMediaPlayer.cpp
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/third_party/WebKit/Source/platform/testing/EmptyWebMediaPlayer.h
[modify] https://crrev.com/82acdc0cc501e6c772a45334facbef32c261fb1a/third_party/WebKit/public/platform/WebMediaPlayer.h

Sorry, not sure why I didn't see this during review, but this approach is wrong and adds 3 blocking calls to the render thread. You can't call VisibleRect() and then PaintCurrentFrame() later, they can return different values since they issue tasks to the compositor thread and then block on the render thread for the result.

PaintCurrentFrame() needs to get the frame ref only once and then handle everything this current function is doing:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp?l=5164

I.e. getting the ImageBuf, checking if rect is zero, etc. If it's not possible to move this code into WebMediaPlayerImpl, we'll need to come up with some two stage mechanism where we have something like PrepareFrameForWebGL() on the WMP interface, this will issue the only blocking call and then VisibleRect() and PaintCurrentFrame() will used the result cached from PrepareFrameForWebGL().

Err, current committed code seems to only have 2 blocking calls, the VisibleRect() and PaintCurrentFrame() -- still not ideal and still prone to getting out of sync though.

Hi dalecurtis, thanks for pointing it out. I have modified VisibleRect() method which will follow the logic of NaturalSize. See https://chromium-review.googlesource.com/c/chromium/src/+/749161. Do you think the new change can resolve the problem that you mentioned?