The Mac OS X Thread

presjpolk

Edit history:

presjpolk: 2013-08-06 02:07:00 pm

2013-08-06 02:06:22 pm

HELLO!

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.

HDL

2013-08-07 09:38:12 am

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?

Attachment:

x264 settings.png

nate

2013-08-07 01:49:46 pm

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.

presjpolk

2013-08-08 12:12:42 am

HELLO!

I should have said this before. Thanks, HDL, for your constant research on this.

HDL

2013-08-14 10:11:45 am

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.

nate

2013-08-14 10:34:19 am

if you're already in communication with the author then it may prudent to mention that kumari uses ffmpeg and is open source.

HDL

2013-08-14 02:17:05 pm

He replied with a more in-depth response:

Quote:

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)

He replied with a more in-depth response:

[quote]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)[/quote]

nate

2013-08-14 02:32:30 pm

ok. still doesn't explain why you have more luck with kumari.

HDL

2013-08-14 02:35:16 pm

I know, but I can't do much other than wait and see. :/

HDL

2013-10-04 09:18:43 pm

So I recently learned about this right here. Anyone use it on OS X before? Seems you can, according to the driver page.

presjpolk

Edit history:

presjpolk: 2013-10-04 11:31:52 pm

2013-10-04 11:31:31 pm

HELLO!

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.

HDL

2013-10-05 06:45:51 am

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?

nate

2013-10-05 07:23:13 am

wonder if it's a lower quality conversion to yv12. does it only affect areas with color? can you post screenshots?

HDL

Edit history:

HDL: 2013-10-05 07:33:58 am

2013-10-05 07:33:29 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.

Attachments:

CocoaSplit.png

Kumari.png

nate

2013-10-05 08:03:22 am

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).

HDL

2013-10-05 09:42:37 am

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:

Attachments:

No PIP.png

PIP.png

DJS

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

2013-10-20 03:57:48 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

Attachment:

yua_HQ.mp4

HDL

2013-10-20 07:22:10 am

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.

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.) [i]except[/i] 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.

DJS

2013-10-20 09:59:13 am

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.

Attachment:

yuatrimed_HQ.mp4

presjpolk

2013-10-20 10:02:48 am

HELLO!

DJS you don't like Kumari?

DJS

2013-10-20 10:05:23 am

torch slug since 2006

i like it more than cocoasplit at the moment, because with kumari i can stream what i want to stream.

HDL

2013-10-20 03:20:28 pm

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).

presjpolk

2013-10-20 05:08:38 pm

HELLO!

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.

DJS

2013-10-21 02:40:49 am

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.

crismas

2013-10-22 12:29:20 am

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