In the old tab capture implementation, there was some logic to set the capture size to a "nice rounded" width X height (https://cs.chromium.org/chromium/src/content/browser/media/capture/web_contents_video_capture_device.cc?rcl=0338b5c1e3c8bbd80395e4d5f5060d5d7d531f55&l=536).

The new FrameSinkVideoCapturer should account for such effects. One example is when 1365x768 capture resolution is chosen: This can cause quality degradation due to the odd-valued width and the I420 image format.

Idea (not vetted): It seems like FrameSinkVideoCapturer should set up the CopyOutputRequests to crop and scale such that: 1) scaling quality is improved; 2) the captured result jives well with the I420 image format and downstream encoders (which tend to encode in 8x8 blocks). It should be reasonable to crop the source and result by a few rows/columns such that scaling quality is maximized.

Also, if the parameters are chosen correctly, it may be possible to drastically improve performance as well: For example, the "bicubic upscaler" first step in GLHelperScaling could be avoided.