obs-ffmpeg: Add ROI support for VAAPI#10136
Conversation
|
Looks fine to me, can't test it on my machine due to NVIDIA right now, hopefully one of our Linux folks can double check. |
|
Hello @nowrep, I would love to help you testing this code. I have an Arch Linux and an AMD GPU with AV1 encoder. |
|
You'll need to build it yourself anyway because there's no UI yet for ROI afaik. |
|
The compilation failed for some reason: I'm using Arch Linux, it was compiled inside a debian bookworm container using distrobox and arch itself both gave this error. |
|
@LucasSnatiago That said, I'd like this thread to not become a debugging session unless it's actually about the code in this PR. The comments should be focused on PR review itself so that maintainers don't have to sift through unrelated comments. |
|
@nowrep I compiled and recorded a video using it, but how can I test if it is really working? I thought it would be easy to notice the differences, but it is not. How can I enable it? Do you prefer screenshot of the recordings at the same bitrate with this feature on and off? Or another approach? |
You can test with this patchdiff --git a/plugins/obs-ffmpeg/obs-ffmpeg-vaapi.c b/plugins/obs-ffmpeg/obs-ffmpeg-vaapi.c
index a8e03fbcd..db629585b 100644
--- a/plugins/obs-ffmpeg/obs-ffmpeg-vaapi.c
+++ b/plugins/obs-ffmpeg/obs-ffmpeg-vaapi.c
@@ -429,6 +429,21 @@ static void *vaapi_create_internal(obs_data_t *settings, obs_encoder_t *encoder,
enc = bzalloc(sizeof(*enc));
enc->encoder = encoder;
+ obs_encoder_add_roi(enc->encoder, &(struct obs_encoder_roi){
+ .top = 100,
+ .bottom = 400,
+ .left = 100,
+ .right = 400,
+ .priority = -1.0,
+ });
+ obs_encoder_add_roi(enc->encoder, &(struct obs_encoder_roi){
+ .top = 500,
+ .bottom = 700,
+ .left = 500,
+ .right = 700,
+ .priority = -1.0,
+ });
+
enc->codec = codec;
enc->vaapi = avcodec_find_encoder_by_name(vaapi_encoder_name(codec));
There will be two regions with very low quality, one screenshot is enough. |
|
I made some tests and I could not notice any differences here are some tests: Original videoAll videos are recorded using your patch.
I record at 2k60fps so I made an increase in the area size for the last test (3.): I'm completely up to do a lot more tests if needed. |
|
It works with H264/HEVC, is broken with AV1. Fix FFmpeg/FFmpeg@3f863f0 |
|
I'm still not convinced it works, maybe I'm doing something wrong: None of them I can see any difference. All ffprobe details are available on the video description if you want to see. For some reason all first 4 videos have like 14Mbps bitrate, but with noticeable worse video quality do you know why it happens? I'm still using this code to set the ROI region: |
|
You need Mesa 24.0 or newer, other than that I have no idea why it wouldn't work for you. |
|
Well, that's my Mesa's version: Mesa version========== VULKANINFO ==========Vulkan Instance Version: 1.3.279 Instance Extensions: count = 24VK_EXT_acquire_drm_display : extension revision 1 Instance Layers: count = 12VK_LAYER_AMD_switchable_graphics_32 AMD switchable graphics layer 1.3.279 version 1 Devices:GPU0: I don't know if it is necessary, but here is my ffmpeg details: ffmpeg versionffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers What else can I check? |
RytoEX
modified the milestones:
OBS Studio (Next Version),
OBS Studio (Next Major Version)
I just took a look at these, but between recording from an already compressed YouTube video, the low target bitrate, and additional YouTube compression on Upload it's hard to tell what is or isn't the ROI influence. You can find test videos here for example: Pick any one without HDR/DoVi. Maybe try one of these in particular: The snow and waves should be fairly visibly different. Regardless, there are a couple noticeable areas. It's best to take 2 screenshots and overlay them, then switch between layers to make the changes more noticeable. Original: AV1 2.5k: Some areas that are particularly noticeable: There is also a noticeable sharp line at the bottom left that is only a few pixels tall, but that might just be capture artifacts. The entire part of the snake closer to the camera is also noticeably more blurry, but that may well be down to purely the bitrate since the existing blur from the depth of field compresses to more blur very easily. I haven't gone through the entire video and TBH I wouldn't be able to pinpoint where exactly the ROI starts or stops, but there is definitely a difference. Should also be noted that ROI is really only going to have a significant impact if you're bitrate starved. So I'm not sure if this applies to CQP mode at all since it adjusts bitrate based on a Quality target and doesn't try to cram quality into a given bitrate. All that's to say you might have to lower the Bitrate quite a bit more to see a difference. You can just artifically bitrate starve the recording by setting it to 500 kbps or something like that and you should see a noticeable difference. On a separate note:
There is a plugin from Rodney which should work with this. |
|
OK I did some testing of my own. Keep in mind this is with very extreme settings (reasoning above), and has been done with the aforementioned plugin (if you happen to be on Fedora, it's on my COPR). Recording settings were 250 kbps at 720p30, with the ROI cranked to the max to deprioritise. And yes the difference is very obvious, you can spot where the ROI area is. no-ROI.mp4vaapi.mp4In case you somehow can't see the difference in the VAAPI one, here's the ROI region: As a fun side note, this is what those same settings look like on x264: x264.mp4 |
5 participants
Description
Add ROI support for VAAPI
Motivation and Context
ROI support for VAAPI
How Has This Been Tested?
Tested with mesa driver using AMD gpu.
Types of changes
Checklist: