Roll Eyes
Lips Sealed
page  <- 12345678910111213 -> <- 1 .. 3 .. 13 ->
List results:
Search options:
Use \ before commas in usernames
Edit history:
presjpolk: 2013-06-28 11:44:18 am
OK this is the dumbest thing in the world but it may work:

Quicktime Broadcaster local rtp to ffmpeg

ffmpeg rtmp to hashd.


Results: It works but ffmpeg is really bad at keeping up and I have to drop to 15fps to do it.

I give up.  I can either give up fancy stream layouts, or I can give up the ability to stream anything better than 480i.  I give up fancy stream layouts. I'm going to straight Kumari.
Hey guys, I got a question for those who use Norichan.

Do any of you see frame skips in the preview window on F1?  I'm wondering if it's normal or just something only I'm experiencing.
Edit history:
DJS: 2013-07-01 05:39:04 am
torch slug since 2006
hard to tell. i wanna say though that my f1 preview window isnt full f1, seems like 50-60 fps, but i might be hallucinating.
its def not as smooth as on my crt.
Edit history:
HDL: 2013-07-01 07:57:36 am
The easiest way to notice is to look at really fast flicker, such as the emeralds on the file select in Sonic 3 & Knuckles or the lasers near the end of Flying Battery.  It doesn't affect local recording of course, but I am curious to know if there's anything one can do to improve it for streams.

For the record, EasyCapViewer does this as well.
wonder if it's a vsync thing. did you say that easycapviewer has tearing also?
Edit history:
HDL: 2013-07-01 12:43:24 pm
HDL: 2013-07-01 12:42:48 pm
HDL: 2013-07-01 12:30:49 pm
HDL: 2013-07-01 12:19:30 pm
Vsync definitely seems like a factor, as I get near perfect flicker in EasyCapViewer with it turned on (no tearing).

However I did a quick test just now and it seems Kumari does have some influence.  Even with vsync on EasyCapViewer exhibits the same behavior:

This also happens if you just run Kumari without streaming.  There are frames skipped without tearing.

Edit: I changed the deinterlacing so that the change in frame rate is more pronounced and easier to see:
well, given how kumari works it's not surprising that frames aren't drawn. the machine is too busy recording the screen to show every frame. are those frames also dropped in the recording from norichan? my guess would be no but that doesn't help the stream quality, haha. ;-[
Stream's getting good reviews since I switched to all Kumari all the time.

I think at this point, with the fact that there's no hardware that supports either QtKit or AVFoundation, Kumari has got to be the *only* way to stream on MacOS right now.
Quote from nate:
are those frames also dropped in the recording from norichan?

Nope.  You saw there were some tiny hiccups in my encoded run (source avi has those too), but I get the feeling that has a separate cause.

I'm curious, how much further work will be put into Kumari?  I know alpha 1 implies there will be updates, but you did say that it's sort of a side thing that currently has no set scope or direction.  Given how much better it handles video quality, frame rate, and CPU over the alternatives, it would be a shame if this is as far as it gets.

I'm also curious as to why it's so good on CPU.  Optimized for multiple cores perhaps?
yeah at some point i will come back around to it and steal stuff people like from obs, basically make it usable under windows and maybe get single window capture under os x. not sure how to answer the cpu question since it's dependent on the video encoding library which is x264 via ffmpeg. using the sliders you can control how much cpu it will use versus the quality. the ticks on the sliders correspond to the x264 encoding presets, i.e. starting from left: ultrafast superfast veryfast faster fast medium slow slower veryslow placebo
Edit history:
DJS: 2013-07-02 12:18:33 pm
torch slug since 2006
x264 is amazing. i always have the x264 slider set to veryfast in whatever i do, even when i encode my movies/tv shows and i cant tell any difference from it comparing to slow, apart from the file size.

and yeah, if kumari got more features/alpha 2, that would be great.  out of everything i tried, kumari is the only program that i have been able to stream from a mac with. i managed to it with FMLE once but only if the only things i had running was norichan and fmle, and the cpu was at 100%. kumari, i can even have my twitch chat open without the cpu fan going louder. it's truly amazing.
Speaking of the slider, I had an occasional pause/stutter issue in my stream when it was set to 2 (1 tick from the left).  I have it on 4 now and the stutter is completely gone.

FMLE is a CPU hog but you should not be getting anything close to 100% usage, even on that Mac Mini you mentioned in page 1 (unless you set a really high resolution/fps).  What does your system monitoring software show?
The one thing I'd like to see in Kumari is the ability to tune it to a max bit rate for Nico.
torch slug since 2006
My settings was 768x432 30fps iirc. I think CamTwist is the main problem.
Just stumbled upon this, anyone have experience with it?  Looks to be the cheapest option so far besides getting a lucky Easycap.
would i piss anyone off if i dropped support for 10.6 in yua?
Edit history:
DJS: 2013-07-23 02:10:18 pm
torch slug since 2006
i personally dont use 10.6, but isnt 10.6 like windows xp, i.e. alot of people still use it?
on the other hand, maybe not alot of speedrunners use it...

does 10.6 make it harder to develop?
10.6.. snow leopard?

Yeah I don't see the point in dragging that version around with you.

It's not like MS Windows where you saw a ton of people stick with XP because it was easier to run an illegal copy of, and a ton more because they didn't like the first pass at the move to a fully multi-user environment.
Edit history:
HDL: 2013-07-27 03:55:56 pm
HDL: 2013-07-27 03:53:33 pm
HDL: 2013-07-27 12:56:51 pm
Quote from nate:
would i piss anyone off if i dropped support for 10.6 in yua?


Quote from DJS:
i personally dont use 10.6, but isnt 10.6 like windows xp, i.e. alot of people still use it?

I've seen all sorts of different statistics about this, so it's probably best to take it with a grain of salt.

In other news, Wine 1.6 is out.  Good riddance X11.

Non ninja edit: I decided to try out that streaming plugin for CamTwist.  At first I had a really hard time getting it to work.  Then I got it to work and my stream only showed a black screen, followed by not getting it to work again.  Apparently the plugin does not play nice with PIP or anything like it (such as image overlays).  It will stream Desktop+ just fine, but not PIP Desktop+, severely limiting what can be done with it.


-Can use with Desktop+ (confine to application window)
-Stream directly from within CT.
-Handles 60 fps like a champ.
-Handles CPU like a champ (mine was around 15%).


-Can't handle PIP or overlays (and probably some other effects)
-Doesn't use x264.
-A bit confusing to use properly at first.
-Turns the video in CT upside down (although it appears correctly on stream).

Unfortunately the guy who made it has not posted in a while, so I'm not sure if he plans to continue developing it.  In any case, the source is available here:

Intruding N313 and F014
Quote from DJS:
does 10.6 make it harder to develop?

Most likely it does.  In the OpenMSX development, the guy who makes the mac port is building it for 10.6 because he doesn't like 10.7 or 10.8, but also he wants to make it more compatible.  He has run into massive difficulties that have caused compile errors, so yes it can be annoying.

I still use 10.6 because I am back to my old 32 bit hardware, which I have finally set up for streaming.

Speaking of the new WINE, I tried the Windows version of Norichan on Ubuntu, but it didn't run, no surprise there.  Even though that computer is the same age, it would be nice as a backup.
sorry, yeah, the reason i was asking about 10.6 is exactly that. as of qt 5.1 there's no official support for 10.6. it's a little crazy because of how good qt support usually is but it seems to be a c++11 thing (no official support for c++11 before 10.7) and qt 5.1 is c++11 happy.

i can still release software for 10.6 but i will have to compile qt myself and it's annoying because i would really prefer qt to have c++11 support. we will see.

yeah, i'm not surprised at all about norichan. i mean what are the odds of the driver working. it's a libusb-win32 driver so it's meant to be a bridge between nt kernelspace and userspace so you can write driver code in userspace. kind of like a port of libusb for windows.
I learned of another option for streaming called CocoaSplit.  I think it's the foundation for the the CT stream plugin, and made by the same guy.  Here's the link:

So far I can't get video from CT to appear properly (awaiting the guy's response on that), but it shows x264 as an option and lets you select Twitch servers.  If this works the way I think it does it might possibly be the best streaming option currently.  More after I test it out.
torch slug since 2006
Think I'm gonna go back and mess around with my Mac a little soon, but I'm not sure how much I can do since l gave my brother my easycap, and I'm left with my dazzle. Afaik only way to get a dazzle to show up on osx is usin that $30 video glide software, which I rather not spend money on... So if anyone knows an other way to use a dazzle dvc100 in osx, let me know.

Sent from my iPhone
Edit history:
presjpolk: 2013-08-05 05:28:43 pm
So what does CocoaSplit do that Kumari or Quicktime Broadcaster don't?

Just noticed it does AVFoundation. Which means once we get hardware that uses that... there we go.
CocoaSplit is like FMLE but better.  It takes advantage of newer technologies (like Syphon which is very CPU efficient) and is compatible with CT 3.0.  If I'm not mistaken, this is the first time you can stream with CT using x264.  I've tested it out and it works with PIP Desktop+.

The only thing I'm having trouble with is finding settings that give me 60 fps.  You have to manually tweak the x264 settings and I don't know enough about this stuff to set everything correctly, I just wind up fiddling with it repeatedly.