Question / Help 1080p60 @ 6k bitrate possible w/ placebo?
- Thread starter awolive
- Start date
BK-Morpheus
Active Member
maybe you can simulate it by using some kind of workflow like this:
- record 1080p60 with extreme bitrate and NVENC
- encode that video with Handbrake and use settings that are equal to OBS x264 placebo and write down avg encoding fps
- repeat encoding with less cores and write down avg encoding fps
- repeat encoding with less clock-speed and write down avg encoding fps
Now you will have data that can be used to simulate/predict the core count/clockspeed that is needed to encode with a little more than 60fps avg (you would need the minimum encoding speed to be 60fps).
When you check the performance hit when changing from very fast to slow and you check again when going from slow to slower preset, you'll see, that the CPU load increases pretty extreme (maybe exponential) while the quality improvement is mediocre.
- record 1080p60 with extreme bitrate and NVENC
- encode that video with Handbrake and use settings that are equal to OBS x264 placebo and write down avg encoding fps
- repeat encoding with less cores and write down avg encoding fps
- repeat encoding with less clock-speed and write down avg encoding fps
Now you will have data that can be used to simulate/predict the core count/clockspeed that is needed to encode with a little more than 60fps avg (you would need the minimum encoding speed to be 60fps).
When you check the performance hit when changing from very fast to slow and you check again when going from slow to slower preset, you'll see, that the CPU load increases pretty extreme (maybe exponential) while the quality improvement is mediocre.
Boildown
Active Member
So supposedly x264 can only utilize around 1 thread per 40 (-ish) lines of vertical video. So dividing 1080 by 40 equals 27; you'd want to have around 27 threads. x264 also opens 1.5 threads per logical CPU core. So if you do that math you want a CPU with ~ 18 cores, as 18 x 1.5 = 27. Hyperthreading complicates this, maybe you can turn hyperthreading off and use a true 18 core CPU. But 18 core CPUs have to run at a low clockspeed, so maybe its better to get a 9-core CPU and have hyperthreading turned on (for 18 logical cores), because a 9 core CPU will have a higher clockspeed than an 18 core CPU. The truth is probably somewhere in-between.
Anyways, you'd want this CPU and you'd want it to run at a higher clockspeed than has ever been achieved before. Placebo is many times harder than Slow, for example. Maybe an order of magnitude or so. So if I were to guess, I'd say you'd want a 10 to 14 core CPU with IPC similar to what we have now running at 10-20 GHz to even think about it.
Obviously, Intel and AMD have shown no signs at all of being able to achieve this.
Anyways, you'd want this CPU and you'd want it to run at a higher clockspeed than has ever been achieved before. Placebo is many times harder than Slow, for example. Maybe an order of magnitude or so. So if I were to guess, I'd say you'd want a 10 to 14 core CPU with IPC similar to what we have now running at 10-20 GHz to even think about it.
Obviously, Intel and AMD have shown no signs at all of being able to achieve this.
BK-Morpheus
Active Member
As the whole thing is more of a speculative nature:
If I would have so much CPU power, I would rather stream 720p60fps medium and record 1080p60fps medium at the same time, instead of streaming 1080p60 placebo ;-)
If I would have so much CPU power, I would rather stream 720p60fps medium and record 1080p60fps medium at the same time, instead of streaming 1080p60 placebo ;-)
Placebo is not good for streaming (or at all?), mobile plattforms won't play it in Hardware and even browsers don't handle it that good. Also it doesn't improve the quality much http://www.videoquality.pl/preset-settings-x264-quality-compression-speed-test/
Very slow works fine for streaming, from my tests
Very slow works fine for streaming, from my tests
The only problem is too many reference frames and level limit.
Placebo is ok if you don't get encoder overload. (will get overloaded on most CPU)
But for 1280x720 30fps, level 3.1, use custom x264 option: level=3.1 ref=5
Encode (stream or record using "use stream encoder") and read OBS logs for any lines of level limit exceeded. It will show up if there is too many reference frames or the resolution and frame rate too big for level.
DPB size (16 frames, 57600 mbs) > level limit (5 frames, 18000 mbs) ... this means x264 will still flag this as level 3.1 with too many reference frames that might black screen or slow down older mobile devices. Placebo is 16 reference frames if 'ref=' not used.
There is level recommendations on both twitch and wikipedia.
https://stream.twitch.tv/encoding/
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
This does not affect compatibility of YouTube as YouTube always transcode / re-encode to multiple resolutions.
Yes it may help, limiting level and reference frames is mainly to help with mobile device's hardware decoder that have limited decoder speed and limited memory (mostly super fast cache memory limited in size).
Well it is ok because you convert your placebo preset to slow.[/QUOTE]
Boildown
Active Member
Well, not really. Here's a handy reference that shows what changes between each preset: http://dev.beandog.org/x264_preset_reference.html
Even if you did do Placebo with ref=3 or 5 or something smaller instead of 16, the CPU load would still be high because of all the other things. Also, some of the settings (and I'm not sure how much this applies to ref) are best done together. I've experimented with the settings between Medium, Slow, and Slower, making various "hybrid presets", and some of them just look like garbage unless another setting that changed between the two presets is set too.
what you create there is the quality of slow with computing complexity of placebo.
Reference frames (ref) isn't the only thing that affects quality or size. Try ref=16 with UltraFast and you will see bad quality at the same bitrate.
A lot of encoder settings will affect quality and encoder speed, but makes almost no difference on decoder's speed (me, subme, merange, rc-lookahead, scenecut, threads, asm=AVX2, a lot of stuff). But, ref does affect level compatibility, decoder memory usage, and might affect some decoder's speed.
ultrafast is bullshit and you should know that, try it with veryfast
BornDownUnder
Member
I believe sam made the comparison due to Ultrafast being very basic for quality:compression ratio, with the knowledge of reference frames doing bugger all by themselves...
that way around it doesn't work, but creating shortcuts to make it worse is easy