Forgot to mention that this stays for few seconds and then video renders normally,but happening quite frequently as of now I don't have 100% reproducible steps. 

[Bulk Edit]
URGENT - PTAL.
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 M62.

Further check when I ran videos with "--disable-gpu" I didn't see the issue.

+media folks. This warning's a bit worrisome; do we use pow() for colorspace conversion  / gamma correction on videos?

[1972:3152:0814/191205.544:WARNING:angle_platform_impl.cc(41)] : rx::HLSLCompiler::compileToBinary(224): C:\fakepath(69,10-34): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(91,10-34): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

Yes we do, but the warning is a bit on the paranoid side. It doesn't actually mean that we are giving negative values to pow(), it just means that it can't tell from the code that we aren't.

Does your laptop have an ICC profile?
If so, can you attach it here?

Confirm, the "pow" warning is spurious.

From the attached about:gpu

GL_VENDOR	Google Inc.
GL_RENDERER	ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0)
GL_VERSION	OpenGL ES 3.0 (ANGLE 2.1.0.0d2ecb4ea992)

IIUC this is software GL. Is there a way to force that for testing? Perhaps that path is having trouble with some shaders?

This is not software GL. It's ANGLE's Direct3D 11 backend running on, apparently, an Intel HD 4400.

D'oh -- thanks for the clarification.

I attempted to reproduce by repeatedly seeking around the first segment of that video (before the first commercial) and playing ~30 seconds each time. One time I saw corruption of the entire video, as though the video stream itself had become corrupted. This resolved itself after a few seconds. Not able to reproduce the original report.

The GPU in this laptop, I realize, isn't really comparable to the HD 4400 in the submitter's laptop. I'll retest on an HD 5500.

Deleted: gpu.html 50.7 KB

gpu.html 50.7 KB View Download

Note: the laptop from #12 is a Razer Blade.

Also not able to reproduce after seeking around that video quite a bit on a Lenovo X250 with Intel HD 5500 GPU, as well as opening the video in a second tab and then closing it.

I think this might be related to  Issue 702369 , where it seems there's some bookkeeping problem related to the texture pool used by the hardware video decoders, but am not sure. Relating these two bugs together, though this one doesn't really block the other.

Unless this is readily reproducible we can't call this a release blocker. We'll try again tomorrow on the affected machine.

Deleted: gpu.htm 55.3 KB

gpu.htm 55.3 KB View Download

The original image isn't just green, it's also blocky, which makes me think that stream corruption could be the cause here.

Agreed.

[Bulk Edit]
URGENT - PTAL.
M61 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. 

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M62. Thank you!

Note: We will only have 2 beta releases before Stable promotion. Plan is to cut M61 Stable RC on 08/31/17.

Update : I wasn't able to reproduce the issue again for last couple of day's.

Can we remove the blocker label, since as per above comment Prudhvi is unable to reproduce it.

Thanks.!

I saw this issue again last night, captured network logs and shared with Ken for further review. As per past conversation with Ken this must be due to low internet bandwidths which must be causing this issue once that is confirmed we can remove the stable blocker.

pbommana@: thanks for the logs. With the low incidence of this problem even on your machine, and the likelihood that most people aren't experiencing it, I'm downgrading it and removing the ReleaseBlock label.

rch@: you and I discussed this case offline, and you offered to take a look at it if it were reproducible. I put Prudhvi's logs here (Google employees only, sorry):

https://drive.google.com/open?id=0B5DES7PYkZBLX1A0dndYOS1KUjg

Could you please take a look and see if anything jumps out at you? I took a look but don't see anything obviously wrong in the Timeline.

I can see that folder in drive, but I don't see any logs there. Am I doing it wrong?

Ok, I was able to see the log and nothing jumps out to me as the network stack misbehaving. The video appears to be served from Akamai, and is not QUIC so that rules out my particular area of expertise! *whew* :)

That being said, from the QUIC evens, I do notice some periods of significant QUIC packet loss, which is consistent with an earlier assertion that low bandwidth would be causing this issue.

Looking at the URL_REQUEST events for the video itself, I don't see anything that looks wrong. So if low bandwidth is an explanation for this behavior, I'd be inclined to believe that's what's happening here.

Does that help?

OK, thanks rch@ for your diagnosis. pbommana@: apologies but I'm closing this out as it doesn't seem to be a widespread problem.