If using linux, we may use ffmpeg to encode to x264 and stream, use source file from rtmpdump directly. That solve issues with play bar poping up and may able use second pc to read chat. Async audio ? need more testing...
Also need testings with Quick Sync, if it capable of encode 720p or 1080p with 60fps without down sometimes fps.
Quick Sync video quality on high bitrates, over 20000 kbps is almost loseless.
I found I had issues with audio syncronization and the server simply killing the connection if the bitrate was too high. You could just set the bitrate for something like 100,000 if the server could handle it and be done with it.
I heard from the quicksync development thread that quicksync has issues running at 60fps, I don't know how true this is now as I can't test it anymore. Something to look into. Any FPS higher then 30 actually.
My experience of using OBS + Quick Sync on i5-3450, local record, high bitrate, is told me 1280x1024 60fps can't be record without visualy drop fps sometimes. Maybe with HD4000 or HD4600 not that problem.
Yup, that's the point of LAN encoding... If only it were easier to implement and there weren't some flaky parts to it (like audio syncronization problems).
What exactly is that setting supposed to change and what part of the program does it interface with? Encoder? OBS? Guessing that's specific to the quick sync implementation in OBS and trades off quality for speed (but since the bit rate is so high it doesn't matter).
I don't get async audio issues yet. That setting for Quick Sync give you extra fps on capture video and quality on high bitrate same. In hd4600 Quick Sync is better quality encode, have more options of quality. I don't may test this because don't have it.
I guess if now hd4600 Quick Sync not able to capture 1080p 60fps with MFX_TARGETUSAGE_BEST_SPEED setting, then next iteration(next "generation" intel processors) of Quick Sync be able to do this without problem.
Only thing is more delay video compare to capture card.
Hmmm... seems you're having more success then I was using AMS. Mind making some test vods at different bit rates and fps?
Another problem with capturing from VLC is you get tearing or video sync issues occasionally on the stream where frames will skip or stutter.
Just to clarify, you can do what Ivan is talking about without a Intel processor capable of Intel Quick Sync. You just set the encoder in OBS to Ultrafast. It still uses resources, but it uses about 1/2 to 1/3 as much as running the encoder at Veryfast. It's extremely lightweight in comparison and then you just do all the other steps he's talking about. It's almost lossless operating at ultrafast at 10k, but I'd up it to 30k just to be sure (I could only get it working at 10k due to AMS freaking out with high bit rates).
There is the whole video delay thing, but that doesn't really matter. Streaming isn't completely real time anyway. Viewers wont know unless you get like 30-60+ seconds of delay.
Another crazy idia, somehow capture frames rgb24 format and convert to yv12 format, make video from this frames and stream to lan computer.
This operation must be even less cpu usage then x264 ultrafast.
For 720p60fps need 79 megabytes per second(1000mbit network card is cheap)
For 1080p60fps need 177 megabytes per second, one adapter not enough. Maybe use two adapters, send even frames to first adapter, send uneven frames to second then show it in right order.
It's just crazy idia and sure have many problems to make it work properly.
Quick Sync compare to capture cards have 12bit color space vs 24bit (i guesse) for capture cards.
Don't know if it make any difference, x264 in most cases also have 12bit color space ?
I'm not sure why you'd want to stream raw data across the network. You run into the issues other people were mentioning when I first brought this up which is the data usage. IP does have overhead, so that's also something to consider.
Extremely high bitrates with a little bit of compression is so close to lossless it doesn't seem to matter for streaming. Although ideally it would be nice if it were lossless. Even using a adapter to capture a second signal over HDMI isn't lossless when it converts back and some adapters have quality issues.
How good a capture card is totally depends on how much money you want to dump on one. A lan solution could technically be completely lossless as it is raw bits, without the added cost.
I've personally been a supporter of this for some time because it allows me to reposition not only the workload (encoding), but also the heat and noise of the second computer in a different room. Not just that, but you also can control scenes and what not on the primary computer, where as with a capture PC you have to do scene work on the capture PC. That's another one of the big downsides to using a capture PC I wasn't very fond of. When you go ethernet the possibilities are practically endless.
This is promising though, hopefully Jim will eventually get a inkling to poke around in this area sometime soon. I mean this pretty much obsoletes capture cards as a whole (which means less time would need to be spent supporting them and there are a lot of them).