Regarding the not-NAN float type, there was actually a proposal for it which was shot down: https://github.com/rust-lang/libs-team/issues/238.

I don't remember every argument in there but it seemed that there are good reasons not to add it unlike a NonZero integer type which seems to have no real downsides.

I'm sorry, but even if this exact example does not appear, this case is technically specified by the reference.

The page on identifiers (https://doc.rust-lang.org/reference/identifiers.html) calls out that a "single underscore character is not an identifier". If you then follow the trail (Search for "Underscore"), you will find that it is instead a wildcard pattern (https://doc.rust-lang.org/reference/patterns.html#wildcard-p...). It says that "[u]nlike identifier patterns, it [the wildcard pattern] does not copy, move or borrow the value it matches."

From this, it follows that the right-hand side ("value expression", roughly equal to an rvalue) is not moved into a place called _, but is effectively just a value matched against a wildcard pattern. This does nothing (the value is not moved into any other place), so it gets dropped.

Yes, a YouTuber named EposVox released a video on AV1 hardware encoding when the first Intel dGPUs with support for it released: https://www.youtube.com/watch?v=ctbTTRoqZsM

Later on in the video, there are some graphs comparing Intel's AV1 encoder to SVT-AV1 at different speed presets. Even one of the faster presets (9) will comfortably stay above AV1 quality according to VMAF, and if you don't need real-time speeds you can lower the preset to get further ahead of the hardware encoder. (BTW: That video is >1 year old now, and SVT-AV1 had some significant updates in the meantime too. So the software side is probably looking better now.)

There's a feature that allows you to try and target a specific VMAF score, but it doesn't work very well. What av1an does do for you is increase the speed by a lot, especially for aomenc and rav1e, which don't scale well with high thread counts. SVT-AV1 doesn't really have this problem.

A faster encode might allow using a slower speed/preset setting, which would increase quality per bitrate a little bit. But I don't really consider av1an a tool that increases encode quality, to be honest.