argh, I wanted to start the title with "GLSL bug: " as for the rest of the series. Is it possible to edit ? 

fabrice.neyret@gmail.com, when you say it's ok or not depending on the machine, do you have access to two machines where it is working on one but not the other? Can you save the contents of about:gpu (save as webpage, complete) in Chrome on the working and not working machine and attach them to this issue?

During encoding videos are typically rounded up to the nearest macroblock size. Bugs have been reported against Chrome's handling of video-to-WebGL texture uploads: see  Issue 672895  and follow-on bugs. However it's believed that the correct cropping is occurring at this point.

Could you please simplify the test case? There's a long discussion thread on the ShaderToy sample and I don't have time to sort through all of it. We receive a lot of reports daily. Please provide something similar to this test case which was written for that bug:

https://github.com/KhronosGroup/WebGL/pull/2202

Thanks.

@jmad... : 
on my lab's chrome    58.0.3029.81 linux,   size is UNchanged
on my lab's chromium  62.0.3202.62 linux,   size IS   changed
on my home  chrome    62.0.3202.94 linux,   size IS   changed
on IQ's     chrome    62.0.3202.94 windows, size is UNchanged
on my lab's chrome    62.0.3202.94 windows, size is UNchanged (today, but seems to have upgraded right before, maybe from 61. argh, I should have registered before, sorry)
on Firefox, size IS changed

I do now have some of the corresponding about:gpu files, but I'm not sure whether it is still useful since I don't confirmed having 2 identical systems giving different behavior.

Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We still need a smaller test case in order to begin investigation of this bug.

smaller test case: how simpler would you suggest it could be in shadertoy ? ( I can't do it outside of shadertoy, sorry). 

I could drop the font display machinery (and thus don't display any numbers) to just show the red (video size) vs white bar (texture size), for instance, but is it really the problem ?
This shader does basically nothing else that binding the video texture and showing the resulting textureSize().

Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Submitter, looking at that ShaderToy example I don't know what I'm supposed to be seeing and what's correct and incorrect. Please make the test case simpler and eliminate all unnecessary information.

Here is a simplified version: https://www.shadertoy.com/view/XllBR7

Depending on the browser and version, image size on GPU (width in white) might differ to image size on disk (width in red).
This 509x396 video get  512x396 on GPU  for firefox and some version of chrome.

Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Looks like a behavior change between M58 and M62. Ligi, can someone from QA team do a bisect?

Sure, routing to triage team for bisecting.

Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using chrome reported version #62.0.3202.94 and latest canary #64.0.3279.0.

Bisect Information:
=====================
Good build: 62.0.3194.0    Revision(496533)
Bad Build : 62.0.3196.0    Revision(497279)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/d6e0bb934a513d5b8e3a9fb6464eb821960e44a4..9fc174c5ecbe4617752c4c8682d29d0c8fea08b0

From the above change log suspecting below change
Change-Id: Ifcd8fb3fe991b93dfdbbe84d0a78e0efe08aea34
Reviewed-on: https://chromium-review.googlesource.com/629458

zmo@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-64 and requesting to merge the fix( (if its safe merge) to M-63

Thanks...!!

Your bisect is totally off.

The last known good is @464251, the first known bad is @464258.

My educated guess is crrev.com/464253: Fix broken draw/upload paths from videos to 2D canvas and WebGL.

I'll dig a bit further to see where the difference comes from.

Friendly ping to get an update on this issue as it is marked as stable blocker.
Thanks in advance..!

I don't think this should block any release. Remove Release-blocker label.

I will get to this bug soon.

This doesn't seem like it's P1. I'm setting to P2 but please change it back if this warrants P1.

Sorry, but I have to un-assign myself as I won't be able to work on this any time soon.