In the latest Nightly, video's (incl. ads) on youtube.com are broken. The top half is black and white-ish, the bottom half is green, and there is a red line in between.

I'm testing on OS X with a fresh profile.

STR:

1. Visit for example https://www.youtube.com/watch?v=nYO86php_Wc
2. playback the video. Note that the ad is sometimes unaffected, so definitely skip to the video

ER: video should play without problems
AR: video shows color problems described above

@Matt, I ran mozregression, here's the result : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4ed6ec0c8220321b13c108ffaa7ab6cfc8d7698f&tochange=4558b3cfd6fe49647780a0ec86dfa97f0dd3adcb

Can you please post your about:support contents?

I can't reproduce this on my 2016 MBP, with either graphics card enabled.

Could you also paste the Codecs and Color lines from right click -> Stats for Nerds? For me, on the main video (not the ads), I get:

Codecs: vp09.00.51.08.01.01.01.01.00 (248) / opus (251)
Color: bt709 / bt709

I cannot reproduce the bug on my machine. I have a Late 2016 MBP running 10.15.6.

Which mac are you using? what graphic card does it have? are you using an external screen?

Can reproduce on my "mac" with an AMD 5700XT running macos 10.15.6
can't reproduce with a MBP late 2018

Can't reproduce on iMacPro (2017) with AMD Radeon Pro Vega 56.
Can't reproduce on MacBook Pro (2019) with Intel UHD Graphics 630.

Running on a 2019, 16" MacBook Pro (AMD Radeon Pro 5300M 4 GB & Intel UHD Graphics 630 1536 MB) on OS X 10.15.6. I'm using an external screen, but I can also reproduce without it. I can reproduce with both WebRender enabled and disabled. See attachement for about:support content.

Stats for nerds:

Codecs: vp09.00.51.08.01.01.01.01.00 (248) / opus (251)
Color: bt709 / bt709

I can reproduce the issue only when using discrete graphics. Intel UHD works fine. I hope that helps, let me know if I can provide anything else :)

I ran into this just now. MBP 16" 2019, AMD Radeon Pro 5300M + Intel UHD Graphics 630, I happened to be connected to an external display (4K, USB-c to display port). Nightly 81.0a1, build 20200805094932.

Matt, can we find an owner here?

(In reply to Nihanth Subramanya [:nhnt11] from comment #8)

I ran into this just now. MBP 16" 2019, AMD Radeon Pro 5300M + Intel UHD Graphics 630, I happened to be connected to an external display (4K, USB-c to display port). Nightly 81.0a1, build 20200805094932.

Spent some time trying to find repro scenarios:

1. All YouTube videos that I tried were affected (something like 5 different vids)
2. Netflix (tried just one) was affected
3. Prime video was affected - but not the ad at the beginning, only the actual TV show once it starts playing (tried just one)
4. Videos and gifs embedded in Reddit were NOT affected (I'm referring to vids uploaded to reddit, not YouTube embeds)
5. Videos embedded on cnn.com (again, direct cnn vids, not YouTube embeds) were NOT affected.

My only guess is that, when the window server is presenting the IOSurface to the screen, it's interpreting the data in the CbCr plane with a different stride than we do when we write the data into the plane. That's surprising though because we do correctly call IOSurfaceGetBytesPerRowOfPlane when writing the data.
Maybe we're allocating the plane with a stride that's higher than what the window server supports? One potential problem I can see is that CreatePlaneDictionary calls IOSurfaceAlignProperty with the wrong property name; it uses kIOSurfaceBytesPerRow to align the stride for a plane, and that stride is stored in a property with the name kIOSurfacePlaneBytesPerRow (note the extra Plane in there). I would be really surprised if that actually made a difference, but I suppose it's worth double-checking.

(In reply to Markus Stange [:mstange] from comment #11)

Maybe we're allocating the plane with a stride that's higher than what the window server supports?

Hmm, no, it would be lower than what the window server supports. The CbCr plane is displayed too small, so the window server is reading more than we give it, so it's using a larger stride than we are.

I think in the attached screenshot, the stride that the window server is reading with is 5/3 (=1.667) times the stride that we use for writing. That's off by a huge amount, and cannot be explained just by stride alignment.
I'm saying 5/3 because the pattern in the screenshot repeats every 3 "read rows", and in each 3-row chunk, red "sequences" with similar features are present 5 times.

(reported on Slack)

In this screenshot it seems the stride is off by an even factor of 2.

jya managed to reproduce this on one of his machines so we tested a few things.

Setting gfx.webrender.compositor=false doesn't appear to fix the issue, so it seems that this happens when WebRender's shaders read from the IOSurface. It may also happen when CoreAnimation reads the surface, it's hard to confirm that we were taking that path.

Hardware decoding appears to be enabled on that machine (for h264 videos), which also use NV12 surfaces and work fine. I can't explain the difference here.

Dumping the resulting sizes and strides from the IOSurface gives sane values:
Requested YSize 854 480, actual 854 480
Requested CbCrSize 427 240, actual 427 240
Strides: 896 896

Switching to use the apple specific YUV422 format instead of NV12 appears to fix the issue. I might move ahead with that for now, since it's pretty slow progress trying to understand the NV12 issue more.

On LInux, YUV420 is used for software decoded video and possibly hardware decoded VP8, otherwise NV12: bug 1629788 comment 27 + bug 1655747.

Backed outfor build bustage at MacIOSurface.cpp.

Backout link: https://hg.mozilla.org/integration/autoland/rev/7d6b5987454b78251e26abff2227f144b94094b6

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=9086f10df485113d245835c27bf984ccd96b6d0c&searchStr=OS%2CX%2CCross%2CCompiled%2Cdebug%2Cbuild-macosx64%2Fdebug%2CB&selectedTaskRun=VyGyzT5-TL-R_jYyIn-xlw.0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=312217610&repo=autoland&lineNumber=15349

Also this kind of failures started from there: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedTaskRun=dT4ouPseTpmV5jVl3Xl5Tw.0&searchStr=os%2Cx%2C10.14%2Copt%2Cmochitests%2Ctest-macosx1014-64%2Fopt-mochitest-plain-e10s%2C2&tochange=cea3ece6f1fffab7742b0f396bbd439bcef688c6&fromchange=f927522d89bc6435fae66b5873d0dbb83b30bf32

Failure logs: https://treeherder.mozilla.org/logviewer.html#?job_id=312224260&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=312224173&repo=autoland

These too: https://treeherder.mozilla.org/logviewer.html#?job_id=312224969&repo=autoland
TH link.

I don’t know if this will help with diagnosis and fixing, but I have a screen recording showing this problem spilling out well beyond the Firefox application window in Mojave on a 2015 15" MBP. WARNING: the video contains intense flickering, and could easily trigger epileptic seizure. Here’s the link: https://meyerweb.com/vid/2020/firefox-insanity.mov. Note that the flickering continues after the video is paused.

I have observed this both on the laptop display as well as an external monitor (which is what I recorded). It only happens for certain videos, like the one I recorded: https://www.youtube.com/watch?v=2lDFvVGtMuE

Other videos just show the color blotching, never the flickering, such as this one: https://www.youtube.com/watch?v=xLnapb-30hA

Excuse me, I mistyped. It’s an early 2013 15" MBP, not a 2015.

That's amazing. And scary.

Matt, if there's more trouble landing this patch today, you have my blanket r+ to land a patch that just disables the ioImage->SetData call.

https://hg.mozilla.org/mozilla-central/rev/b8dfd9c7a388

== Change summary for alert #26707 (as of Fri, 14 Aug 2020 09:08:10 GMT) ==

Improvements:

4% basic_compositor_video macosx1014-64-shippable opt e10s stylo 5.41 -> 5.17

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=26707

These glitches turned out to be caused by the missing word Plane in the following code:

  AddDictionaryInt(aDict, kIOSurfacePlaneBytesPerRow, bytesPerRow);
  AddDictionaryInt(aDict, kIOSurfacePlaneOffset, aOffset);
  AddDictionaryInt(aDict, kIOSurfacePlaneSize, totalBytes);
  AddDictionaryInt(aDict, kIOSurfaceBytesPerElement, aBytesPerPixel);
                                    ^-- missing Plane

We're fixing it in bug 1736670.