Alliance for Open Media codecs

[foxyshadis]

now I'm wondering, whether PVQ from the daala folks would've made it smaller ^^ :p
IIRC PVQ was less complex so easier to realize by hw, but was decided against, because of needed additional development time, even though it would've increased efficiency, too.

We'll know when gen2 will be realized (in 5 or 10 years) hehe

PVQ is smaller purely in the frequency domain, where Daala tried to keep everything. But it couldn't stay in the frequency domain with the current state of the art, so it ended up being both less efficient after everything was combined and optimised. Of course, Monty is constantly throwing new things at the wall to see what sticks, so maybe AV2 will change that.

[EwoutH]

AV1 is now quickly becoming mainstream, is it time for an separate Sub-Forum for AV1 (or AOM codecs in general)? I would love separate threads for aom, dav1d, rav1e, svt-av1, hardware acceleration and applications that support AV1.

[Mjpeg]

AV1 is now quickly becoming mainstream, is it time for an separate Sub-Forum for AV1 (or AOM codecs in general)? I would love separate threads for aom, dav1d, rav1e, svt-av1, hardware acceleration and applications that support AV1.

My vote is it's too early for that. It's nice reading about the encoder and decoder stuff in one place for now. Or put another way .. at what average messages/day rate should it split Maybe 25? Where well short of that now.

[EwoutH]

I think the number of messages per day is now also limited because small things don't seem important enough for a combined thread. With split threads I would report way more often about small changes in dav1d performance, SVT-AV1's troubles with Open Source and rav1e and aom related news. Now it just doesn't seem important enough to report on in a general thread.

For example:

Henrik Gramner just made some really interesting optimizations to dav1d's msac function in MR696 (https://code.videolan.org/videolan/dav1d/merge_requests/696) and MR697 (https://code.videolan.org/videolan/dav1d/merge_requests/697), resulting in about 1.5% faster performance on all x86-64 platforms. Martin Storsjö (wbs) is working on adding the same improvements with NEON for Arm64.
dav1d just got a logo (https://code.videolan.org/videolan/dav1d/merge_requests/681)
For benchmarking purposed, dav1d now can be run (https://code.videolan.org/videolan/dav1d/merge_requests/670) at fixed frame rates



SVT-AV1 just reduced memory usage (https://github.com/OpenVisualCloud/SVT-AV1/pull/242) by 30 to 70 percent
Someone is working on a decoder (https://github.com/OpenVisualCloud/SVT-AV1/pull/246) in SVT-AV1
Some effort is made to get SVT-AV1's development process more transparant and compliant with open source practices in this issue (https://github.com/OpenVisualCloud/SVT-AV1/issues/238)

[soresu]

A thought I had, was to make splitting up the general thread easier, you could just take everything pre-bitstream freeze and label it as such.
Thats got to be a serious portion of the thread, and mostly about AV1 development?

[benwaggoner]

AV1 is now quickly becoming mainstream, is it time for an separate Sub-Forum for AV1 (or AOM codecs in general)? I would love separate threads for aom, dav1d, rav1e, svt-av1, hardware acceleration and applications that support AV1.
Certainly tools and infrastructure are getting improved and deployed. But who actually has live content in AV1 other than YouTube?

[dapperdan]

But who actually has live content in AV1 other than YouTube?


Facebook appear to have it all hooked up to deploy AV1 since about a year ago, but whether they actually use it for anything other than testing yet I don't know.

Anyone use Facebook to watch popular videos? Do they have a "stats for nerds" equivalent?

[iwod]

Facebook appear to have it all hooked up to deploy AV1 since about a year ago, but whether they actually use it for anything other than testing yet I don't know.

Anyone use Facebook to watch popular videos? Do they have a "stats for nerds" equivalent?

The likelihood is close to Zero. Although that is just a pure guess.

The latest report from Facebook shows 92% of its users are on Mobile Apps. That is up from 90% YoY and trending towards 100%. I doubt they would want to push AV1 for the sake of saving bandwidth ( even less than a rounding error for Facebook ) at the expense of user battery. ( Which will lower user engagement time, and lower ads revenue, everything Facebook is valued of )

[EwoutH]

SVT-AV1 v0.5.0 (https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.5.0) just got tagged!

Windows build (https://ci.appveyor.com/project/OpenVisualCloud/svt-av1/builds/24654459/artifacts)

[EwoutH]

Amphion announced the CS8142 (PDF (http://www.amphionsemi.com/wp-content/uploads/Amphion-CS8142-One-Pager.pdf)), the first AV1 hardware decoder!

SVT-AV1 just opened a huge PR with unit tests: #260 (https://github.com/OpenVisualCloud/SVT-AV1/pull/260). They also have a lot of development branches (https://github.com/hguermaz/SVT-AV1/branches) open, including one with a lot of AVX2 and AVX512 optimizations (https://github.com/hguermaz/SVT-AV1/commits/lm-opt).

[dapperdan]

Faster decoding in Firefox thanks to Dav1d:

https://blog.mozilla.org/blog/2019/05/21/latest-firefox-release-is-faster-than-ever/

We have seen great growth in the use of AV1 even in just a few months, with our latest figures showing that 11.8% of video playback in Firefox Beta used AV1, up from 0.85% in February and 3% in March.

[sneaker_ger]

11.8%? How? Did Youtube roll out AV1 big time?

[dapperdan]

The 80/20 rule would suggest you only need to encode 20% of the currently popular videos to get 80% of the views so getting up to 11% should be relatively straightforward if YouTube focus on the big hits.

[lvqcl]

11.8%? How? Did Youtube roll out AV1 big time?

It seems that Youtube now streams SD video (480p and below) in AV1 format by default.

[hin12]

It seems that Youtube now streams SD video (480p and below) in AV1 format by default.

All channels with >1 million subs I've seen have AV1 available in SD for videos uploaded from January onwards. I posted this on March 6th:

Is 480p the highest quality option for all AV1 videos on YouTube? I'm seeing that a lot of popular videos are being encoded to AV1, but only at the 144p, 240p, 360p and 480p resolutions.

You had to enable the setting on testtube back then, though.

[lvqcl]

You had to enable the setting on testtube back then, though.
And now it's unnecessary; that's the point.

[stax76]

What is currently the fastest AV1 encoder?

[Tommy Carrot]

What is currently the fastest AV1 encoder?

SVT-AV1 with the default preset. The quality is bad though.

Aomenc with --cpu-used=8 --rt is even faster, but the quality is absolutely rancid.

[stax76]

SVT-AV1 with the default preset. The quality is bad though.

Aomenc with --cpu-used=8 --rt is even faster, but the quality is absolutely rancid.

I'll be waiting for improved encoders then.

[ChaosKing]

rav1e is "fast" with ok quality.

[stax76]

rav1e is "fast" with ok quality.

Last time I tried rav1e 2019-04-30 and it was SLOW AS HELL, like < 1 fps.

[ChaosKing]

Last time I tried rav1e 2019-04-30 and it was SLOW AS HELL, like < 1 fps.

1 fps is fast for av1 :D

[soresu]

I'm just wondering if the quality regression in rav1e has been fixed yet, with activity masking coming from GSOC it should be in a pretty good place quality wise if nothing is still broken.

[VincAlastor]

What is currently the fastest AV1 encoder?

Again thank you very much for staxrip!!!

i use in staxrip a custom cmd line for ffmpeg aomenc from streaming media experts.

-c:v libaom-av1 -crf 40 -b:v 0 -strict experimental -threads 24 -tiles 8x2 -cpu-used 5 -row-mt 1

https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Good-News-AV1-Encoding-Times-Drop-to-Near-Reasonable-Levels-130284.aspx

https://www.reddit.com/r/AV1/comments/9afr5d/my_1700x_encoding_speed_results_mostly_with/


also new version of rav1e with tiles support brings up to 3 fps for fullhd content

https://blog.rom1v.com/2019/04/implementing-tile-encoding-in-rav1e/

[birdie]

At this time shouldn't we consider AV1 a failure and move on to newer codecs, e.g AV2?


It doesn't have fast enough decoders to decode on mobile at 1080p on most devices (>80%).
It still doesn't have encoders which are anywhere fast enough to be usable by mere mortals.
Its hardware adoption is not there - the spec was finalized almost half a year ago, and AV1 is nowhere to be seen in Zen 2.0 (Ryzen 3000), Radeon RDNA 5700 or Intel Ice Lake. No word on its decoding acceleration even in the recently announced Arm's Cortex-A77/Mali-G77.

[nevcairiel]

You do realize that a newer codec would end up even more complex, and thus even slower, and also slowing down hardware adoption even more?
All your points can be applied for any new codec.

- Mobile hardware, especially on the low-end, is inherently slow. The dav1d AV1 decoder can decode 1080p on mid-range and high-end mobile devices. But for mainstream roll out, thats not going to be used anyway, because it uses too much battery.
- Encoder development takes years. You must not have been around when any other codec was new. On top of that, any new codec is also always going to be slower then previous codecs. You pay for quality or compression with speed.
- Hardware development also takes years. Noone knolwedgeable ever realistically expected AV1 to show up in hardware before the end of 2020 or so. The turn-around times for hardware are really long. Hardware you see launch/announced today was long through the design process before AV1 was finished.

Any other new codec would be in the exact same situation a year or so after the spec was officially finalized. In fact this is already looking pretty good on adoption, most major browsers now include AV1 decoders, and YouTube is rolling out content.

Basically, do some more research on how codec lifetime has been in the past for any other codec.

[soresu]

You do realize that a newer codec would end up even more complex, and thus even slower, and also slowing down hardware adoption even more?
All your points can be applied for any new codec.

- Mobile hardware, especially on the low-end, is inherently slow. The dav1d AV1 decoder can decode 1080p on mid-range and high-end mobile devices. But for mainstream roll out, thats not going to be used anyway, because it uses too much battery.
- Encoder development takes years. You must not have been around when any other codec was new. On top of that, any new codec is also always going to be slower then previous codecs. You pay for quality or compression with speed.
- Hardware development also takes years. Noone knolwedgeable ever realistically expected AV1 to show up in hardware before the end of 2020 or so. The turn-around times for hardware are really long. Hardware you see launch/announced today was long through the design process before AV1 was finished.

Any other new codec would be in the exact same situation a year or so after the spec was officially finalized. In fact this is already looking pretty good on adoption, most major browsers now include AV1 decoders, and YouTube is rolling out content.

Basically, do some more research on how codec lifetime has been in the past for any other codec.

I wish I could upvote this, you pretty much laid it out nice and clear there.

[soresu]

To add to Nevcariel's reply to Birdie, I would not expect any ASIC decoders to appear on AMD CPU's as they are generally integrated into the GPU design, which also means they end up in APU's aswell - once they have an ASIC it will be on the nearest APU or GPU release from that point.

[sneaker_ger]

We'll have to wait and see when or if free AV1 encoders surface that can beat e.g. x265 at not more than 10x slow down. It's hard to please the doom9 crowd. VP9 never got to that point, maybe AV1 will be the same.

[nevcairiel]

We'll have to wait and see when or if free AV1 encoders surface that can beat e.g. x265 at not more than 10x slow down. It's hard to please the doom9 crowd. VP9 never got to that point, maybe AV1 will be the same.

Encoders are no longer being made for this crowd. The primary design goal is massive-scale cloud encoding for YouTube, Netflix, Amazon, and everyone else that fits the encode-once, download hundreds of thousands of times scenario.

In such a scenario, even the slowest encoder is acceptable if it saves enough bytes.

In that scenario, VP9 also didn't fail. It gets used for a lot of content on the web.

[birdie]

Encoders are no longer being made for this crowd. The primary design goal is massive-scale cloud encoding for YouTube, Netflix, Amazon, and everyone else that fits the encode-once, download hundreds of thousands of times scenario.

In such a scenario, even the slowest encoder is acceptable if it saves enough bytes.

In that scenario, VP9 also didn't fail. It gets used for a lot of content on the web.

This is what I was talking about.

AV1 is not a codec for masses. It's a very special codec for content delivery. That's it. And that makes it and its discussion kinda worthless.

And VVC is already miles better/faster/more effective than AV1.

[richardpl]

And VVC is already miles better/faster/more effective than AV1.

Whatever you think.

[dapperdan]

I'm not sure it's fair to say VP9 and AV1 were designed purely for those use cases, it's just that that's one of the easiest niches to win if you're a next-gen codec where encoding time is traded for smaller size.

That lets them use it profitably from day one while expanding further into other niches. It probably has impacts on how much effort goes into multithreading or other features that this use case doesn't need.

Libvpx seems to equal x265, subjectively, objectively and in encoding time in the recent MSU study (and both are near the head of the pack) The argument now seems to be that it's the rate control that makes it unsuitable for many users despite good showing in test scenarios. But libvpx having bad rate control is a rather different claim than the VP9 format being 10x slower than it should be and therefore a disaster.

[sneaker_ger]

Doom9 crowd can't exactly live on the potential of a spec. It needs (free/cheap) access to a well-rounded encoder implementation with a sweet spot on bitrate distribution/AQ/speed. x264 and x265 meet those demands. libvpx? Not so much.

[lvqcl]

(free/cheap) access to a well-rounded encoder implementation with a sweet spot on bitrate distribution/AQ/speed.
I suspect that we won't see such encoders for VVC.

[nevcairiel]

I'm not sure it's fair to say VP9 and AV1 were designed purely for those use cases, it's just that that's one of the easiest niches to win if you're a next-gen codec where encoding time is traded for smaller size.


Its not a design target for the codec itself, because the codec really doesn't care. I'm talking about encoders. The huge open-source push that made x264 as great as it is for "personal" encodes is unlikely to repeat itself. Companies driving encoder development do not target doom9ers. You can already see this on x265 where the community involvement is pretty low, and this will only get worse as the computational complexity of codecs goes up and the "personal use" usecases get less attractive.

This is what I was talking about.

AV1 is not a codec for masses. It's a very special codec for content delivery. That's it. And that makes it and its discussion kinda worthless.


This will not change with any future codec. Not with AV2, not with VVC, or anything that follows. The computational complexity increase in all those future codecs just makes it impractical for "hobbyist" use.


And VVC is already miles better/faster/more effective than AV1.

Dream on. A MPEG reference encoder has never won any price in any of those categories.

Doom9 crowd can't exactly live on the potential of a spec. It needs (free/cheap) access to a well-rounded encoder implementation with a sweet spot on bitrate distribution/AQ/speed. x264 and x265 meet those demands. libvpx? Not so much.

And unless the "Doom9 crowd" is going to develop their own encoder, noone is going to do that for them. Thats how x264 was ultimately born, it was made by video enthusiasts, not a company.

---

It really all comes down to the inherent complexity of newer codecs. As it gets more and more impractical to encode them due to the speed, less and less people and smaller companies are going to use them, and the entire ecosystem shifts over to only the bigger players that have the volume to host huge encoding farms. Even if there was a perfect free AV1 encoder, it would still be slow. There is no going fast without sacrificing quality or compression, at which point you eventually cross into the domain of already established codecs, and you lose your reason to even use the newer codec in the first place. Hence, development is no longer targeting individuals or small companies.

[sneaker_ger]

And unless the "Doom9 crowd" is going to develop their own encoder, noone is going to do that for them. Thats how x264 was ultimately born, it was made by video enthusiasts, not a company.
I'm not judging, just saying how it is. People see the advertisement for the new shiny codec and can't wait to profit from "50% less bitrate". They need to reduce their hopes. As you say AV1 today isn't for them and maybe never will. Of course I wouldn't mind to be proved wrong in the future. :)

[benwaggoner]

Encoders are no longer being made for this crowd. The primary design goal is massive-scale cloud encoding for YouTube, Netflix, Amazon, and everyone else that fits the encode-once, download hundreds of thousands of times scenario.

In such a scenario, even the slowest encoder is acceptable if it saves enough bytes.
Oh, these things are always down to cost benefit. Google is just willing to subsidize VPx/AV1 to a huge degree, and likely has a lot of spot-idle capacity in data centers to do the encoding.

But high quality encoding doesn't work with chunks of a few seconds. Encoding longer sequences allows for IDRs and shot changes and more aggressive VBV use. YouTube can have quite a bit of keyframe strobing with difficult content for these reasons. YouTube quality wouldn't be acceptable for lots of premium content.

There has never been a VP9 encoder that offers sufficient quality OR performance for premium content, and there isn' one for AV1 yet either. I don't think this is because the VP9 bitstream wasn't capable of it, it's just that no one wrote an encoder with good psychovisual tuning, intra-frame parallelism, and other stuff.

Encoders are a real chicken-egg problem. There needs to be enough companies willing to pay for better encoders to create a competitive market so that companies work hard to make better encoders than each other. That market never emerged for VP9, so libvpx never saw the kind of quality and performance improvement of, say, the H.264 or HEVC reference encoders to the best available commercial encoders.

There is clearly more interest in AV1 than there ever was for VP9, and more quality innovation already than VP9 has had to date. Which is very promising.

In that scenario, VP9 also didn't fail. It gets used for a lot of content on the web.
Other than YouTube?

VP9/s niche is user-generated non-DRM social media content. And in practice, H.264 would have offered at least equivalent quality at equal encoding time due to faster and more psychovisually tuned encoders. An x264 running at veryslow speed is going to be the same speed as a quite low-complexity VP9 encoder, especially on high-core systems. The quality comparison for high volume use are done at quality @ bitrate @ time.

[benwaggoner]

I'm not judging, just saying how it is. People see the advertisement for the new shiny codec and can't wait to profit from "50% less bitrate". They need to reduce their hopes. As you say AV1 today isn't for them and maybe never will. Of course I wouldn't mind to be proved wrong in the future. :)
We have seen 50% improvements generation-to-generation with the MPEG codecs. But that's at the same point of development. An HEVC enocoder with seven years of refinement isn't going to be only half as good as a VVC reference implementation. But comparing HEVC encoders seven years after spec freeze to VVC seven years after code freeze probably will show ~50% bitrate savings. Some content will even be more. Film grain synthesis could result in 75% reduction in some of the most difficult content, for example.

AV1 wasn't ever promised to be more than 20% better, and even that was in mean PSNR, not psychovisually. AV1 encoders haven't demonstrated any advantage over HEVC with subjective quality, even with the reference encoders.

The VPx code base started VERY heavily PSNR-tuned, which may be way it does well with that today. I don't have any reason to think that is a limitation of the AV1 bitstream versus just the libaom encoder.

But the general case of "AV1 can deliver the same subjective quality at meaningfully lower bitrates than HEVC" has yet to be demonstrated.

[nevcairiel]

Other than YouTube?


Netflix uses it for mobile devices, with the EVE encoder I believe, which they have found to be equal to x265 quality at the time, if not slightly better in some cases (last blog on that was from December)

[TD-Linux]

Last time I tried rav1e 2019-04-30 and it was SLOW AS HELL, like < 1 fps.

You can try speeding it up with the --tile-cols-log2 and --tile-rows-log2 option if you have a lot of cores. I'm working on making these more automatic.

[IgorC]

But the general case of "AV1 can deliver the same subjective quality at meaningfully lower bitrates than HEVC" has yet to be demonstrated.
Unfortunately this can be the case.

Beamr HEVC 2 Mbps does visually better than AV1 3 Mbps. Both VP9 and AV1 are heavily optimizied for specific metrics.

Beamr 2 Mbps (https://drive.google.com/open?id=12rOGjYJI2pmKUVZYgGiQD8E1awI7e75l)
AV1 3 Mbps (https://demo.bitmovin.com/public/firefox/av1/)

[Asilurr]

Libvpx seems to equal x265, subjectively, objectively and in encoding time in the recent MSU study (and both are near the head of the pack).At its worst, a contemporary version of libvpx will encode 8-bit 4:2:0 content as slowly as a contemporary version of x265. Often libvpx is noticeably faster than x265, given similar approaches to encoding complexity.

Here's a quick&dirty test, using an admittedly peculiar content source. Lena_std.tif from lenna.org, RGB24 converted to 8-bit 4:2:0, both downscaled and then upscaled two times each (i.e. 256x256, 1024x1024) into 250 frames long videos. All encoders are the latest versions available today on Wolfberry's public GDrive (https://drive.google.com/drive/folders/1xZQABtoaSFgGu11YstmHKYLzO3elemlC). All encoding times are reported by Win10's PowerShell: Measure-Command {start-process process -argumentlist "args" -Wait}, and expressed in milliseconds.

x264 common settings: --crf 15 --preset veryslow --tune stillimage
405 --threads 1: 03130.76 || 03142.22 || 03119.85 (03130.94)
405 --threads 2: 02101.52 || 02105.54 || 02105.00 (02104.02)
420 --threads 1: 26487.85 || 27508.10 || 26479.85 (26825.27)
420 --threads 2: 16336.86 || 15308.29 || 15327.17 (15657.44)

x265 common settings: --crf 15 --preset veryslow --frame-threads 1 --lookahead-slices 1
505 --no-wpp: 05160.82 || 05161.18 || 05154.55 (05158.85)
505 --wpp: 04131.71 || 04142.67 || 04131.78 (04135.39)
520 --no-wpp: 68123.55 || 68134.36 || 67103.71 (67787.21)
520 --wpp: 36649.91 || 37674.62 || 34628.27 (36317.60)

x265 common settings: --crf 15 --preset placebo --cu-lossless --rd-refine --tskip -qg-size 64 --ref 6 --bframes 16 --me sea --subme 7 --frame-threads 1 --lookahead-slices 1
505 --no-wpp: 063053.81 || 061024.00 || 062028.34 (062035.38)
505 --wpp: 039684.32 || 038664.65 || 038684.41 (039011.13)
520 --no-wpp: 796345.10 || 796345.10 || 796345.10 (796345.10)
520 --wpp: 235701.00 || 235701.00 || 235701.00 (235701.00)

libvpx common settings: --lag-in-frames=25 --passes=2 --end-usage=q --cq-level=20 --good --cpu-used=0 --kf-max-dist=250 --auto-alt-ref=6 --tile-rows=0 --enable-tpl=1 --frame-parallel=0 --ivf
905 --tile-columns=0 --row-mt=0 --threads=1: 05167.92 || 05164.62 || 05167.18 (05166.57)
905 --tile-columns=5 --row-mt=1 --threads=2: 04133.40 || 04143.00 || 04147.51 (04141.44)
920 --tile-columns=0 --row-mt=0 --threads=1: 50871.23 || 49853.74 || 49845.72 (50190.23)
920 --tile-columns=5 --row-mt=1 --threads=2: 31568.60 || 31571.60 || 28518.96 (30553.05)

XAB .. output type
X .. 4 for x264, 5 for x265, 9 for libvpx
AB .. 05 for 256x256, 20 for 1024x1024

Only one x265 beyondplacebo encode at each resolution due to appalling performance.
The average values are reported in brackets, for each output type and encoding settings.

As some sort of hardware footprint is inevitable (HDD versus SSD, memory specs and amount, platform, processor specs), the above targeted the lowest common denominator: parallelism disabled, then parallelism crippled to check the scaling. Conclusions based on this small-scale test:
1. x264 is at least twice faster than either x265 or lipvpx, at comparable encoding complexity.
2. x265 parallelizes better than libvpx as encoding complexity increases.
3. x265 versylow is at best comparable with the slowest libvpx settings, lagging behind as the resolution increases.
4. x265 beyondplacebo is significantly slower than the slowest libvpx settings.

As mentioned above, this is just one possible comparison. The enthusiasts should definitely do their own, and only then report whichever encoder to be the speed demon. It's very hard to conceive that chunk-based libvpx (the obvious caveats aside: logistical hassle and quality issues) is ever slower than x265 regardless of the hardware footprint, each of them at its highest encoding complexity. But instead of testing themselves (with whatever source they please, at whatever resolution and bit depth, on whatever encoding machine), people prefer to reiterate ad absurdum that libvpx is always slower than x265. And it was, indeed, years ago.

[mandarinka]

Last time I tried rav1e 2019-04-30 and it was SLOW AS HELL, like < 1 fps.

If it was on Windows, it is possible you downloaded a build with assembly disabled. Last time I ran test, it was the case (official windows build from the project), and I only got that information like two weeks later after spending days watching the atrociously slow FPS counter. I guess devs expect everybody interested to be on Linux or something. Naturally it would help if the encoder signalled assembly being used like good old x264/x265 do (good idea for linux distros too, because there used to be clueless packagers that disabled ASM accidentaly) or warned when it's not, but I think nobody got around to code that yet.

Encoders are no longer being made for this crowd. The primary design goal is massive-scale cloud encoding for YouTube, Netflix, Amazon, and everyone else that fits the encode-once, download hundreds of thousands of times scenario.

In such a scenario, even the slowest encoder is acceptable if it saves enough bytes.

In that scenario, VP9 also didn't fail. It gets used for a lot of content on the web.

Sadly it's not just about speed, but about quality too. They seem to just care about some metrics on low bitrate content, actual high quality encoding with transparent quality gets a finger.

Its not a design target for the codec itself, because the codec really doesn't care. I'm talking about encoders. The huge open-source push that made x264 as great as it is for "personal" encodes is unlikely to repeat itself. Companies driving encoder development do not target doom9ers. You can already see this on x265 where the community involvement is pretty low, and this will only get worse as the computational complexity of codecs goes up and the "personal use" usecases get less attractive.

This will not change with any future codec. Not with AV2, not with VVC, or anything that follows. The computational complexity increase in all those future codecs just makes it impractical for "hobbyist" use.


There might also be another factor at play: Google and friends siphon away those enthusiasts to work on decoders/encoders for whatever formats they come with. I guess the developers are happy doing that, but I can't help thinking that resource/creative power was kind of wasted polishing me too project like VP9, which never got good anyway. Perhaps it will be a waste with AV1 too, we shall see (hopefully not but track record from predecessors isn't good).

[sneaker_ger]

But high quality encoding doesn't work with chunks of a few seconds. Encoding longer sequences allows for IDRs and shot changes and more aggressive VBV use. YouTube can have quite a bit of keyframe strobing with difficult content for these reasons. YouTube quality wouldn't be acceptable for lots of premium content.
If only Youtube had like .. multiple .. videos coming in daily. Then they could encode them simultaneously on a single CPU each. :devil: (And serve AVC or fast setting VP9/AV1 until they are done.)
You could do a fast first pass for scenechange detection and vbv estimation and send the chunks along with that info.

[nevcairiel]

actual high quality encoding with transparent quality gets a finger.

This is not something any streaming service does though, so why should they invest into developing stuff for a goal they don't even need?
Its just how it goes. And for UHD Blu-ray discs, they can just throw massive bitrates at it to solve any such issues.

As said above, it all comes back to the same thing: If you want a codec for a use-case that noone else focuses on, then do the work, instead of the complaining. :)

[mandarinka]

This is not something any streaming service does though, so why should they invest into developing stuff for a goal they don't even need?
Its just how it goes. And for UHD Blu-ray discs, they can just throw massive bitrates at it to solve any such issues.

As said above, it all comes back to the same thing: If you want a codec for a use-case that noone else focuses on, then do the work, instead of the complaining. :)

That's okay response to complains, but irrelevant response to criticism of the technicals. BTW, I'm not sure all the free software developers contributing are paid by those streaming companies, yet they contribute to this software that is directed at the companies interest only as you say. Perhaps there is some exploitation of volunteer goodwill?

Also you can't really expect users to jump to programming and so that shouldn't really be thought of as a solution. Even if with the open source principles, you are actually entitled to it. But, it's not like, easy to do. Second, users want to do the using, not switching roles to open source programmers.
It's probably easier to just not use such software (and use x264, x265, whatever is better). Though with this "open formats" movement/fandom/advocacy, there is this curious anomaly that people are so strong subscribers to the concept that they want to use it even if it "is not for them" at all... well there are lots of weird layers to these debates.
I think this superstrong mindshare that bends people's views is another reason why pointing out the technical problems should keep being done. And not brushed aside by "it's not for you" arguments. The enthusiasts al over the internets seem to think "it" is for them, by the look of it.
Maybe sometimes they also think all those winning compression tests and netflix blogs are also for them (while perhaps they also aren't?).

[soresu]

There might also be another factor at play: Google and friends siphon away those enthusiasts to work on decoders/encoders for whatever formats they come with. I guess the developers are happy doing that, but I can't help thinking that resource/creative power was kind of wasted polishing me too project like VP9, which never got good anyway. Perhaps it will be a waste with AV1 too, we shall see (hopefully not but track record from predecessors isn't good).

If codec engineers are being siphoned away from anywhere it is other codec projects.

The guy under the name xiph_mont was working on a new audio codec called Ghost when Daala started up in earnest and it was abandoned - and he later moved to AV1 development with most of those that worked on Daala.

[dapperdan]

Xiphmont was employed by Red Hat and Mozilla, both companies that have a business model (and a mission) incompatible with codec licenses and therefore strong motivation for "me-too" codecs that they can integrate properly.

(Which reminds me, VP9 has been the default codec choice for webRTC in Firefox and Chrome for a couple of years. I can't quickly find any stats on what kind of usage this gets. Originally the browsers agreed a compromise of supporting both VP8 and H.264 baseline and Firefox shipped that via a licencing hack where Cisco provide the binary blob and it doesn't cost them anything in licence fees because they were already at the annual cap.)

[Tommy Carrot]

What's the difference between deltaq and AQ in aomenc? Deltaq changes the quantizer of the frames, and AQ changes the quantizers of the blocks within the frames, or am i completely wrong?

Also, what is tpl-model, what does it do?