I'm working on integrating screen capturing in a framework I'm expanding. I'm requesting the MediaStream of the screen through the getDisplayMedia method and recording it using the RecordRTC library. Both Firefox and Chrome allow the user specify what exactly will be shared, like the entire screen, a specific window or a single tab (only Chrome). I noticed the choice here significantly affects the resulting video file size. The results below are from 30 second recordings, where the browser window filled the entire screen.
Chrome:
Entire Screen: 3.44 MB
Window: 0.81 MB
Tab: 0.15 MB
Firefox:
Entire Screen: 5.23 MB
Window: 3.56 MB
Ofcourse when recording a window opposed to the entire screen the resolution becomes slightly smaller. Like for the firefox recording: entire screen = 2560x1440 and window = 2488x1376, but I don't think that should make that much of a difference.
I've tried looking at the Chromium source code (as that's open-source and Chrome based) to figure out what the difference is between the different options, but can't seem to figure out what is going on. None of my Google searches were successful either.
Does anyone know what the reason for these large differences is?
I'm on Ubuntu 20.04 if that makes a difference.
This is because when you record the window or the tab, the browser is responsible for the rendering of the content. So it knows when something new has been painted and when nothing has been painted.
You can clearly see this in Chrome where they'll even fire a mute event after 5 seconds on the VideoTrack of tab-capture where nothing is animated.
So, they know there is nothing new being painted, they don't pass anything to the stream and instead create a single frame with a duration of long time.
When capturing the desktop however, they're not responsible for the rendering anymore and don't know if something has changed: they have to pass every frame as a new frame.