mirror of
https://github.com/zakk4223/CocoaSplit.git
synced 2026-05-15 22:00:34 -06:00
[GH-ISSUE #8] VBV buffer producing terrible quality and frame pileup #8
Labels
No labels
enhancement
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/CocoaSplit#8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @LordHDL on GitHub (Aug 7, 2013).
Original GitHub issue: https://github.com/zakk4223/CocoaSplit/issues/8
The stream skips and piles up lots of frames without a value set to VBV buffer. This is fixed with a value entered for VBV buffer. However, no matter the value, the stream quality is a mess compared to the specified bit rate.
@zakk4223 commented on GitHub (Aug 10, 2013):
I'd have to look at the x264 code to be certain, but I'm pretty sure not setting a value for VBV buffer completely disables any rate control, so it's not shocking that it would result in stream skipping/pile up due to it potentially exceeding available bandwidth.
As far as the quality, it's going to depend on the resolution, framerate and all of the settings in the x264 pane. Let me know what you have everything set to and I can tell you if something seems off.
@LordHDL commented on GitHub (Aug 10, 2013):
It's certainly not my bit rate, as I've streamed with different types of software for a long time and have it set to stay within limits.
I've tried many types of settings in CocoaSplit but here's an image of values that almost worked well.
Initially I tried setting only the bit rate and leaving the other fields blank, but the stream fails to upload without a CRF value entered.
@zakk4223 commented on GitHub (Aug 13, 2013):
I think I fixed this, it was a big mess of how to properly set timebase/fps settings for the x264 encoder vs everything else. I uploaded a new binary, so redownload and see if things are better now.
@LordHDL commented on GitHub (Aug 13, 2013):
Now I'm seeing this with the new build:
Any combination of values results in huge amounts of FPS out and pending frames. Happens with source video set to 60 or 30 fps.
@zakk4223 commented on GitHub (Aug 14, 2013):
Oops, I inverted the framerate fraction in the x264 settings. Turns out interesting things happen when you do 60/1 instead of 1/60... I never noticed it was pushing a bunch of bandwidth out on my local tests!
I just pushed a new build that fixes that.
@LordHDL commented on GitHub (Aug 14, 2013):
I did an extended test session with the new build. All fields must be filled or the stream either won't start, or will have issues. I found this strange because I asked the author of a different stream app how it handles the encoder and he says it doesn't set buffer, keyframe, or CRF values (it only lets you change preset and target bit rate, and leaves the other values empty). That particular app nets much better quality and no frame issues.
Yet with CocoaSplit if you do not set buffer, keyframe, and CRF it will have problems.
-No CRF = stream doesn't upload at all
-Without keyframe and/or buffer values = loads of pending output frames
-With buffer and keyframe values = no pending frames but significantly degraded video quality (though not nearly as bad as before recent fixes).
I don't know much about encoders but the discrepancy seems odd; they both use x264.
@LordHDL commented on GitHub (Aug 14, 2013):
The author of the other app just informed me that it uses ffmpeg as well. Not sure how relevant that is here but I mention it just in case it'll help any. The source might help too: http://nate.quandra.org/kumari/kumari_source.tar.gz
@zakk4223 commented on GitHub (Aug 14, 2013):
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. 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. VBV+CRF attempts to smooth things out, but it may do so at the expense of quality. 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.
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. I'm moving to a design where I just grab frames at the specified framerate so it should result in saner rate control. I should probably add defaults for some of the x264 settings too.
Also 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 working on that right now too (and that is part of the reason I'm changing how frames are grabbed from sources)
@LordHDL commented on GitHub (Aug 15, 2013):
Writing this here as I can't seem to find a way to send a direct message to you. Would you mind if I informed Twitch about your app? According to Jared they are looking into providing better information for Mac streaming and it seems all they know about is Wirecast (prohibitively expensive) and FMLE (ridiculously antiquated).
@LordHDL commented on GitHub (Aug 26, 2013):
I got this from the August 22 build; FPS out remains at 0 and frames pile up. Happens with CBR mode on or off, and any combination of x264 values.
@taintedzodiac commented on GitHub (Dec 10, 2013):
Did you happen to find a solution to the "Zero FPS Out" issue in the previous post? I've just started using CocoaSplit with CamTwist and despite trying all sort of x264 settings, nothing seems to be working. Latest build downloaded this morning, running on Mavericks. Thanks!
Have also tried Syphon and AVFoundation, same issue.
@LordHDL commented on GitHub (Dec 10, 2013):
This issue was since fixed for me in an updated version. I also have Mavericks and stream all the time with x264 and Syphon. All I can say is try deleting your settings file in Application Support/CocoaSplit and let it create a new one. If it's still happening then you likely have incorrect x264 settings.
@taintedzodiac commented on GitHub (Dec 10, 2013):
Thanks for the quick response. Sadly after removing the settings again just
now, same problem persists. Thanks again anyway!
On Tue, Dec 10, 2013 at 2:46 PM, LordHDL notifications@github.com wrote: