Stinger transitions lagging after adding StreamElements browser source
So I made a few stinger transitions recently for OBS and they ran fine. But then I tried Stream elements for the first time making two browser sources (one for each scene) and after putting in the second stream element source (which contains an animated screen border and an animated chatbox I made for each). the transitions starts lagging and wont perform properly. Should I even be adding in animated borders and chatboxes in the first place in Steam Elements? or is that more for alerts specifically?
also a note on rendering, I've rendered everything in Davinci Resolve with:
Format: QuickTime
Codec: GoPro Cineform
Type: RGB 16-bit
Quality: Best
1920x1080 resolution with "Export Alpha" checked
I then converted the .mov files with ffmpeg and using this cmd line:
"ffmpeg -i "sourcefilename" -c:v libvpx-vp9 -pix_fmt yuva420p "targetfilename".
Is there a better alternative rendering format to use in Davinci Resolve than this? Or will the batch file that Eposvox provided in his video do the job already with my current rendering settings?
36 Replies
The thing to note is that there is no GPU that supports hardware decoding of a video with an alpha channel, it will always be decoded on the CPU
The main issue with decoding video is decompressing it, which is the reason that codecs CineForm, ProRes, and raw AVI are recommended is because they are already basically not compressed, meaning they have much lower CPU usage to decode
Since Stream Elements isn't going to let you upload a multi-gigabyte stinger file (AFAIK), you're stuck using VP9 which is still takes some considerable CPU power to decode, hence why you're getting render lag
I see. Well 720p doesnt look bad (looks the same honestly) with the transitions at least so I could just re-render those uncompressed. but maybe I should render my chat boxes and borders to 720p as well and re-upload them to stream elements?
As nice as stream elements is, you don't really need to set up actual scenes or stinger transitions with it, you can do that all locally. If you have an SSD that isn't used for OBS recordings or for running games off of, you can just have the CineForm / ProRes / AVI media files on that SSD and use them directly in OBS. Saves you the hassle of configuring things in Stream Elements (unless you're specifically trying to utilize their editor features) and it'll solve your render lag issue when using transitions and general media sources
Als in the upcoming OBS 29.1 update, stinger transition media files will be cached so after the first use of the stinger file it should basically never have render lag afterwards
See thats also what I didnt know earlier and was trying to figure out. have everything in an SSD or use stream elements, whichever makes OBS use less of my CPU/GPU resource so I can stream properly
I was under the impression you need stream elements to reduce hardware resources
As it stands it's less intensive to use local files with lower compression codecs than stuff like Stream Elements
Stream Elements just gives you a browser source of your media which still requires you to decode it, excet your selection of codecs for those files is limited
Can I put my own custom alerts in OBS too without stream elements?
By alerts I mean like new followers, donations, twitch bits, etc
AFAIK alerts are the one thing you have to use Stream Elements for, but there may be other tools online that can let you use local files for them. There are tools like SAMMI and such that let you just have something happen when one of those events are triggered, but it'll require more work to set up than Stream Elements
I see. So things like borders and chatboxes art can stay locally but alerts require something like stream elements to track people joining or donating
The way alerts work is through an API - Twitch and YT basically wait for an event, and when it's triggered then any registered API service will receive a notice of the action
The reason I suggested SAMMI is because it receives notifications for events just like Stream Elements does, but it lets you say what to do for a given action. Stream Elements does a lot of the work for you by hosting their own services, whereas SAMMI gives you more control over
There's also StreamerBot that lets you do a lot of the same stuff in a different way
Alright Ill have to do more experimenting and check out SAMMI
Pretty much everything can be done locally when it comes to twitch because of its api.
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
So I was watching Eposvox's video talking about using his batch script to convert to AVI and when I tried converting one of my .mov files, I get a message saying "too large number skipped frames 76799 > 6000" and my transition lags a bit playing on mpv player even.
(yes its saids xbscreen.avi in the screenshot but I was testing with my transitions as well)
I do not know what to do here but is it something to do with how I render out everything in davinci resolve?
Are your davinci resolve exports using variable frame rate?
uhh I dont think so, but how do I check exactly?
I usually render out everything in 60fps and my timeline is 60fps too
Output scaling is checked to match timeline settings as well
What are you current export settings?
Format: QuickTime
Codec: GoPro Cineform (though I'll probably change to uncompressed wtih BGRA 8-bit type later if im re-rendering the resolution to 720p)
Type: RGB 16-bit
Quality: Best
1920x1080 resolution with "Export Alpha" checked
bypass re-encode when possible being checked as well
ahh I shouldve said earlier everything else was untouched in the export settings
are the settings okay or....?
The settings should be fine, I'm just wondering why that issue is happening
Can you try opening a command prompt window in the location where the exported video is and run this command:
ffmpeg.exe -hide_banner -i "YOUR_VIDEO_FILE.mov" -pix_fmt rgba -map 0 -vsync 0 -c:v rawvideo -c:a copy "YOUR_VIDEO_FILE.avi"It still gave me the same message
If you're willing to, can you upload the exported file somewhere like Google Drive or the like and share it with me (can be over DM's if you prefer) - I can nvestigate more on my end
Okay Ill send it to you later. Im just out currently.
Google Drive: Sign-in
Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).
there
Ok I'll investigate and test things out and let you know what I find
Well I haven't found the exact reason why ffmpeg is having issues converting your cineform export into AVI, but I can confirm that this process is the issue itself
I converted your export to H264 and H265 without issues, and then converted those to AVI without any issues either
So it seems like it's just Resolve's cineform export that's problematic
wait was that one cineform? I thought I exported as uncompressed
well that clip I've sent you I mean
Whoops yeah I meant uncompressed
Does the same issue happen when you export it with cineform?
yea, I tested my original transition clips before
those were exported with cineform
Just a test, can you export it as uncompressed in RGBA format instead of BGRA
Then try converting it to AVI with the commands from earlier
WAIT
I seemed to have figured out a solution, no need o re-export it
ffmpeg.exe -hide_banner -i FILE.mov -pix_fmt rgba -map 0:v -c:v rawvideo -map 0:a -c:a copy FILE.avi
I changed the -map 0 to -mp 0:v and added -map 0:a
Basically in the previous version, ffmpeg seemed to be having issues thinking there might be more video/audio streams than just the 1 video and 1 audio streams, and would try encoding these non-existent streams ontop of the ones that do exist
By specifying -map 0:v before the video options and -map 0:a before the audio option, we were telling ffmpeg to specifically transcode just the 1 video stream to rawvideo and keep the 1 audio stream as isOkay no error message this time but the avi file is still 1.03 GB, the same size as original. Is that correct though?
Though the alpha works here so thats good at least
because if the file is supposed to shrink more, then theres still a problem, otherwise, its all good.
Well if you're going from uncompressed to uncompressed you shouldn't be seeing any file size changes
ah wait yea true
There might be some changes because of the pixel format arrangement or the container format but there shouldn't be any iscernable difference
alright hopefully I SHOULDN'T have anymore issues adding my overlay stuff inside of OBS. Yes I got a build that has a 4090 but at the same time, if my second PC is gonna handle OBS (this one) then this whole process is needed anyways. since this computer has an intel i7-7700k and GTX 1070 in it
Thank you for your help. if webm in 720p still gives me issues then I can now use avi with that command you given me