Issue metadata
Sign in to add a comment
|
Canvas not rendering in Chrome 57 for MP4s
Reported by
jonat...@wevideo.com,
Mar 13 2017
|
||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Example URL: https://awstest.wevideo.com/static/movieeditor/test/video.html Steps to reproduce the problem: 1. Try to playback MP4 in canvas 2. (if using provided test link, press play) Source for MP4 is here https://proxies-2.wevideo.com/2016_12_06_be591451-f31f-42ee-9318-827deeff425c What is the expected behavior? 1. MP4 is visible on playback 2. (if using provided test link, two videos appear when previewing) What went wrong? MP4 playback is not visible from canvas. Did this work before? Yes, in Chrome 56 Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Works in Chrome 56 Chrome version: 57.0.2987.98 Channel: stable OS Version: OS X 10.11.6 This is working without any issue in 56.0.2924.87 This issue appears on both 57 and 59.0.3040.0 (canary)
,
Mar 13 2017
,
Mar 13 2017
,
Mar 13 2017
Please find the manual bisect results below : last Good build : 57.0.2977.0 First bad build : 57.0.2978.0 Change log : https://chromium.googlesource.com/chromium/src/+log/57.0.2977.0..57.0.2978.0?pretty=fuller&n=10000 Note : Unable to load the Video on chromium builds and due to unavailability of Corp Mac machine, I will ask team to provide that later tonight.
,
Mar 13 2017
,
Mar 13 2017
+kbr who touched canvas rendering during that range. pbommana@ - are you able to reproduce on Windows?
,
Mar 13 2017
oop's sorry forgot to update no Iam unable to reproduce the issue on Windows(7 and 10) and Linux(ubuntu 14.04Lts), This is specific to Mac
,
Mar 13 2017
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you! Know that this issue shouldn't block the release? Remove the ReleaseBlock-Stable label or move to M58.
,
Mar 14 2017
I'm sorry about this regression. If it had been reported earlier then it might have been possible to prevent it from getting into M57. As it stands, marking this R-B-S for M57 is pointless, so updating the milestone to M58. I can reproduce on my MacBook Pro Retina. Let me dig into it. It's almost surely caused by the fix for Issue 672895 .
,
Mar 14 2017
Note to the submitter: please routinely test your product on both Chrome Canary and, ideally, Chrome Beta to find these regressions earlier. We try our best to prevent them, but clearly we don't have all of the necessary test cases in our conformance suite.
,
Mar 14 2017
WebGL rendering doesn't work either, for that video, on 59.0.3040.0 canary, Win 10 ([.Offscreen-For-WebGL-000001FDCEB8C080]GL ERROR :GL_INVALID_VALUE : glCopySubTextureCHROMIUM: source texture bad dimensions.). It works on stable 57.0.2987.98, Win 10. Test URL: https://jsfiddle.net/21c70p39/5/
,
Mar 23 2017
We have a business based on mp4 rendering on canvas, that means we have to say to our Chrome+macOS users to use another browser (until Apr 25th, 2017 if i'm not mistaken). I understand that hotfixes cannot be released like that for M57, but still.
,
Mar 23 2017
I'm very sorry again for this regression. Working on diagnosing it. If the patch is small I will push for a merge back to M57.
,
Mar 23 2017
,
Mar 24 2017
,
Mar 25 2017
Part of the problem, at least, is that the video element is reporting a size of 484 x 272, and the video's natural size is also reported as 484 x 272. However, the hardware-accelerated video decoding pipeline is producing textures that are 480 x 272. The mismatch is causing the CopySubTextureCHROMIUM operation that was introduced in the fix for Issue 672895 to fail. Unfortunately the revert of that fix is no longer cleanly mergeable to M57 or M58, so I'll continue debugging this and see whether to try to merge back a fix or a revert.
,
Mar 30 2017
Issue 706809 has been merged into this issue.
,
Mar 30 2017
#16: I was worried that something had gone wrong in the size computation, so I analyzed the metadata. This H.264 stream has |coded_size| = 480x272 and no cropping (so |visible_rect| = |coded_size|), and the MP4 has |natural_size| = 483.5x272. This is consistent with your results, and implies that no cropping is required (just scaling to the natural size).
,
Apr 3 2017
#11 & #16: I had the exact same warnings as #11. #16 made me look closely at our video file. FWIW, we apparently rendered out our files with what our video expert calls "elongated pixels", a left over form our source (PAL DVD). This made our 1280*720 video have an actual size of 1400*720. Exporting it instead with square pixels made the size "really" 1280x720, and now the video shows fine in Chrome 57. Even if that does not help with solving the bug, it may be a work-around if you export your own videos.
,
Apr 4 2017
I'm having the same issue with #11 and #19. Video that was working before is now no longer working in Chrome 57 on Windows 10 or Chrome 56 on Android. The video is generated with the following FFMPEG settings, ffmpeg -i out.mp4 -vcodec libx264 -profile:v baseline -preset slow -pix_fmt yuv420p -b:v 5000k -maxrate 5000k -bufsize 2200k -s 1920:1080 -threads 0 -c:a aac -strict experimental -b:a 128k -movflags faststart out2K.mp4 I'm trying to work out how to ensure it has square pixels.
,
Apr 5 2017
A friendly reminder that M58 Stable launch is coming soon! Your bug is labelled as Stable ReleaseBlock, please make sure to land the fix, verified in trunk and get it merged into the release branch ASAP.
,
Apr 6 2017
Btw, I don't know if it's related, but the exact same problem happens on the last release of Chrome for Android
,
Apr 6 2017
A friendly reminder that M58 Stable is launch is coming soon (less than 2 weeks)! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!
,
Apr 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9c785e56c8fcfc13e558a046124a88af0c68af1f commit 9c785e56c8fcfc13e558a046124a88af0c68af1f Author: kbr <kbr@chromium.org> Date: Fri Apr 07 19:36:22 2017 Roll WebGL d0783b8..32cfddc https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/d0783b8..32cfddc BUG=685232, 701060 , 709351 TEST=bots TBR=zmo@chromium.org CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2798083005 Cr-Commit-Position: refs/heads/master@{#462964} [modify] https://crrev.com/9c785e56c8fcfc13e558a046124a88af0c68af1f/DEPS [modify] https://crrev.com/9c785e56c8fcfc13e558a046124a88af0c68af1f/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py [modify] https://crrev.com/9c785e56c8fcfc13e558a046124a88af0c68af1f/content/test/gpu/gpu_tests/webgl_conformance_expectations.py [modify] https://crrev.com/9c785e56c8fcfc13e558a046124a88af0c68af1f/content/test/gpu/gpu_tests/webgl_conformance_revision.txt
,
Apr 11 2017
,
Apr 11 2017
kbr@, should this be marked as applicable to all OS aside from iOS?
,
Apr 11 2017
I've seen the same issue on Linux (Ubuntu 64 as well). So this affects Windows (I tested Windows 7), Mac, Ubuntu, as far as I've seen.
,
Apr 11 2017
,
Apr 11 2017
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ef4c9d488edca70239e636d80b19daa1b4e03d86 commit ef4c9d488edca70239e636d80b19daa1b4e03d86 Author: kbr <kbr@chromium.org> Date: Wed Apr 12 00:06:13 2017 Roll WebGL 32cfddc..fd73a60 https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/32cfddc..fd73a60 BUG= 701060 TEST=bots TBR=zmo@chromium.org CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2806313004 Cr-Commit-Position: refs/heads/master@{#463848} [modify] https://crrev.com/ef4c9d488edca70239e636d80b19daa1b4e03d86/DEPS [modify] https://crrev.com/ef4c9d488edca70239e636d80b19daa1b4e03d86/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py [modify] https://crrev.com/ef4c9d488edca70239e636d80b19daa1b4e03d86/content/test/gpu/gpu_tests/webgl_conformance_revision.txt
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0cc4c62a163318c06636916b7e2b2c6a56f16b74 commit 0cc4c62a163318c06636916b7e2b2c6a56f16b74 Author: kbr <kbr@chromium.org> Date: Wed Apr 12 03:58:17 2017 Fix broken draw/upload paths from videos to 2D canvas and WebGL. The fix for Issue 672895 made these video rendering and upload paths fragile if the video's metadata caused the natural size to differ in certain ways from the coded size. Make the code robust to this case by reverting to CopyTextureCHROMIUM in most cases, and allocating the texture to the correct sizes in others. Tested with new WebGL conformance test to be incorporated in a forthcoming roll: https://github.com/KhronosGroup/WebGL/pull/2359 . BUG= 701060 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 Review-Url: https://codereview.chromium.org/2791813003 Cr-Commit-Position: refs/heads/master@{#463925} [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/content/renderer/media/webmediaplayer_ms.cc [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/content/renderer/media/webmediaplayer_ms.h [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/content/test/gpu/gpu_tests/webgl_conformance_expectations.py [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/media/blink/webmediaplayer_impl.cc [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/media/blink/webmediaplayer_impl.h [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/media/renderers/skcanvas_video_renderer.cc [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/media/renderers/skcanvas_video_renderer.h [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/third_party/WebKit/Source/core/html/HTMLVideoElement.cpp [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/third_party/WebKit/Source/core/html/HTMLVideoElement.h [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h [modify] https://crrev.com/0cc4c62a163318c06636916b7e2b2c6a56f16b74/third_party/WebKit/public/platform/WebMediaPlayer.h
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fe3f46f92f93b06b429c51439cbb846d42c0521f commit fe3f46f92f93b06b429c51439cbb846d42c0521f Author: kbr <kbr@chromium.org> Date: Wed Apr 12 16:28:49 2017 Revert of Fix broken draw/upload paths from videos to 2D canvas and WebGL. (patchset #13 id:230001 of https://codereview.chromium.org/2791813003/ ) Reason for revert: Broke conformance/extensions/oes-texture-float-with-video.html on Android with NVIDIA GPUs: http://crbug.com/710874 . Original issue's description: > Fix broken draw/upload paths from videos to 2D canvas and WebGL. > > The fix for Issue 672895 made these video rendering and upload paths > fragile if the video's metadata caused the natural size to differ in > certain ways from the coded size. Make the code robust to this case by > reverting to CopyTextureCHROMIUM in most cases, and allocating the > texture to the correct sizes in others. > > Tested with new WebGL conformance test to be incorporated in a > forthcoming roll: https://github.com/KhronosGroup/WebGL/pull/2359 . > > BUG= 701060 > 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 > > Review-Url: https://codereview.chromium.org/2791813003 > Cr-Commit-Position: refs/heads/master@{#463925} > Committed: https://chromium.googlesource.com/chromium/src/+/0cc4c62a163318c06636916b7e2b2c6a56f16b74 TBR=dalecurtis@chromium.org,dglazkov@chromium.org,liberato@chromium.org,sandersd@chromium.org,tobiasjs@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 701060 Review-Url: https://codereview.chromium.org/2818493002 Cr-Commit-Position: refs/heads/master@{#464052} [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/content/renderer/media/webmediaplayer_ms.cc [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/content/renderer/media/webmediaplayer_ms.h [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/content/test/gpu/gpu_tests/webgl_conformance_expectations.py [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/media/blink/webmediaplayer_impl.cc [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/media/blink/webmediaplayer_impl.h [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/media/renderers/skcanvas_video_renderer.cc [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/media/renderers/skcanvas_video_renderer.h [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/third_party/WebKit/Source/core/html/HTMLVideoElement.cpp [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/third_party/WebKit/Source/core/html/HTMLVideoElement.h [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h [modify] https://crrev.com/fe3f46f92f93b06b429c51439cbb846d42c0521f/third_party/WebKit/public/platform/WebMediaPlayer.h
,
Apr 13 2017
,
Apr 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0986e62026891425cb209b61092d091d44ec8812 commit 0986e62026891425cb209b61092d091d44ec8812 Author: kbr <kbr@chromium.org> Date: Thu Apr 13 02:34:58 2017 Fix broken draw/upload paths from videos to 2D canvas and WebGL. The fix for Issue 672895 made these video rendering and upload paths fragile if the video's metadata caused the natural size to differ in certain ways from the coded size. Make the code robust to this case by reverting to CopyTextureCHROMIUM in most cases, and allocating the texture to the correct sizes in others. Tested with new WebGL conformance test to be incorporated in a forthcoming roll: https://github.com/KhronosGroup/WebGL/pull/2359 . BUG= 701060 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 Review-Url: https://codereview.chromium.org/2791813003 Cr-Original-Commit-Position: refs/heads/master@{#463925} Committed: https://chromium.googlesource.com/chromium/src/+/0cc4c62a163318c06636916b7e2b2c6a56f16b74 Review-Url: https://codereview.chromium.org/2791813003 Cr-Commit-Position: refs/heads/master@{#464253} [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/content/renderer/media/webmediaplayer_ms.cc [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/content/renderer/media/webmediaplayer_ms.h [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/content/test/gpu/gpu_tests/webgl_conformance_expectations.py [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/media/blink/webmediaplayer_impl.cc [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/media/blink/webmediaplayer_impl.h [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/media/renderers/skcanvas_video_renderer.cc [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/media/renderers/skcanvas_video_renderer.h [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/third_party/WebKit/Source/core/html/HTMLVideoElement.cpp [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/third_party/WebKit/Source/core/html/HTMLVideoElement.h [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h [modify] https://crrev.com/0986e62026891425cb209b61092d091d44ec8812/third_party/WebKit/public/platform/WebMediaPlayer.h
,
Apr 13 2017
Requesting merge to M58. Apologies for the late date, but this is a critical regression to several customers, and it's going to require manual merging because of changes to the code between M58 and M59.
,
Apr 13 2017
This bug requires manual review: Reverts referenced in bugdroid comments after merge request. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 13 2017
Gah, this is huge and super late in the cycle. https://bugs.chromium.org/p/chromium/issues/detail?id=672895 (the fix for which introduced this bug per c#9) is a Pri-2 whereas this seems more impactful, can we just revert the original patch instead?
,
Apr 13 2017
,
Apr 13 2017
Just to update : Final Beta and Pre-Stable RC cut @ 4.00 PM Monday, 04/17.
,
Apr 14 2017
amineer@: yes, I can work on reverting http://crbug.com/672895 for M58. May I have approval to do that directly? I'll build M58 locally to verify the revert.
,
Apr 14 2017
Sigh, I guess the revert is just as big as the fix patch :\ What's less risky in your eyes?
,
Apr 14 2017
Spoke with kbr@ offline - the revert is less risky. Approving revert for M58 branch 3029.
,
Apr 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/df726b319141fe6869bdae70100bf24daa460d2f commit df726b319141fe6869bdae70100bf24daa460d2f Author: Kenneth Russell <kbr@chromium.org> Date: Fri Apr 14 22:58:07 2017 Revert "Fix the size of video textures uploaded to WebGL." This reverts commit 4910ae5b242c441bd047b78bb5cb46ad954920fa. This revert is being done only on the M58 branch, as the lower-risk option of fixing the draw/upload paths from video to both 2D canvas and WebGL. Tested locally. Verified that new WebGL conformance test texture-corner-case-videos.html passes with this revert applied. BUG= 672895 , 701060 TBR=chrishtr@chromium.org,esprehn@chromium.org,dalecurtis@chromium.org CQ_INCLUDE_TRYBOTS=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 Review-Url: https://codereview.chromium.org/2820823003 . Cr-Commit-Position: refs/branch-heads/3029@{#723} Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471} [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/content/renderer/media/webmediaplayer_ms.cc [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/content/renderer/media/webmediaplayer_ms.h [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/media/blink/webmediaplayer_impl.cc [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/media/blink/webmediaplayer_impl.h [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/media/renderers/skcanvas_video_renderer.cc [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/media/renderers/skcanvas_video_renderer.h [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/third_party/WebKit/Source/core/html/HTMLVideoElement.cpp [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/third_party/WebKit/Source/core/html/HTMLVideoElement.h [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp [modify] https://crrev.com/df726b319141fe6869bdae70100bf24daa460d2f/third_party/WebKit/public/platform/WebMediaPlayer.h
,
Apr 14 2017
Fixed in Chrome 59, and the original broken fix for Issue 672895 reverted in Chrome 58.
,
Apr 14 2017
Thanks kbr, this one was a frustrating endeavor!
,
Apr 14 2017
Thanks sandersd@ for your help getting to this point. Sorry for not getting to the bottom of all of the behaviors (i.e., Android), but had to start somewhere.
,
Apr 19 2017
Verified the issue on Mac os 10.12.3 ,ubuntu 14.04 and windows 7 using chrome beta M58 #58.0.3029.81 and issue is fixed. Steps followed to verify : 1. Launched chrome and played video "https://awstest.wevideo.com/static/movieeditor/test/video.html" , MP4 video played. As attached in screencast . Adding TE-Verified Labels. Thanks!
,
Apr 24 2017
Hi, hdodda@chromium.org Please, retest using gl.texSubImage2D(..) without gl.texImage2D(...) I've got catch this when I'm using gl.texSubImage2D(..) [573:775:0424/204839.653941:ERROR:texture_manager.cc(2745)] : [.Offscreen-For-WebGL-0x7ffb90034c00]GL ERROR :GL_INVALID_VALUE : glTexSubImage2D: bad dimensions.
,
Apr 24 2017
#48: please provide a small and self-contained test case. I think all of the issues have been fixed in Chrome 58 and later.
,
Apr 25 2017
#49: Use attached video and index.html (modify code form Comment 47 by hdodda@chromium.org), after 100 tick of frameloop() I used gl.texSubImage2D(...) and caught error. Test on macOs 10.12.2, Chrome Version 58.0.3029.81 (64-bit)
,
Jun 13 2017
Hi, kbr@chromium.org and hdodda@chromium.org I've got catch this when I'm using gl.texSubImage2D(..) again in Version 59.0.3071.86 (Official Build) (64-bit), macOs 10.12.2 [.Offscreen-For-WebGL-0x7fcabf129600]GL ERROR :GL_INVALID_VALUE : glTexSubImage2D: bad dimensions. This test case. Go to link and choose file from the attach testVideo.m4v https://jsfiddle.net/td13ptxr/
,
Jun 13 2017
mikolamin: Can you file a new bug with your details? It's easy to lose track of comments on old bugs like this.
,
Jun 14 2017
Sure. Here you are. Issue 733172
,
Jun 15 2017
|
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by dalecur...@chromium.org
, Mar 13 2017