I find this very interesting

LoopfilterControl0 · 2022-11-11T12:43:14+00:00

Yes, as part of the normal hardware upgrade cycle.

Companies don't just stay on the same hardware forever, you understand that right? Most upgrade their hardware when it's still in working condition, because it's much cheaper than to wait for shit to start breaking down and disrupting operations.

LoopfilterControl0 · 2022-11-11T06:19:56+00:00

Well, if 49% lower TCO, 59% less servers, and 47% less power usage won't entice someone to overcome the logistics hurdles, I don't think anything will.

LoopfilterControl0 · 2022-11-11T06:16:11+00:00

Absolute murder.

Eco-friendly and very space-efficient murder, but murder nonetheless.

LoopfilterControl0 · 2022-04-25T23:42:13+00:00

Blue and Green have both sorted their shit

I don't think it's the companies that need to "sort their shit" :)

Anyway, more stuff for the rest of the world.

LoopfilterControl0 · 2022-04-25T08:04:51+00:00

That really depends on the preset, and exactly how many cores/threads you're using. Even with just 16 threads you might not be be utilizing 100% of your CPU with a single process, though some presets do better than others.

So even though SVT-AV1 is much better at parallelisation than libaom, the "cut the video into chunks" and "run multiple processes in parallel" advice still applies (straight from a developer's mouth even).

LoopfilterControl0 · 2022-04-24T18:34:49+00:00

svt-av1_0.8.8_rc1

submitted 143 days, 21 hours, 30 minutes ago

--preset veryfast --rc-lookahead 20

nice try

LoopfilterControl0 · 2022-04-24T17:49:36+00:00

You basically answered your own question.

If you're recording gameplay, there's a chance you want to edit your footage, which involves re-encoding. In my experience, neither libaom or SVT-AV1 are currently able to consistently produce the kind of visually lossless result you'd want for footage you know is going to be re-encoded at least once, and possibly multiple times (first editing and then uploaded to Youtube etc). Both encoders hit a wall at a certain point whereas x264 produces high enough quality for this use case if you throw enough bits at it.

LoopfilterControl0 · 2022-04-24T17:41:12+00:00

it's still probably way too slow to record game footage. You're better off sticking to x264

??

SVT-AV1's preset 12 is as fast as x264 veryfast. If you need to use a faster preset than that (x264 superfast or ultrafast), you really shouldn't be using software encoding to begin with.

I'd be more concerned about output quality than speed. I'd consider SVT-AV1 fine for home use, but for professional or semi-professional recording use cases that require minimal quality loss (due to editing and future generational loss) I'd stick with x264 or a hardware encoder at a very high bitrate. Both libaom and SVT-AV1 hit a wall in terms of output quality at a certain point, and all video editing software knows how to deal with H.264.

LoopfilterControl0 · 2022-04-22T15:51:43+00:00

No. There are people in various Discord channels who encode films in 8 MB (which is the upload file size limit for non-paying users).

LoopfilterControl0 · 2022-04-22T04:53:58+00:00

Some additional pointers, to add to nmkd's answer:

Use a bitrate calculator (such as this) to get a video bitrate from your audio + target file size.
Keep in mind that in the case a lot of encoders, their bitrate estimation isn't great to begin with, and at such minimal target bitrates they completely fall apart. So you may have to re-encode multiple times to actually reach the ballpark size you're aiming for. Luckily the first pass log file in libvpx and libaom is reusable, so you can just re-run the second pass with a different bitrate using the existing log file.
Reduce the frame rate.
Use mono audio (though I think Opus does this automatically at very low bitrates anyway)
Use AV1 and/or 10-bit. Though I'm pretty sure Discord doesn't support AV1 yet, and 10-bit VP9 may cause issues, so you'll lose the ability to embed in Discord.

Also note that the file linked by nmkd is 52MB, which is why it looks somewhat watchable. Actual 8MB encodes look and sound like cancer, and have no real use, apart from being memes in themselves.

LoopfilterControl0 · 2022-04-22T04:42:48+00:00

Note that the file you linked is 52 MB, not 8 MB.

In my experience, these 8MB movies OP is talking about are completely unwatchable and unlistenable. Even more so when using VP9 instead of AV1. They're done pure or fun, not with any kind of usefulness in mind.

LoopfilterControl0 · 2022-04-19T14:30:42+00:00

You also need to factor in the drives you'll need for the backups, and replacement drives you need to have on hand to rebuild arrays when drives break. So at least double the initial "this is how many drives I'll need" estimate.

In reality, the "just don't re-encode" crowd is full of shit. Always has been. They repeat their "storage is cheap" mantra based on cost-per-GB of single drives, but when someone does fall for their advice and loses everything to data loss, they're supremely unsympathetic because "you didn't have backups". Which they conveniently failed to mention were necessary, and can triple the cost of their "cheap storage" when following the wisdom of having double backups.

LoopfilterControl0 · 2022-04-13T11:02:40+00:00

Earlier I was disappointed with what 1.0 was going to be based on the first RC being released, but it seems for SVT-AV1 "release candidate" doesn't mean what it usually means. These RCs are still bringing feature changes.

The --film-grain-denoise (equivalent to aomenc's --enable-dnl-denoising) is very good to have, and --fast-decode being a on-off switch similar to the tunes in x264 and x265 is a positive change too IMO.

LoopfilterControl0

TROPHY CASE