After my investigation, this could be an issue related to the compositor tile.
As the "splitting" line depends on the location of the player.

When WMPMSCompositor::UpdateCurrentFrame always returns true, it forces chrome compositor to redraw the player, regardless whether there is a new frame or not.

When WMPMSCompositor::UpdateCurrentFrame return value is based on whether we have a new frame or not, then in this test case, for most of the time it will return false, and when "request frame" is clicked, it will return true. (Obviously you cannot make your click rate close to 60FPS) 

Then I think something is wrong in the compositor that different tiles are not sync.

So I think this is not a duplicate of 606890.

Emircan@, do you know anyone familiar with compositor?

I do not think there is anything wrong with your generated stream, or with the player.

One evidence is that when the players shows a half-half frame, click any blank area (which invalidates the page and forces compositor to redraw the frame), the frame will look good. This means WebMediaPlayerMS does submit a good frame.

Thanks for the analysis Qiang. The alpha channel is triggering both these threading issues, but it indeed looks like the root cause of this issue might be different than 606890. As you said, when we have a partially rendered frame and click any blank area, the frame gets rendered properly. That would validate WebMediaPlayerMS's submission.

I am going to add ccameron@ and jbauman@ to see if they have any leads. ccameron@, this looks like it might be related to DirectRenderer::DrawFrame() that you mentioned in email. Can you take a look?

I'm not sure, but this can happen if, similar to  bug 606890 , the damage rect does not include the entirety of the changes in the frame. 

In  bug 606890 , the damage rect did not include the video, so none of the video updated. If the damage rect happens to include part of the video (maybe due to redrawing the button when it's clicked on) then part of the video will be updated and part won't.

Btw for  bug 606890 , qiangchen@ prepared this CL [0] to address. The issue there was WebMediaPlayerMSCompositor::UpdateCurrentFrame() falsely returning false when there was a race. 

Also, you can try with --show-surface-damage-rects to see the actual damage rects that are reported (though the issue won't actually happen with it enabled).

Sounds potentially related to  issue 595245  -- canvas synchronization issues.

I'm pretty surprised that we're seeing temporal tearing, but I could imagine that to happen.

This issue is reproducible on Windows as well. So I am not sure if it would be related to  bug 595245 .

Also, I tried --show-surface-damage-rects as jbauman@ suggested. The partially rendered areas completely correspond to the the damage-rect borders shown there. My question now is that how is damage rect decided from WebMediaPlayerMSCompositor. AFAIU, WebMediaPlayerMSCompositor only reports that frame is changed via UpdateCurrentFrame() but not a certain area.

If WebMediaPlayerMSCompositor::UpdateCurrentFrame returns true then VideoFrameProviderClientImpl::DidReceiveFrame will make the entire video frame as damaged. Damage rects that don't cover it completely are caused by damage to other layers.

Merge Blink>CaptureStream into Blink>MediaCaptureFromElement

Renamed Blink>MediaCaptureFromElement to Blink>MediaStream>CaptureFromElement. Moving issues to the new component.

Not reproducible on Mac any more.