obs-browser: Update default size

[cg2121]

Description

Changes default size to size of canvas.

Motivation and Context

A better default.

How Has This Been Tested?

Created browser source.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.

[RytoEX]

I prefer something like this, but it's probably down to personal preference.
https://github.com/RytoEX/obs-browser/tree/change-default-size

[notr1ch]

Do we even need a v2 here? We're not changing anything except the default value so users shouldn't experience any unexpected issues as the defaults are only used on source creation or reset.

In the event a user does restore the browser source back to defaults (and is thus presumably OK with losing all their settings and getting new defaults), it would be confusing that the defaults of a legacy browser source do not match the defaults of a newly added browser source, with no visible way to distinguish between them.

[WizardCM]

Yes, v2 is required because the defaults aren't saved on source creation. It's the reason v2 exists at all.

[WizardCM]

The feedback I provided in my previous review has not yet been responded to, so I don't believe this should be merged as-is.

[notr1ch]

Ah I see, I didn't realise our defaults worked like that.

[WizardCM]

So, extending what I said above, today I learned that if you create a browser source and click "OK", all settings are saved because of the way the functions in the browser source are written (this should not actually be the case, but it is). So it's safe to assume that any browser made since the v2 rewrite (at least) has the current default resolution saved.

[tt2468]

I personally have reservations about this. I use OBS on very lightweight machines and browser sources account for most of the resource utilization on them. Making the default size the size of the canvas will end up leading to our users creating larger browser sources than necessary, and therefore increasing the performance footprint of OBS.

If I were to tackle this issue, I would add a way for the content in the browser source itself to announce a "optimal resolution" to obs-browser, and obs-browser could queue an obs_source_update() with the new width/height settings. This would improve user experience and make browser integrations more seamless.

[RytoEX]

I personally have reservations about this. I use OBS on very lightweight machines and browser sources account for most of the resource utilization on them. Making the default size the size of the canvas will end up leading to our users creating larger browser sources than necessary, and therefore increasing the performance footprint of OBS.

If I were to tackle this issue, I would add a way for the content in the browser source itself to announce a "optimal resolution" to obs-browser, and obs-browser could queue an obs_source_update() with the new width/height settings. This would improve user experience and make browser integrations more seamless.

This proposed change is the result of conversations at TwitchCon and in our Discord server where users mentioned that overlay tools expect/encourage you to build the overlay at canvas size or that they build them this way unprompted because that is intuitive. The fact that our default browser source size is neither the canvas size nor even the same aspect ratio, means that they have to change it in the settings manually each time. Resizing the scene item with transform settings produces sub-par results.

It has been suggested before that obs-browser should support meta tags that specify width, height, and FPS. It was just never implemented. See here: https://github.com/obsproject/obs-browser/blob/e54c9f14b3d7c1835853d130dcb135d3cfaf41e8/data/error.html

If you wanted to try to implement something like that, be my guest. Though that wouldn't necessarily help with alerts or overlays unless the providers also then implemented them.

[tt2468]

Fair enough. I do believe in the meta tags idea, so I'll try to find time to work on that.