Something else to keep in mind is that you NEVER want to go beyond 80% of your Upload Rate. In general terms., for "High" Quality (at least in terms of Streaming)ħ20p60 you're going to want 4.88Mb/s with 2s Key Frames and a Frame Buffer of 2440KB/sġ080p60 you're going to want 8.85Mb/s with 2s Key Frames and a Frame Buffer of 4425KB/s as a point of note this is something the AMD ReLive Software Automatically handles for you., but it does have an issue with Mixer (Microsoft's VC-1 Streaming Solution) as, well it's setup for x/h264 rather than VC-1.Īnd the figures I've provided below are for VC-1 "Smooth Streaming" but will work with x/h264 as well. Instead having a Larger Buffer allows a better utilisation of your Hardware and Prevents Dropped Frames / Streaming Artefacts. so having say a 230KB Buffer, means you're limiting the number of Transcoded Blocks which is great IF you have a Weak CPU / GPU but if that's the case then I'm going to be honest, you SHOULD NOT be Streaming. You can technically get away with 1/16th the Raw Frame Size, but that's only if you're using a "Low Encoding" approach as you'll need that for each block. Now as a note., you ideally want a Frame Buffer that is 50% the size of the Bitrate in Bytes. this as a note is why AMD Ryzen Threadripper is currently the only Desktop CPU capable of Real-Time 8K Encoding., but then for Streaming Purposes for any "Decent" Quality you'd need a really good Internet Upload Speed as you'd be looking at ~30Mb/s for 8K. In said regards for 2K (1080p) you'll need 3 Cores., 4K (2160p) you'll need 6 Cores and 8K (4320p) you'll need 12 Cores. and will result in very little CPU Overhead, while providing "Medium" Quality Encoding (2K for GCN 1.x, 4K for GCN 2.x and 8K for RDNA 1.0).įor High Quality Real-Time you MUST use CPU Encoding. GCN 2.0 or RDNA 1.0 is exceptionally powerful, provided you utilise it via the AMD Media Framework SDK. Still with this said the Media Engine on Radeon Graphics., esp. and OBS is one of those few Applications that will use "Next Available Core / Thread" as opposed to requiring Core/Thread 0., for it's workloads. Where-as with Ryzen 圆00 or better CPUs., this becomes a Non-Issue as you essentially have 2+ Cores entirely unused for said task. and this obviously poses an issue as for each "Level" of CPU Encoding Complexity., you require +1 (Dedicated) Thread(s)., and as such this too can use up to 4 Cores which as you can imagine doesn't leave much for whatever else you're trying to run. This poses an issue when most Games will use up to 4 Cores (6 Threads). Generally speaking., the reason that Software (CPU) Encoding is still listed as (Not Recommended) is because 4 Core / 8 Thread Processors were (and to a degree still are) the most common used by Streamers. This will take ~25% of your CPU for your steam.ĭONT CHANGE: direct=spatial deblock=-3:2 trellis=0 weightp=1 deadzone-intra=4 deadzone-inter=12 aq-mode=3 aq-strength=1.1 // these are near optimal values for like 95% of games outthere Level=3.2 ref=3 bframes=2 b-adapt=0 direct=spatial deblock=-3:2 me=umh merange=32 subme=4 no-mbtree=1 trellis=0 weightp=1 deadzone-intra=4 deadzone-inter=12 aq-mode=3 aq-strength=1.1 rc-lookahead=0 threads=6 lookahead_threads=0 If you REALLY want to have a better result, but also have a higher CPU load you can try this for 720p60 Level=4.2 ref=3 bframes=1 b-adapt=0 direct=spatial deblock=-3:2 me=hex merange=24 subme=3 no-mbtree=1 trellis=0 weightp=1 deadzone-intra=4 deadzone-inter=12 aq-mode=3 aq-strength=1.1 rc-lookahead=0 threads=4 lookahead_threads=0 sliced_threads=0 My "custom x264 options" give me <15% CPU load when streaming 1080p60 Rc_lookahead=50 // HOW SHOULD THIS BE POSSIBLE? Do you use 2pass encoding? in a stream? so your encoder knows what you do next? xD // rc_lookahead=0 Trellis=2 // 1st requires CABAC 2nd is not usefull for streaming // use trellis=0ĭirect=3 // 3? there is only "temporal", "spatial" or "none" // for streaming use: direct=spatial Subme=8 // WHY JUST WHY? you do this when you want to encode a file locally and not for streaming - it takes ALOT of CPU // use 3 or 4 Ref=5 // means your frame can reference up to 5 frames - that costs ALOT of CPU load // better use 2 or 3 CPU Preset: slow (DONT USE THAT) Fast (only with high OC) BEST is "Faster" and "Veryfast" so a smaller custom buffersize on a low bitrate makes alot of sense in quality!Ģ. ALSO have in mind - if you use 44312kbps for 10 frames than the next 10 frames need to be 3288kbps to maintain "CBR" - so after a crisp clear video you will have pixel mash for some frames. so lets say you have bitrate of 3800kbps and a custom buffer of 512kb than your x264/h264 stream can range from 3288-4312kbps. without that your stream can be 2x3800kbps.
0 Comments
Leave a Reply. |