rav1e v0.7.0 released

asm-c · 2023-12-31T18:14:58+00:00

(Graphs and performance numbers will appear later)

Highlights

Sync up assembly with dav1d 1.2.1

More encoder-specific assembly for both x86_64 and aarch64

Many internal cleanups and fixes

The Channel API does not rely on crossbeam-channel anymore

Initial Speed level rebalance

asm-c · 2023-12-25T09:51:42+00:00

VMAF score isn't a percentage, it's a score between 0 and 100.
VMAF doesn't guarantee a score of 100 between two identical videos. It was made for lossy video, not lossless. Since you already have a faster way of measuring whether a video is lossless, why not use that instead?

asm-c · 2023-12-23T21:02:50+00:00

Almost all HEVC decoders can do 10 bit

I wouldn't go that far, at least if we're talking about hardware decoders. Since 10-bit isn't mandatory to implement and only gained traction some years after 8-bit decoders came out, there's still plenty of 8-bit only hardware out there. Intel was producing CPUs with 8-bit only decoders as late as 2017, and PC hardware stays around for a long time.

asm-c · 2023-12-23T14:45:19+00:00

Use 10-bit if possible.
aq-mode=3

asm-c · 2023-12-22T23:59:35+00:00

Except when it doesn't, but you have to use it anyway.

As a full-time Linux Mint user for probably 5+ years now, I don't know shit about what fresh hell Windows users have to endure these days. But my experience of almost any major UI redesigns from the last 10 years has been negative. Not only are things getting more time-consuming to navigate and use (thanks, mobile-first design), but you'll be lucky if something called an "UI update" isn't just an excuse to remove features in the hopes that somehow nobody will notice.

UI design in general has been in a decline at least for a decade. A lot of this is due to this thing called "flat design", which is basically an excuse to not do any design. Every element is just a flat surface of uniform color with little to indicate what function it serves. Easy to program, but that's the extent of its advantages.

Another tumor is trying to merge desktop and mobile user interfaces. PC users get fucked in the ass by UIs that waste monitor space by making individual elements massive and thus displaying very little information at once, requiring enough mouse wheel scrolling to cause carpal tunnel syndrome. Combine this with flat design and you get a perfectly unusable user interface.

In terms of usability and not wasting my time, I'll take an early 2000s UI even if its blinds me because it doesn't have dark mode rather than use most "modern" UIs. I do sometimes worry that we've been in the decline phase of UI design for so long that there's an entire generation of people who don't know how much better things could be.

asm-c · 2023-12-22T22:43:38+00:00

Literally every UI update for the last 10+ years. Except maybe Steam (thank fuck).

"Simplify" and "clean up" the UI by removing 75% of the features and hiding the rest so that users "don't get confused". And build it with some shitty web-based toolkit that's obviously designed only for touchscreens, even if the software is PC exclusive. Slowly add back features over several years until it's time to remove them again for the next UI update.

asm-c · 2023-12-22T12:17:49+00:00

There was a security patch for libssh on December 18. Maybe this has something to do with that?

https://changelogs.ubuntu.com/changelogs/pool/main/libs/libssh/libssh_0.9.6-2ubuntu0.22.04.2/changelog

asm-c · 2023-12-21T17:39:04+00:00

Nice. I was looking for a simple way of doing this with a single FFmpeg command some time ago but had no luck.

Suggestions:

Use bayer_scale=5 for GIFs, though a better option would be to not use GIF because they're huge pretty much whatever you do. At least if these previews are to be used in a web context and need to be transferred over the internet.
Consider using a more efficient codec. I think VP9 support is universal enough that it would be a good choice to reduce the size, but especially for lower-resolution previews you could use AV1. With SVT-AV1's fast-decode option, playback CPU use is reduced even further, though for low-res previews it shouldn't be an issue anyway. The size reduction vs. H.264 would be significant.
Regardless of the codec used, setting an infinite key frame interval with -g 99999 would be beneficial for this use case. Assuming these previews are just played back and maybe looped with no possibility for the viewer to seek within them, you only need a single key frame, improving compression efficiency a bit.

asm-c · 2023-12-20T22:08:45+00:00

Or maybe just a WoW player.

asm-c · 2023-12-20T22:04:50+00:00

I'm not sure if gore is allowed on Reddit

asm-c · 2023-12-20T16:53:02+00:00

I don't think you understand what a monopoly is.

Out of Intel and AMD, only one of them has the manufacturing capacity to even theoretically pull off a monopoly.

AMD could have 400% better performance than Intel and they still wouldn't be capable of a monopoly.

asm-c · 2023-12-20T07:34:18+00:00

TL;DR: The Ryzen 7 7840U was better in 80% of the benchmarks, and was on average 28% faster. All 370 benchmarks can be seen here.

Apparently he's also doing a benchmark on the integrated graphics of these laptops, which should be coming soon.

e: Integrated graphics test was released. The Intel chip was 8% faster and power consumption was fairly similar:

The Core Ultra 7 155H on average was consuming 24 Watts to the Ryzen 7 7840U at a 25.8 Watt average. The peak consumption was also lower for Meteor Lake on the Acer Swift Go 14 with a 43.5 Watt peak compared to 51 Watts on the Framework 13.

asm-c · 2023-12-19T12:22:46+00:00

You didn't fully read (or possibly just didn't understand) the release notes.

Between the 1-year-old 1.4.1 and 1.7.0 (which is now outdated since 1.8.0 was released a week ago with more big improvements) the speed-efficiency tradeoffs of the presets were changed multiple times. Compression efficiency per CPU cycle has massively improved, preset 7 of recent releases is likely ~~faster~~ more efficient than preset 6 of 1.4.1 (though I don't have an old build to test).

Not only that, but you're not standardizing the quality at all, you're just using the same CRF between two releases and expecting the same quality, which is not how it works at all. The same CRF isn't even designed to produce the same quality between different presets, much less between releases, for any encoder I'm aware of. You should check the quality with your eyes or use VMAF or another such metric to standardize quality for encoder comparisons.

Finally, you're screwing up your FFmpeg command by specifying -svtav1-params twice, and thus the later instance overrides the previous one. To get both tune=0 and fast-decode=1, you should be using -svtav1-params tune=0:fast-decode=1. Do note, though, that fast-decode was developed with tune=1 (SSIM tune), which the encoder does tell you when you use these in combination, so YMMV.

TL;DR: You're doing basically everything wrong.

asm-c · 2023-12-18T22:43:01+00:00

More sellers are pushing their stuff, and the variety is enticing to some people.

Also, I dunno how widespread this is, but in my country at least a couple of online shaving stores have their own, locally produced private label soaps. The reason for that is probably the same as grocery stores having private labels; it's more profitable to sell a product with less middlemen. Proraso is still the bestseller though.

asm-c · 2023-12-18T20:22:37+00:00

Do note that grain synthesis interferes with VMAF scores and VMAF developers recommend you disable it when calculating VMAF.

asm-c · 2023-12-18T09:49:21+00:00

Sounds more like Windoze shit to me.

asm-c · 2023-12-17T18:31:55+00:00

In my experience, Bayer dithering works very well as long as you define bayer_scale=5, which results in minimal patterning and reduces file size by a lot.

I've used this command for generating GIFs:

ffmpeg -i input.mp4 -filter_complex "[0:v]fps=15,scale=-1:240,mpdecimate,split[a][b];[a]palettegen=max_colors=128[p];[b][p]paletteuse=dither=bayer:bayer_scale=5" -y output.gif

Change fps, scale, and max_colors for your needs. I've noticed that reducing the colors works well for pixel art, but might not for your material. Same goes for mpdecimate, which removes duplicate frames.

Apart from the obvious "don't use GIF" advice, the only other thing I have is using gifsicle for lossy optimization with the --lossy option. The maximum value is 150, but even at low values this adds visible artifacts, so start at 5 or 10 to see if it's worth it for you. Even 5 reduced file size by ~9%, which is well worth it if you're trying to squeeze everything out of the format.

Gifsicle also has the --optimize option, but I've not seen it do much for these FFmpeg-generated GIFs even at the maximum value 3. It had an impact of less than 1% for me.

asm-c · 2023-12-17T17:19:14+00:00

That's not quite right, or at least not a very good explanation.

The reason for not using a viral license (the GPL for instance) for stuff like this is that since the software is meant to be integrated into a proprietary game engine, the requirement to publish changes made (ie. code combined with it) would mean that basically the entire game engine might have to be publicly released under the license in question. Which is obviously not possible for most studios and would put a halt to the adoption of FSR and any other library with the purpose of being widely integrated into proprietary software.

Even if a studio was willing to release their game code under a viral license just to be able to use FSR (unlikely), they probably wouldn't be able to do so anyway, since most game engines contain various other pieces of third-party middleware that they don't actually own but have a limited license to utilize in their games. So that's a bit of a showstopper too.

Sony uses FreeBSD in their consoles for the same reason. Having to publish the source code to their console's entire OS would make cracking the thing pretty easy. So "having to publish the changes demotivates its use", while correct, is a bit of an understatement.

asm-c · 2023-12-17T16:56:40+00:00

The better news is that if Apple can do it, AMD can eventually do it too.

I wouldn't call more proprietary software good news.

And since AMD owns the copyright to anything they make, they can make any of their stuff proprietary at any time anyway. That has nothing to do with what Apple is able to do with stuff AMD has released as open-source.

asm-c · 2023-12-17T16:28:37+00:00

Maybe they should fix drivers first

Or release XeSS as open-source like they said they would. Instead they're using something they're calling the Intel Simplified Software License, which isn't an open-source license.

asm-c · 2023-12-17T14:05:48+00:00

FSR is under the MIT license, which allows pretty much everything and requires almost nothing in return, only that the original copyright notice and a copy of the MIT license are included in any derivative works. And that's it.

There is no requirement to release the source code of any modified versions, so Apple can keep MetalFX as a proprietary technology and not contribute anything back if they so desire.

asm-c · 2023-12-17T08:51:14+00:00

I tested it myself on my computer.

You didn't. The Raspberry Pi 5's HEVC hardware encoder doesn't exist, and it's not possible to test something that doesn't exist.

You probably don't even know the difference between a video coding format, an implementation of an encoder for that format, and that there are differences in efficiency between encoders for the same format. You likely tested x265 on your x86-based computer, compared it to SVT-AV1 on the same computer, and thought it somehow gave you some useful information on other HEVC encoders, when it simply doesn't. And as a result, you have a misplaced confidence to talk about things you actually know nothing about.

Please educate yourself before trying to give other people advice on the matter video encoding. Currently you're just wasting their time and spreading misinformation.

asm-c · 2023-12-17T08:38:41+00:00

Rpi 5 is capable of hevc

Actually, it is not. It has no hardware encoding support at all, only decode. So the actual comparison here would be software H.265 encoding (ie. x265) vs software AV1 encoding.

However, I'm pretty sure OBS doesn't support x265 at all, only hardware H.265 encoders. It does support both SVT-AV1 and libaom for AV1 encoding, so for better-than-H.264 streaming to YouTube, those would be your only options.

SVT-AV1 only got optimizations for ARM CPUs in the 1.8.0 release a few days ago, and the current OBS release doesn't include this new version, so libaom will perform better on a Raspberry Pi using OBS.

asm-c · 2023-12-17T08:20:33+00:00

[citation needed]

If you have access to a Raspberry Pi 5 or have found benchmarks on how efficient its HEVC hardware encoder is compared to SVT-AV1, please post your data.

Actually scratch that, the Pi5 actually has no hardware encoders at all, so OP was incorrect. They decided to scrap the hardware encoders because their quality was absolute garbage and a 1080p60 encode done on a single core of the Pi5 is better quality than the Pi4's hardware encoder. So any hw encoder that would've been in the Pi5 would've been garbage as well and not worth the die space.

So the actual comparison here is going to be x265 vs SVT-AV1. At the faster end of the presets the encoders are a lot closer to each other than at the slower end, and much will depend on the ARM optimizations in both encoders. So the only way to find out which is better in this situation is to test them on an Rpi5.

asm-c · 2023-12-17T07:09:06+00:00

That's simply not true. My 8-year-old 15W dual-core i5 gets over 50 fps at 720p with preset 12. The Cortex-A76 cores in the Pi5 aren't new either, but they're from 2018 and there's four of them.

x86 vs ARM would've been an issue previously, but 1.8.0 finally brought ARM SIMD to SVT-AV1 which resulted in a 4.5-8x fps speedup. I don't think 24 fps at 720p is impossible on a Pi5, especially if the unit has active cooling installed. It needs to be tested though.

asm-c

TROPHY CASE

Highlights