rfcs
rfcs copied to clipboard
Add RFC: Browser Transition
Description
Create a new "Browser" transition within the obs-transitions
plugin that harnasses CEF (via obs-browser
) as its backend. Basically a "Stinger" but instead of a 'Media Source', it's a 'Browser' source.
Motivation and Context
The web browser is a powerful tool on its own. As a source in OBS, it's great for building dynamic overlays.
However, JavaScript developers are used to being able to control everything. In this case, a source cannot (and shouldn't) do anything related to transitioning from one scene to another. This is where a Browser transition makes sense, especially as they expose access to transition_start
and transition_stop
events. Check the RFC for full details.
View the RFC
I currently have custom HTML based transition animations which would benefit from having OBS browser transitions as an official feature. They differ from a stinger transition in that there is no hard transition time point where the animation covers the entire screen. Instead I use an object that swipes across the screen along a single linear vector and extends to the edges of the screen 90 degrees perpendicular to the swipe vector, with the original scene on the leading side of the current location of the swipe and the new scene on the trailing edge of the swipe. I do this by taking the object I want to swipe across the screen and scaling it to hit the edges of the screen, then placing it on top of a green background extending off to one side in order to key it out later.
The whole setup works for transitioning from a single scene to another single scene but it isn't as flexible as if I were able to use it as a transition officially. Also there are some browser source timing issues that can get in the way due to the time it takes for browser source to load and begin rendering, which often causes the start of the animation sequence to stutter across the screen and requires a hard coded delay in the start of the CSS animation to smooth things out, which in turn makes the transition itself lag by 300-500ms or so.
In short my current method is an ugly hack but it works for some usage scenarios at least, and I've noticed other content creators using this same technique, namely Harris Heller's video editor Sam uses this same trick.
As an example, I have an electric guitar stretching bottom to top of screen that starts out in a browser source off to the left of the screen, then after a short 300ms or so delay in the CSS animation it swipes across the screen from left to right until it vanishes off the right side, dragging behind it a full screen green background, which I key out. The guitar never fills the entire screen, so I can't just toggle from one scene to another, rather both are showing simultaneously as the guitar swipes across the screen, and in one variant the guitar has a whammy bar which I have spinning around in a circle using CSS animation also.
Browser source transitions would greatly expand what is possible in transitions in a very flexible way. If implemented, hopefully someone can figure out a way to make the animation start immediately without any browser source startup lag delaying or stuttering the animation like browser source does though. I imagine pre-caching things somehow might solve that problem.
I am very interested in browser-based transitions. I currently use the following hack:
- Play a Stinger that is simply a transparent
.mov
file of a known duration. - Using
obs-websocket
, detect when that Stinger has begun playing, and then play an animation in a Browser Source present on all scenes, which then acts as the actual visuals of the transition.
This works, but like all hacks, places limitations on me and can be fragile. Having first-class support for this concept in OBS itself would be great, and would be a truly unique thing that sets OBS apart from traditional hardware-based vision mixers. Fully dynamic transitions are a fairly unexplored part of broadcast design simply because nothing really supports it.
On that matter, the WebVfx plugin for the MLT framework supports loading web pages or QML layouts as transitions, filters or frame producers: https://github.com/rectalogic/webvfx. It doesn't do GPU texture sharing though.
So this would be like browser sources acting as stingers? The problem is you probably can't actually use them in any way other than that. It's not like you can transfer the two transitioning backbuffers to the browser.
Yes, basic stinger-style transition but with a webpage rather than a video is what I'm aiming for with the current RFC. No backbuffer craziness expected.
I was notified of this rfc after I published my Browser Transition plugin. This plugin does not resolve all points in this rfc, but it can be a good start.
After discussion, I am content leaving this task to a third party plugin which already exists for now. If there's additional functionality that is missing from the plugin, work and efforts can be made there to bring it up to actual user requirements.
Moving to Final Comment Period, with Disposition Close.