This article is the second in a series about benchmarking hardware encoding performance. In the first article available, I delineated a procedure for testing hardware encoders. Specifically, I recommended this three-step procedure:

1. Identify the most critical quality and throughput-related options for the encoder.
2. Test across a range of configurations from high quality/low throughput to low quality/high throughput to identify the operating point that delivers the optimum blend of quality and throughput for your application.
3. Compute quality, cost per stream, and watts per stream at the operating point to compare against other technologies.

After laying out this procedure, I applied it to the NETINT Quadra Video Processing Unit (VPU) to find the optimum operating point and the associated quality, cost per stream, and watts per stream. In this article, we perform the same analysis on the NVIDIA T4 GPU-based encoder.
About The NVIDIA T4
The NVIDIA T4 is powered by NVIDIA Turing Tensor Cores and draws 70 watts in operation. Pricing varies by the reseller, with $2,299 around the median price, which puts it slightly higher than the $1,500 quoted for the NETINT Quadra T1 VPU in the previous article.
In creating the command line for the NVIDIA encodes, I checked multiple NVIDIA documents, including a document entitled Video Benchmark Assumptions, this blog post entitled Turing H.264 Video Encoding Speed and Quality, and a document entitled Using FFmpeg with NVIDIA GPU Hardware Acceleration that requires a login. I readily admit that I am not an expert on NVIDIA encoding, but the point of this exercise is not absolute quality as much as the range of quality and throughput that all hardware enables. You should check these documents yourself and create your own version of the optimized command string.
While there are many configuration options that impact quality and throughput, we focused our attention on two, lookahead and presets. As discussed in the previous article, the lookahead buffer allows the encoder to look at frames ahead of the frame being encoded, so it knows what is coming and can make more intelligent decisions. This improves encoding quality, particularly at and around scene changes, and it can improve bitrate efficiency. But lookahead adds latency equal to the lookahead duration, and it can decrease throughput.
Note that while the NVIDIA documentation recommends a look-ahead buffer of twenty frames, I use 15 in my tests because, at 20, the hardware decoder kept crashing. I tested a 20-frame lookahead using software decoding, and the quality differential between 15 and 20 was inconsequential, so this shouldn’t impact the comparative results.
I also tested using various NVIDIA presets, which, like all encoding presets, trade-off quality vs. throughput. To measure quality, I computed the VMAF harmonic mean and low-frame scores, the latter a measure of transient quality. For throughput, I tested the number of simultaneous 1080p30 files the hardware could process at 30 fps. I divided the stream count into price and watts/hour to determine cost/stream and watts/stream.
As you can see in Table 1, I tested with a lookahead value of 15 for selected presets 1-9, and then with a 0 lookahead for preset 9. Line two shows the closest x264 equivalent score for perspective.
In terms of operating point for comparing to Quadra, I choose the lookahead 15/preset 4 configurations, which yielded twice the throughput of preset 2 with only a minor reduction in VMAF Harmonic mean. We will consider low-frame scores in the final comparisons.
In general, the presets worked as they should, with higher quality and lower throughput at the left end, and the reverse at the right end, though LA15/P4 performance was an anomaly since it produced lower quality and higher throughput than LA15/P6. In addition, dropping the lookahead buffer did not produce the performance increase that we saw with Quadra, though it also did not produce a significant quality decrease.
​
TABLE 1. H.264 OPTIONS AND RESULTS.
Table 2 shows the T4’s HEVC results. Though quality was again near the medium x265 preset with several combinations, throughput was very modest at 3 or 4 streams at that quality level. For HEVC, LA15/P4 stands out as the optimal configuration, with four times or better throughput than other combinations with higher-quality output.
In terms of expected preset behavior, LA15/P4 was again quite the anomaly, producing the highest throughput in the test suite with slightly lower quality than LA15/P6, which should deliver lower quality. Again, switching from LA 15 to LA 0 produced neither the expected spike in throughput nor a drop in quality, as we saw with the Quadra for both HEVC and H.264.
​
TABLE 2. HEVC OPTIONS AND RESULTS.
Quadra vs. T4
Now that we have identified the operating points for Quadra and the T4, let us compare quality, throughput, CAPEX, and OPEX. You see the data for H.264 in Table 3.
Here, the stream count was the same, so Quadra’s advantage in cost per stream and watts per stream related to its lower cost and more efficient operation. At their respective operating points, the Quadra’s VMAF harmonic mean quality was slightly higher, with a more significant advantage in the low-frame score, a predictor of transient quality problems.
​
TABLE 3. COMPARING QUADRA AND T4 AT H.264 OPERATING POINTS.
Table 4 shows the same comparison for HEVC. Here, Quadra output 75% more streams than the T4, which increases the cost per stream and watts per stream advantages. VMAF harmonic means scores were again very similar, though the T4’s low frame score was substantially lower.
​
TABLE 4. COMPARING QUADRA AND T4 AT HEVC OPERATING POINTS.
Figure 5 illustrates the low-frames and low-frame differential between the two files. It is the result plot from the Moscow State University Video Quality Measurement Tool (VQMT), which displays the VMAF score, frame-by-frame, over the entire duration of the two video files analyzed, with Quadra in red and the T4 in green. The top window shows the VMAF comparison for the entire two files, while the bottom window is a close-up of the highlighted region of the top window, right around the most significant downward spike at frame 1590.
​
FIGURE 5. THE DOWNWARD GREEN SPIKES REPRESENT THE LOW-FRAME SCORES IN THE T4 ENCODE.
As you can see in the bottom window in Figure 5, the low-frame region extends for 2-3 frames, which might be borderline noticeable by a discerning viewer. Figure 6 shows a close-up of the lowest quality frame, Quadra on the left, T4 on the right, and the dramatic difference in VMAF score, 87.95 to 57, is certainly warranted. Not surprisingly, PSNR and SSIM measurements confirmed these low frames.
​
FIGURE 6. QUALITY COMPARISONS, NETINT QUADRA ON THE LEFT, T4 ON THE RIGHT.
It is useful to track low frames because if they extend beyond 2-3 frames, they become noticeable to viewers and can degrade viewer's quality of experience. Mathematically, in a two-minute test file, the impact of even 10 – 15 terrible frames on the overall score is negligible. That is why it is always useful to visualize the metric scores with a tool like VQMT rather than simply relying on a single score.
Summing Up
Overall, you should consider the procedure discussed in this and the previous article as the most important takeaway from these two articles. I am not an expert in encoding with NVIDIA hardware, and the results from a single or even a limited number of files can be idiosyncratic.
Do your own research, test your own files, and draw your own conclusions. As stated in the previous article, do not be impressed by quality scores without knowing the throughput, and expect that impressive throughput numbers may be accompanied by a significant drop in quality.
Whenever you test any hardware encoder, identify the most important quality/throughput configuration options, test over the relevant range, and choose the operating point that delivers the best combination of quality and throughput. This will give the best chance to achieve a meaningful apple vs. apples comparison between different hardware encoders that incorporates quality, cost per stream, and watts per stream.
Discover more here: https://netint.com/resources/blog/
#NETINT #ASIC #Encoding #LiveStreaming

Both were considered SL

I did a couple asura short guides, but this will be the last (at least for a looong time), and more extensive one.
https://preview.redd.it/lvtw88fuk23b1.png?width=1079&format=png&auto=webp&s=7d04d76bc6d43f4df81adf9f1a505b702c6ccddd
I will try to cover close to everything related to Asura, and go over two builds, one that has frantic and stressful (but fun) gameplay, and another one for those who just want a more "chill" way of playing. Note that yellow is about 20 to 30% more performant than blue.

THE BASICS

Before we begin, a quick run about some important concepts.
- Skill cancel: Dodging at the right time, makes it so skills and attacks are still effective, while cutting short the animation. This is not only true for Asura, but for her is specially effective. For her 3rd skill, it can be cut almost instantly, 2nd skill as well, and 1st skill as soon as you see the arms appear you can dodge. For the hold attack, as soon as she makes contact with the ground it can also be canceled. For the skills look at when flamefetter state starts, and you can cancel immediately.
https://reddit.com/link/13w1ugi/video/g1sthvyxk23b1/player
Another tip, is to always dodge laterally, never back as dodging away from the enemy takes more time. When playing just aim to do 2 holds, once you get comfortable aim for 3
- Flamefetter state: It's activated upon the use of any skill. For default lasts for 4 seconds and meanwhile it provides extra 20% fire damage. Asura's whole kit and gameplay should revolve around this. Since Flamefetter is a long name, I'll just say FF from now on.
- Do bursts of damage when FF is up if possible: hold attacks, skills and ultimate (yours).
- Functor key: For Asura it's quite important to get if you plan on playing her long-term. It changes the gameplay style and adds a ton of damage.
- When in groups or multiple bosses, use the "target" button to focus on one objective, this way the hold attack fire resistance shred's value will be more consistent.

SIGILS, TEAM AND BOTS

SIGILS:
https://preview.redd.it/bbvtc9l3l23b1.png?width=691&format=png&auto=webp&s=2c32ed71de668f2e1aedab9cf0d568614ba0e915
Use the recommended ones, that provide fire damage and energy regeneration. Prometeus flame and Jörmingandr
For the enchant effects, focus on "Fire blessing -> Fire damage %, and "Gladiator" -> Normal atk damage % (because hold attacks count as normal). Other effects like crit rate is quite good, and others like -energy cost, index mod multiplier, damage against XYZ enemies are fine too. But focus on the two mentioned plus/or crit (low priority).
This are my enchantments. Are WAY away from being perfect (on the way on being so one day). You can see the mentioned effects tho:
https://reddit.com/link/13w1ugi/video/qkvrzlh6l23b1/player
TEAM:
We don't have units that synergize too well with Asura right now, or more specifically good established fire teams. When asked vets on discord, I've been answered, and seen replied to other players that using S Poseidon and Tsukuyomi is the way to go, just for the raw dps (and poseidon's CC).
https://preview.redd.it/kllgv0jdl23b1.png?width=1077&format=png&auto=webp&s=5fce55eeace942bdef857a4f3f36e80f1d1f6131
BOTS:
The most recommended bot is Me-Yow, providing extra energy when doing perfect dodges. Works well with both builds, but specially recommended for the yellow build.
https://preview.redd.it/6itxcaall23b1.png?width=1920&format=png&auto=webp&s=ab9f380e18f100f15e5ff8b5c74053495ba3f52e
When playing with the blue build, depending how you go about it, energy may overflow (be capped). Then other bots like Mitir, to extend modified mode for 3 seconds or Minininja to increase teammates crit rate are also good options.
https://preview.redd.it/uwx8bjfnl23b1.png?width=1304&format=png&auto=webp&s=48c19b389deca830c6cc5a812b2b22f13dad022a
As for the chips, do whatever you feel more comfortable with tbh. I'm using "Tactical Assembly" to have my companions near to focus better targets and make better use of team's CC. And "Countermeasure" to extend poseidon's freeze for 1 sec. Comfortable ones.
"Battlefield Dominance" and "Marginal Benefit" are also very good if you prefer raw dps rather than usability.

YELLOW HOLD SPAM BUILD

https://reddit.com/link/13w1ugi/video/ira3ohjhn23b1/player
The objective of the build:

1. Abuse hold attack as much as possible
2. Abuse skill cancels for skills and attacks
3. Don't use hold attack if FF is not activated

How does the build work?

• With the third yellow code, when doing a hold attack, half of remaining energy is consumed to do more damage.
• With jörmungandr sigils, each time energy is used, there is a chance at recovering 35% of energy.
• With functor key, first hold after entering FF restores 12 energy and deals extra dmg. Each hold attack in FF reduces enemy fire resistance.

Tips:

• Practice a bit the skill cancels. At first go for 2 holds per FF, after some time go for 3.
• If when playing, if you try to do a 3rd hold, and you're seeing that it won't connect the hit inside FF, dodge cancel, to save up energy.

The gameplay for this build, if played this way is super effective, but also super frantic. If you don't want to bother about constant holds and constant animation cancels, go for the blue build.
Shoutout to XLyrcX for explaining to me the hold attack-dodge cancel.

BLUE EXTENDED FLAMEFETTER

https://reddit.com/link/13w1ugi/video/00q6zavoo23b1/player
Objective of the build:

1. Overlap all the skills possible
2. Use 3 skills at once, extend three times, rinse and repeat.
3. Bursts and ultimate after casting 3 skills.

How does the build work?

• With the blue codes, we get 45% extra fire damage during FF instead of 20%.
  • The duration of FF is extended by 4 seconds, based on remaining time (so if there were 2 seconds of FF left, the new one will last 6 seconds).
    • The extra fire damage bonus will stack, based on each skill duration (so hypotetically, if all 3 skills were casted simultaneously, the FF would provide 135% extra fire damage lasting 12 seconds).

Tips:

• Hold & Spam as in the yellow build is still the most effective way to go BUT not for a wide margin. From my testing, playing "normally" vs Hold&Spam is about 16% less effective (making more use of functor's "punch to accumulate hold damage"). So you can play more "normally" and calmly with this build and still perform well.
• For the three skills cooldowns to be consistent, do all 3 at the same time with cancels, preferably starting with skill 1. Then extend three times with skills 1 & 3 & 1, and after that all three skills will be off cooldown to be cast at the same time again.
• At the beginning of the match, wait a bit to gather energy before using the skills.

---------------------------------------------
If you think this was helpful, please comment about it! If there is anything to add/fix/change about Asura and this guide, please do say so and I'll edit it and u/you!
I hope you have a blast playing Aether Gazer, but you'll for sure have it if playing Asura! Enjoy! :D

TL;DR: Script at the bottom, above the pictures!
For a while I have tried to figure out how to use kOS to optimize deploy angle for propeller and ducted fan blades for max thrust. I have failed google a solution. There can be several reasons for this:

1. I suck at googling
2. No-one else has this problem/desire
3. The solution is so obvious, that no-one thought it worth asking or sharing.
4. No-one came up with a solution they thought worth sharing yet.

In the strange case it might be 4., I'd like to share what I came up with.
First of all I noticed that the PAW (Part Action Window) for a prop/blade contains a "lift" field, if you turn it on in alt-F12 debug window under Physics->Aero->Display Aero Data in Action Menus.
This value can be read by kOS, even if the PAW is closed.
I usually use counter-rotating props/fans to avoid spin. I use a KAL-1000 controller to adjust the blade deployment angle. Instead of having the same curve for both props in the counter-rotating setup, I adjusted one of them to have 0.1 to 0.5 degrees higher angle than the other on the entire curve. kOS can control the KAL by setting the "play position" field, but it only seems to work reliably when the PAW for the KAL is open.
In a kOS script, I loop over the blades for each propeller, and read the lift value. If the one with higher pitch angle has more lift, I increase the angle for both, and decrease it if the one with lower angle has more lift.
My initial use has been for a lifting stage for an Eve return ship I'm building. Therefore my tests have been with a vertical setup. As far as I can tell, I don't get much higher in the atmosphere than with manual control, since the deciding factor seems to be when the air gets too thin. However, I do get there a lot faster than I could so far with manual control with the KAL locked to throttle.
I believe it should work at least as well for prop-planes, but have yet to try it out myself (instead I'm typing this post, like a chump).
I didn't do a lot of optimizations (and when I do, it will be in a more structured form, which depend on other files). The prototype uses enum_lib.ks from KSLib to sort collections, but no other dependencies. One of the obvious optimizations is how often the adjustments should be made and how big they should be. I recommend adjusting the time on the KAL-1000 sequence to be one second per degree, so you can follow the angle easily.
It might also be possible to skip the KAL entirely, or you can link it to main throttle and adjust the throttle through kOS if you want it more indirect.
Without further ado, here is the example script I came up with:

local ADJUSTMENT_AMOUNT is 0.5. local ADJUSTMENT_DELAY is 0.05. local curline is 0. function nextLine{ local nextLineNumber is curline. set curline to curline +1. return nextLineNumber. } function resetLines { set curline to 0. } clearScreen. until false { resetLines(). print "Testing blade lift...." at (0,nextLine()). local rotorMap is buildRotorMap(). for rotor in ship:partsnamedpattern("Rotor"){ local valueMap is rotorMap[rotor:uid]. local rotorName is choose rotor:tag if rotor:tag <> "" else rotor:uid. print "Rotor " + rotorName + " Avg. lift: " + round(valueMap:avgLift, 2) + " Avg. angle: " + round(valueMap:avgAngle, 2) at (0, nextLine()). for blade in rotor:partsnamedpattern("Blade"){ local module is blade:getmodule("ModuleControlSurface"). if module:hasfield("lift"){ local lift is round(module:getfield("lift"), 2). print "blade uid " + blade:uid + ": " + lift at (0, nextLine()). } else { print "No lift info available" at (0, nextLine()). } } } optimizeLift(). wait ADJUSTMENT_DELAY. } function optimizeLift { local rotorMap is buildRotorMap(). local sorted is Enum:sort(rotorMap:values, {parameter a, b. return a:avgLift - b:avgLift.}). local worst is sorted[0]. local best is sorted[sorted:length -1]. if (best:avgAngle > worst:avgAngle){ print "increasing blade angle" at (0, nextLine()). adjustBladeAngle(ADJUSTMENT_AMOUNT). } else { print "decreasing blade angle" at (0, nextLine()). adjustBladeAngle(-ADJUSTMENT_AMOUNT). } } function adjustBladeAngle{ parameter amount. local controlModule is getBladeAngleController():getModule("ModuleRoboticController"). local current is controlModule:getField("play position"). controlModule:setField("play position", current + amount). } function getBladeAngleController { return ship:partsnamedpattern("controller1000")[0]. } function buildRotorMap { local rotorMap is lexicon(). for rotor in ship:partsnamedpattern("Rotor"){ local blades is rotor:partsnamedpattern("Blade"). local avgLift is Enum:reduce(blades, 0, {parameter sum, blade. return sum + blade:getmodule("ModuleControlSurface"):getfield("lift").} )/ blades:length. local avgAngle is Enum:reduce(blades, 0, {parameter sum, blade. return sum + blade:getmodule("ModuleControlSurface"):getfield("deploy angle").} )/ blades:length. rotorMap:add(rotor:uid, lexicon("avgLift", avgLift, "avgAngle", avgAngle)). } return rotorMap. } 

​
My test rig
The setting to enable Lift info in PAW
​
The rig during a test
I hope it is useful to someone out there. If you have suggestions on how to improve it, or have come up with a different solution I'd love to her it. Peace out.