If the number goes up it means frames are piling and the stream is skipping for viewers.

Ideally 'pending frames' in CocoaSplit should always say 1. Just set it to whatever gives you a good balance between CPU, quality, and stability. Default is 23, and a lower value is higher quality but will increase the chances of frame pileup if your game has a ton of fast movement/changing pixels, making your stream skip for anyone whose connection can't handle the spiking. VBR spikes bit rate depending on how much is changing in the video, but if you want to use it for any reason then you should set CRF to something reasonable. With CBR on leave buffer and CRF at 0 as they are primarily for VBR. If youve ever wanted to start video editing with a simple program, this one will be a good choice. iMovie is the native video editor from Apple for Mac devices. Depending on your resolution and nature of your game though you might have to raise bit rate a tad, but 1200 should be fine for lower resolutions. Your Companion for Deleted Files Recovery in Mac OS X 10.8.5+ and for Windows XP/Vista/7/8/10. It will stabilize your bit rate for viewers making skipping and frame pileup far less likely for them. With 10 Mbit upload you should definitely enable CBR. What's your issue with CT? Works great for me except for the PIP scaling thing. I don't know about the new version of Yua, though. You can encode but so far every encoding software I've tried (Yua, Handbrake, etc.) except Anri-chan will not trim the audio along with video, so the result is a video of the same length as the source with the same audio but trimmed video.

When I spoke to Nate about it he confirmed that it has an audio bug. It says recordings from Norichan won't encode properly. He replied with a more in-depth response: I'm working on that right now too (and that is part of the reason I'm changing how frames are grabbed from sources)

I should probably add defaults for some of the x264 settings too.Īlso a lot of this doesn't matter since Twitch is going to start enforcing strict CBR mode and 2 second keyframe intervals soon. I'm moving to a design where I just grab frames at the specified framerate so it should result in saner rate control. That said, the current architecture just takes frames as they arrive from the source and encodes them, if the frame rate starts fluctuating or is too slow (the laptop webcams seem to be terrible about this) I'm pretty sure that really messes with x264 rate control. There are lots of discussions of proper settings of rate/buffer/crf out there, for reference I'm setting things up more or less how OBS does. VBV+CRF attempts to smooth things out, but it may do so at the expense of quality. It can result in really spikey bandwidth use it'll happily use lots more bandwidth temporarily if it hasn't used as much recently, so long as it hits the average. Just setting bit_rate is effectively average bit-rate rate control, and x264 may or may not be good at hitting that target depending on what's going on.

Handbrake for mac 10.8.5