Issue is also seen on 64.0.3274.0/10151.0.0 dev-channel Minnie device

I was able to reproduce the issue on M63 minnie.

I guess it occurs only on ARM devices.

The thumbnails are rendered correctly when I disabled Hardware-accelerated video codec in chrome://flags#disable-accelerated-video-decode.

Files app creates video thumbnails by
1. Create <video> tag and load the video.
2. Sets <video>'s currentTime to 3 (3 seconds from the beginning)
3. When <video>'s 'canplay' event is fired, we create a <canvas> tag and call canvas's loadImage for the <video>.
https://codesearch.chromium.org/chromium/src/ui/file_manager/image_loader/request.js?l=301

Hi, this is tagged as a beta blocker for M64.  We're not that far out and this bug hasn't been updated in a few days.  Ping?  Thanks...

Hi Pawel, could you help me triage this issue to the right owner?

Alex, would you perhaps be able to take a look at this issue please? Thank you!

Looking at this, first trying to repro on 10149.0.0 Jerry.

Confirmed repro as well as workaround of setting chrome://flags#disable-accelerated-video-decode.

I am getting the following in /var/log/ui/ui.latest right after downloading the video (so presumably, when the file manager is creating the thumbnail:

[6087:6087:1207/172950.238101:ERROR:gles2_cmd_decoder_autogen.h(4722)] [.Offscreen-MainThread-0x16bba800]GL ERROR :GL_INVALID_ENUM : glCreateAndConsumeTextureINTERNAL: target was GL_FALSE
[6087:6087:1207/172950.238443:ERROR:gles2_cmd_decoder_autogen.h(143)] [.Offscreen-MainThread-0x16bba800]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[6087:6087:1207/172950.238686:ERROR:gles2_cmd_decoder_autogen.h(1913)] [.Offscreen-MainThread-0x16bba800]GL ERROR :GL_INVALID_ENUM : glGetTexParameteriv: target was GL_FALSE
[6087:6087:1207/172950.240349:ERROR:gles2_cmd_decoder_autogen.h(1913)] [.Offscreen-MainThread-0x16bba800]GL ERROR :GL_INVALID_ENUM : glGetTexParameteriv: target was GL_FALSE
[6087:6087:1207/172950.256202:ERROR:gles2_cmd_decoder_autogen.h(143)] [.Offscreen-MainThread-0x16bba800]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[6087:6087:1207/172950.256570:ERROR:gles2_cmd_decoder_autogen.h(2909)] [.Offscreen-MainThread-0x16bba800]GL ERROR :GL_INVALID_ENUM : glTexParameteri: target was GL_FALSE
[6087:6087:1207/172950.256809:ERROR:gles2_cmd_decoder_autogen.h(2909)] [.Offscreen-MainThread-0x16bba800]GL ERROR :GL_INVALID_ENUM : glTexParameteri: target was GL_FALSE

M64 beta is targeted for next Tuesday (12-Dec); anything we can do to close this out and/or retag as stable block is appreciated.   I'll ping the owner as well.  Thanks!

VDA Thumbnail test seems to be happy, so as further evidenced by the above log the problem seems to happen after the thumbnail is generated - maybe as we try to blit a smaller version of the decoded video frame?

I haven't looked into this nor 776613, but  crbug.com/776613#c78  log looks similar to what posted in #13.

It seems that we're passing a texture target is GL_FALSE in both cases? Is it possible the two issues are related?

Confirmed (as dcastagna@ suspected) through bisect that https://chromium-review.googlesource.com/602264 has introduced this regression.

It reverts easily, but maybe we can find a quick way to fix this. Daniele, do you have any thoughts? Otherwise we can quickly revert it in time for beta branching.

Thanks for the efforts.... Pinging to see if we can get to a merge resolution by Monday.. Thanks

I can't reproduce the issue on kevin.
It might be only RK3288 and not rockchip related. I'll try it on Minnie.

I can't repro on minnie (RK3288) with latest-canary. The thumbnail shows up fine.

It works on minnie on latest-dev too.

I don't have a Jerry.
acourbot@: if you have a Jerry and you can repro, do you mind checking if https://mdn.github.io/webgl-examples/tutorial/sample8/ works?

I suspect something is going wrong in media/renderers/paint_canvas_video_renderer.cc.

Would you mind taking a look there and see if that is the case and if we can fix it?

Confirmed that latest-canary and latest-dev do not show the issue on my Jerry (both resolved to R65-10203.0.0 in my case).

But latest R64 (R64-10176.10.0) still has the issue. So it seems like a fix has landed in between, bisecting for it.

Regarding https://mdn.github.io/webgl-examples/tutorial/sample8/, the cube initially shows (when it is flat-shaded), but disappears as soon as textures are used. Reverting https://chromium-review.googlesource.com/602264 also fixes this, and R65 seems to be working fine too.

So I guess the correct course would be to find the CL that fixes that in R65, and backport it to the M64 branch. Doing that at the moment.

Quite interestingly this CL is the one that fixes our issue in R65:

https://chromium-review.googlesource.com/c/chromium/src/+/807366

I have tried backporting it to R64 ToT, and it solves the problem there as well. I am not too sure how this is so, but maybe dcastagna@ or mcasas@ can validate. Already asked for M64 cherry-pick on  crbug.com/791676 .

Since we are on a tight schedule and I am working JST, anyone else feel free to perform the cherry-pick during US daytime.

Thanks for the recent efforts on this one!

Sending to all Beta blockers: 

Please re-evaluate today (Monday, 11-Dec) re: Beta Blocker Status.  We're targeting Beta for tomorrow, so please update if a) this isn't blocking, b) the impacted boards can be identified, c) this is resolved / not reproducible, d) a merge / fix can be submitted today.  Thanks!

Since this seems to be an issue on the application side,
adding the Internals>GPU>Video label.

Great, tnx!
I'll take care of the merge.

I'm moving the Merge-Request-64 for https://chromium-review.googlesource.com/807366 to this bug since the other one is still being worked on.

Approving merge to M64 Chrome OS.  Thanks!

Back to acourbot@ that is doing the merge.

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

commit f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e
Author: Daniele Castagna <dcastagna@chromium.org>
Date: Tue Dec 12 02:31:25 2017

Use VideoFrame::NumTextures ISO NumPlanes where needed

This CL sorts out a few points to clear the way for
crrev.com/c/784330 to be landed again; these changes
are, in a nutshell using NumTextures() ISO NumPlanes()
where appropriate, and rewriting the service function
NumGpuMemoryBuffers() for clarity and to allow for
removing FinalVideoFormat().

TEST=all unittests working as before, Video playback
in all platforms and with/without video deco acceleration
running as on ToT.

TBR=mcasas@chromium.org

(cherry picked from commit 43a94cb5e0b90beca79a80315baecadb474f2c5c)

Bug:  791676 ,  787379 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;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: Ic8f0a646a7a0d9271d7233681cb0383e3f6f64ba
Reviewed-on: https://chromium-review.googlesource.com/807366
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#521999}
Reviewed-on: https://chromium-review.googlesource.com/821151
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#163}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/cc/resources/video_resource_updater.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/cc/resources/video_resource_updater_unittest.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/media/renderers/paint_canvas_video_renderer.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/media/video/gpu_memory_buffer_video_frame_pool.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/media/video/gpu_memory_buffer_video_frame_pool_unittest.cc

CL has landed, marking as fixed. Thanks everyone!

Verified on 10176.20.0, 64.0.3282.37

Daniele. Do we have a test that can catch this kind of regression in the future?

@33: WebGL conformance tests would catch this issue, I'm afraid we're not running those tests on RK Chromebooks though.

We also have a layout test for this: LayoutTests/fast/canvas/canvas-drawImage-video.html
I think we're not running LayoutTests on every Chromebook either.

Assuming we won't run WebGL conformance tests nor layout tests on Chromebooks anytime soon, we might want to consider adding a test in media/renderers/paint_canvas_video_renderer_unittest.cc where we could create a VideoFrame similar to what we're sending on rk with HW video decoding. Those tests are mocking GL though, so I'm not sure how useful it would be.