nice!I like Justin.tv, they're my colo neighbor. This just makes their coolness++
Undoubtably this is because of the low light, but if you bumped up the noise reduction a touch and turned on deinterlacing you'd probably get an even better encode (depending on your available CPU).
Yesterday I had both input size and output size set to 480x360, and with that input size, the de-interlace checkbox is grayed out (I guess it assumes the DV device is doing the de-interlacing when it scales in hardware?) I just changed it to have input 640x480, deinterlacing on; output size 480x360. I guess it looks a little less grainy? It's hard to tell. Presumably it's using more CPU now.
There doesn't seem to be a setting for noise reduction.
You'll notice the deinterlacing most when there's motion on the stream-- like you said, hard to tell right now, but take for example someone walking down the sidewalk outside, the motion is crisper, and no telltale jagged-line-action from the interlacing.
That's too bad about the noise reduction; that's the number one issue with encode quality most of the time. Instead of the encoder having to pump out 200kbps of pixels that only change because of noise in the video, you could get much higher quality on the parts of the signal that are actually changing.
It sure doesn't seem like it's getting 15fps. Feels more like 8.
It does seem to be stuttering at times, but that could be any number of things. Do vmstat or iostat look like they're out of control? Is the connection saturated? Are you setting the packets coming from the encoder as high priority (and does your router behave with high priority packets)? Are the justin.tv servers just hiccuping? Short of doing entirely too much low-level debugging, it'd be hard to nail down one cause of frame drops.
Blah, I only barely remember how to begin finding answers to those questions. It's been ages since I had to think about my pf.conf rules. Fuck it.