FerretBomb
Active Member
Not sure if this would be viable, but I was curious if it would be feasible to add a multi-frame motion blur effect to OBS?
Implementation would allow OBS to run internally and capture at a much higher framerate than is actually being streamed, while compressing multiple frames into a single overlaid aggregate frame; potentially providing a much smoother visual read on gameplay than is currently possible, while cutting down on decoding required, and possibly bitrate in use at the same time.
Anyone who has studied traditional animation knows that the reason standard analogue film looks as smooth as it does is due to the camera shutter being open allowing for motion blur to be captured on the medium; this effect was also used to great effect by Tex Avery in his cartoon works, and later by Warner Bros in much of the Looney Tunes series to provide flowing motion at EXTREMELY low framerates (many cartoons being drawn 'on twos', where each frame is intended to be doubled on camera exposure, halving the framerate).
Problems. Holding multiple frames in memory would increase VRAM usage somewhat, and GPU utilization. Compositing each frame in the blur would help to cut down on this however. System resource utilization would increase as sources were captured at higher rates internally, potentially beyond limits currently in place (people expecting to use this at 120+hz, slapping four frames together and kicking them over the line at 30fps) which might have unintended effects. Image sharpness could be reduced to visually noticeable levels, depending on implementation. Making this an optional tickbox would allow people to either use this or the standard no-blur method. Holding frames could potentially result in 'hitching', depending on implementation. Finally, the overlaid blur-frames could render more poorly under h264, defeating the entire purpose.
Primary load increase would be on the game/window capture, and compositing stages of the rendering pipeline.
But if this worked, you could have people running 60fps (or higher) locally, LOOKING like 60+fps on stream as far as smoothness goes, but only be consuming the bitrate of 30fps. While in motion, relying on persistence of vision to visually interpolate the frames even further, while any static elements would remain relatively un-blurred and sharp.
Implementation would allow OBS to run internally and capture at a much higher framerate than is actually being streamed, while compressing multiple frames into a single overlaid aggregate frame; potentially providing a much smoother visual read on gameplay than is currently possible, while cutting down on decoding required, and possibly bitrate in use at the same time.
Anyone who has studied traditional animation knows that the reason standard analogue film looks as smooth as it does is due to the camera shutter being open allowing for motion blur to be captured on the medium; this effect was also used to great effect by Tex Avery in his cartoon works, and later by Warner Bros in much of the Looney Tunes series to provide flowing motion at EXTREMELY low framerates (many cartoons being drawn 'on twos', where each frame is intended to be doubled on camera exposure, halving the framerate).
Problems. Holding multiple frames in memory would increase VRAM usage somewhat, and GPU utilization. Compositing each frame in the blur would help to cut down on this however. System resource utilization would increase as sources were captured at higher rates internally, potentially beyond limits currently in place (people expecting to use this at 120+hz, slapping four frames together and kicking them over the line at 30fps) which might have unintended effects. Image sharpness could be reduced to visually noticeable levels, depending on implementation. Making this an optional tickbox would allow people to either use this or the standard no-blur method. Holding frames could potentially result in 'hitching', depending on implementation. Finally, the overlaid blur-frames could render more poorly under h264, defeating the entire purpose.
Primary load increase would be on the game/window capture, and compositing stages of the rendering pipeline.
But if this worked, you could have people running 60fps (or higher) locally, LOOKING like 60+fps on stream as far as smoothness goes, but only be consuming the bitrate of 30fps. While in motion, relying on persistence of vision to visually interpolate the frames even further, while any static elements would remain relatively un-blurred and sharp.