Roll Eyes
Lips Sealed
page  <- 12345678910111213 -> <- 1 .. 4 .. 13 ->
List results:
Search options:
Use \ before commas in usernames
Edit history:
presjpolk: 2013-08-06 02:07:00 pm
Have you found HD capture hardware that's CamTwist 3.0/AVFoundation compatible and will give you 60FPS through that?

Heck, forget the HD even, I guess. I haven't heard of diddly.
Nope, I know nothing of CT's compatibility with hardware.  I'm aware some people use Blackmagic with it but nothing beyond that.

Anyway, I've been doing a lot of testing with CocoaSplit and I'm close to having it be a usable option, but there are a couple of issues:

- Frames pile on (pending output) when no value is set for VBV buffer.
- Stream quality is garbage if a value is entered for VBV buffer (see attachment).

x264 is not my forte, but based on what I've read and on speaking to others, VBV buffer is supposed to limit the quality to no more than a specified amount (as I understand it, please correct me if I'm mistaken).  Furthermore, the stream will fail if no value is set for CRF.

When I asked Nate about the way Kumari handles things, he said it doesn't set any buffer or CRF, yet it manages to stream mostly fine.  Anyone know what's going on here?  Bugs, perhaps?

lol well those are definitely x264 settings. so what i read on the website about it being hardware encoding is apparently false. bogus that it forces you to enter those values. the presets are supposed to be there so you don't have to manually enter values.
I should have said this before. Thanks, HDL, for your constant research on this.
I brought up the CocoaSplit issues to the author and he released a build with fixes.  A test stream earlier confirms that it can work for extended sessions, but still seems to have some 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 notified the author about this too just in case there are more bugs afoot.  I'm not sure if this is normal x264 behavior or not, all I know is these values are not needed for Kumari and it has no trouble with frames or video quality.
if you're already in communication with the author then it may prudent to mention that kumari uses ffmpeg and is open source.
He replied with a more in-depth response:

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)
ok. still doesn't explain why you have more luck with kumari.
I know, but I can't do much other than wait and see.  :/
So I recently learned about this right here. Anyone use it on OS X before?  Seems you can, according to the driver page.
Edit history:
presjpolk: 2013-10-04 11:31:52 pm
I own that. It doesn't hook up to a computer.  You install an HDD onto it, and then you copy stuff off with a USB drive. You can only use it to record, not to stream.

I very much like it for recording.  But it doesn't solve the stream situation.
Cool, solves that mystery for me.  I'll add it to the OP.

And just in case this helps anyone, I revisited my CocoaSplit troubles.  Using the latest build (August 22), I couldn't get it to work without dropping frames until I deleted the settings file in Application Support -> CocoaSplit.  After that, different settings worked great and Twitch reported an "excellent" configuration.

The video itself still looked a bit fuzzy compared to Kumari with the same settings.  Anyone know if CamTwist/Syphon mess with video quality in any way (resolutions being the same)?  Or perhaps it's the CBR option in CocoaSplit?
wonder if it's a lower quality conversion to yv12. does it only affect areas with color? can you post screenshots?
Edit history:
HDL: 2013-10-05 07:33:58 am
First one is CocoaSplit, with Norichan at 480 and stream resolutions at 240 (when Norichan was at 240 CocoaSplit produced really fuzzy video).

Second one is Kumari, with Norichan and stream resolutions at 240.

Even with the game window at double the size, the stream was still a tad fuzzier and the colors are different.

the scaling of the text on the left makes me suspicious that the game video is being scaled multiple times (even though it ends up the same size); this could easily introduce the blur. the apparent gamma difference could be the result of a yv12 conversion with different clamping from the ffmpeg one kumari uses. it could also be an artifact of the way it captures the screen data - kumari just does a generic screenshot whereas there are other, more efficient ways of capturing the screen that may introduce artifacts (though i had never considered this before now, and it seems out of place on an apple system).
Quote from nate:
the scaling of the text on the left makes me suspicious that the game video is being scaled multiple times

Well now I just feel silly.  With CT I'm using the PIP feature to position things where I want them to be, and have to scale them up so they fit the screen properly.  I'll bring it up to SteveG in case there's a glimmer of hope that it'll be improved someday.  CT is also the one changing the color apparently (though I don't really mind it).

No PIP and PIP differences:

Edit history:
DJS: 2013-10-20 04:15:46 am
DJS: 2013-10-20 04:15:34 am
DJS: 2013-10-20 04:09:14 am
torch slug since 2006
in the first post of this thread, you say that norichan recordings in 10.8.4 doesnt work. well, im running 10.8.5 now and i was able to do this. (norichan + yua on 10.8.5) - so it seems to work again. if this is already known, or if i am misunderstanding the 10.8.4 statement, then i apologize.

been trying cocoasplit too. excellent application, very fast, but i wish it had "good screen regioning" built in, because camtwist is a piece of shit. im just gonna have to stream my whole desktop, or use kumari, until then.

hdl or anyone else: what are your x264 settings in cocoasplit? my current settings:
anything i should change? the vbv stuff im assuming is good because i have 10mbit upload (i upload in ~1200kbps i.e.), and the keyframe is set to 2 because twitch wants that. preset i have set to superfast because that was what i was using in kumari afaik. im just not sure about the baseline and CRF, and if i should have CBR mode enabled

It says recordings from Norichan won't encode properly.  When I spoke to Nate about it he confirmed that it has an audio bug.  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.  I don't know about the new version of Yua, though.

What's your issue with CT?  Works great for me except for the PIP scaling thing.

With 10 Mbit upload you should definitely enable CBR.  It will stabilize your bit rate for viewers making skipping and frame pileup far less likely for them.  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.  With CBR on leave buffer and CRF at 0 as they are primarily for VBR.  Kumari sets tune to zerolatency.

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.  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.  18 is usually a recommended value.  Just set it to whatever gives you a good balance between CPU, quality, and stability.  Ideally "pending frames" in CocoaSplit should always say 1.  If the number goes up it means frames are piling and the stream is skipping for viewers.
torch slug since 2006
tried trimming and yeah, i see the problem now. interesting. i wonder why that is... (attached)

my issue with CT is that it uses too much cpu. thats it pretty much.

thanks for the setting advice. i will try them out later on when i stream.

DJS you don't like Kumari?
torch slug since 2006
i like it more than cocoasplit at the moment, because with kumari i can stream what i want to stream.
Quote from DJS:
my issue with CT is that it uses too much cpu. thats it pretty much.

If you're still using the Mac Mini, it's probably the Intel HD 3000 causing this (among other stuff).
Nah CT is just a pig Smiley  But make sure you experiment with both Desktop and Desktop+.  One is faster than the other on your system, in all likelihood.  On my old iMac, Desktop was faster. On my new  one, Desktop+ is.
torch slug since 2006
ive been using Desktop+ so i guess i could try the other one.

and yes im still on the mini with the hd3000. apart from streaming, i find it plenty fast. im considering a ssd though.
Hey all,

I was wondering if anyone experienced sparks from their thunderbolt cable? I was planning on streaming today (I use a blackmagic intensity shuttle) and it usually works fine but it started sparking pretty bad trying to plug it in. I tested to see if it was the plug itself by unplugging it out of the bmi and plugging it in first to the usb and it sparked trying to plug it into the bmi. I have a hunch it's the cable itself and not my usb port since my other cable for my dual monitor works just fine.

Either way I'm contacting Apple tomorrow, I just wanted to see if anyone here experienced this.

Thanks Smiley