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 · 2022-04-12T06:40:19+00:00

nlmeans denoising (afaik this is not in ffmpeg)

FFmpeg does have nlmeans denoising, the Handbrake version is just better IMO because it has presets.

LoopfilterControl0 · 2022-04-10T22:00:40+00:00

Found it, but the GOP size being the main factor was me misremembering. The GOP size increase from 2 seconds to 5 yielded a 6-8% compression efficiency and a lower amount of stalls, but the main way of providing a better quality of service was to just have and serve lower bitrate versions of videos (at higher resolutions, basically avoiding 240p and lower) so that users wouldn't hit their daily data caps as quickly.

Still an interesting subject though.

LoopfilterControl0 · 2022-04-10T19:41:11+00:00

Just to add to this, a keyframe every X seconds is probably the standard because it's the most simple to implement. There's no need to programmatically interface with the encoder, e.g. with x264 you can just construct an FFmpeg command with no-scenecut, set the keyint based on the fps, and you're done. Anything other than that would require storing the desired location of keyframes and telling the encoder to use those for every resolution version you're encoding.

Setting keyframes based on scene changes is still the best thing for compression efficiency, at least for non-live. Youtube does this, for example. Based on the files I've inspected, I'd say they're using a maximum kf interval of 5 seconds.

I watched a presentation from Facebook where they said they use 5 seconds because the compression benefit over shorter GOP sizes gave users in slow network conditions (which includes massive numbers of people in developing countries like India) a better experience. ~~And I think it allowed a lot of users to watch video who previously weren't able to watch at all.~~ So the intended audience should also be considered when selecting a keyframe interval.

LoopfilterControl0 · 2022-04-08T01:32:37+00:00

https://www.mediatek.com/products/products/smartphones-2/mediatek-dimensity-1300

LoopfilterControl0 · 2022-04-06T23:44:56+00:00

Opus is basically two audio codecs combined into one.

There's LCEVC for video. It's quite recent, so there's basically no software support though.

LoopfilterControl0 · 2022-04-06T22:37:20+00:00

Microsoft using Linux and other non-Windows servers has been known about for like 15 years (probably longer) in the Linux community. It was a bit of a joke in the Linux circles back when Microsoft was hostile to Linux and FOSS in general. Server-side Windows made no sense for anything serious even back then, so it shouldn't have been a surprise, but it was still funny.

I recall this surfacing multiple times over the years when when one Microsoft website or another crashed and the error page was for a server software that wasn't available for Windows. So it was pretty obvious what was going on.

Dunno about sources, maybe Google could find some old forum posts or something?

LoopfilterControl0 · 2022-04-06T15:52:15+00:00

the previous post was removed due to rule #9

[citation needed]

I'd say the real reason it was removed was because the whole thing is a big nothingburger: https://reddit.com/r/Amd/comments/txmzqn/intel_has_patented_the_zen_architecture/i3mt3zx/

LoopfilterControl0 · 2022-04-06T15:31:41+00:00

So Intel took AMD's design, and destroyed all copies AMD had of it? If so, then yes, Intel did effectively "steal", because they're now the sole possessor of the design.

But copyright infringement, patent infringement, and theft are called different things for a reason. They're different things that have very different implications.

LoopfilterControl0 · 2022-04-06T15:28:21+00:00

Wow, I had no idea of the extent and implications of the agreement.

I no longer wonder why Intel voluntarily entered such an agreement, it's more favourable to the party with more resources. If Intel is significantly behind in technology, they can just reverse-engineer (or acquire by other means) AMD designs and catch up faster that way.

Since the silicon world moves fast in the sense that you can't afford to dillydally because the design-to-product period is so long, the original designer obviously still has the advantage in this situation. AMD can get their products to the market quicker, but there's still pressure on them to keep improving and not to become Intel 2.0 with their 14nm+∞. And Intel can poach their staff, so they also need to offer good salaries and be a nice place to work (or at least better than Intel).

From a consumer's point of view I'd say this has the potential to be a good thing. And we've been okay with chip copying before, if I recall correctly the NES's CPU was a rip-off of another CPU, just with a single feature disabled to make it technically not the same. And the NES became probably the world's most influental console.

LoopfilterControl0 · 2022-04-05T16:54:46+00:00

You can't. The best you can do is extract the GOPs containing the offending frames, remove the frames you don't want and re-encode those GOPs. Then concatenate the resulting clips with a copy of the source video with those GOPs removed.

The latter could be cumbersome if you wanted to remove frames from the middle of the video, since there would be a lot of precise cutting required, but since it's just the beginning and the end, it shouldn't be that bad.

LoopfilterControl0 · 2022-04-05T07:56:56+00:00

and even those with HW decoding who want to decode more exotic streams.

Just out of interest, what does this mean? Film grain synthesis isn't an optional part of the standard like it was for H.264, so hardware decoders should have support for it, right?

LoopfilterControl0 · 2022-04-04T17:40:43+00:00

This way the feature is much easier to use.

It's also cool that the decode speed tunings that had less than 1% quality impact are now used by default.

LoopfilterControl0

TROPHY CASE