Log in

View Full Version : Alliance for Open Media codecs


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

hajj_3
12th July 2018, 08:20
https://medium.com/@luc.trudeau/av1-opportunity-or-threat-for-power-and-arm-servers-6871007ad99e

paul97
12th July 2018, 11:21
When there''ll be a good and official encoder for AV1. (for example in Handbrake or Youtube. We need to wait for Mozilla''s Rust Encoder or they immediately will release AOMedia encoder?

LigH
12th July 2018, 20:05
Official? Well, aomenc is already available as codec for ffmpeg; and HandBrake uses an ffmpeg core, you just need to build a recent version or hope for one to be released.

Whether it is "good" ... your demands, you opinion.

benwaggoner
12th July 2018, 20:06
When there''ll be a good and official encoder for AV1. (for example in Handbrake or Youtube. We need to wait for Mozilla''s Rust Encoder or they immediately will release AOMedia encoder?
What do you consider a "good official" encoder for H.264 and HEVC? Generally for the MPEG codecs there is a reference encoder which is way too slow for production use, and then a variety of vendors making their own implementations, some open-source, some proprietary.

I wouldn't expect to have everyone using one "official" encoder like libvpx with AV1 if AV1 gets significantly broad market adoption. VPx had mainly a very small number of very large companies using it.

olduser217
13th July 2018, 03:11
Yup - rav1e - https://github.com/xiph/rav1e


From encoding strategy or algorithm point of view, are these AV1 encoders developed by Mozilla or EVE have any difference compare to the one from AOM? Or just mainly encoding speed up?

mzso
13th July 2018, 10:48
From encoding strategy or algorithm point of view, are these AV1 encoders developed by Mozilla or EVE have any difference compare to the one from AOM? Or just mainly encoding speed up?

I don't think that any of the encoders are in a usable state yet.

benwaggoner
13th July 2018, 19:16
I don't think that any of the encoders are in a usable state yet.
Certainly not for large scale content publishing.

Given historical encoder development, I wouldn't expect AV1 encoders to be able to practically compete with HEVC encoders for large commercial mission-critical live/VOD applications before Q4 2019.

There's a long path from "look, I can encode a little clip in two days that'll play in this pre-release web browser" to "this is good enough to replace the stuff I bet my business on already."

And 1080p and UHD are things, and the current AV1 are too slow to do enough encoding at those resolutions for tuning, and optimal tuning can be quite different at higher resolutions, particularly 2160p. So no one really even knows how suitable AV1 is as a technology, let alone how applicable current encoders are for it.

Beyond quality @ perf, there's tons of integration effort along many end-to-end pipelines. And some of those pipelines will require a decent quality 2160p60 low latency live encoder. In theory it's obvious how it works, but in practice SO many little things will and do go wrong.

Even with mature codecs, you try to raise the reference frame count of a low bitrate stream (still staying under profile @ level minimum), and you realize that some mobile chipset's DRM implementation requires a boot-time memory carveout of max ref frames * max frame size. So if you use 6 refs at 320x240, and your max frame size is 1920x1080, you still need to carve out 6 1920x1080 frames.

So many little implementation details like that need to get discovered and ironed out with every new codec. One advantage of AV1 is that supporting chipsets will all be newer, so the backwards compatibility won't be as fraught. But in many cases, fraught backwards compatibility is vastly better than none at all.

That's why tons of broadcast/cable is still MPEG-2.

Blue_MiSfit
13th July 2018, 23:34
Super well put, per usual, Ben.

I'm stoked to dive head-first into AV1 testing once I have some more time. I'm neck deep in HEVC right now :)

uneedme
14th July 2018, 08:16
i typed --help ......

too much parameters

I tried to read the references...... tried to get the meanings of abbreviations

alot arguments with no range indications......


............

any good guide texts?Thanks indeed

TD-Linux
19th July 2018, 21:08
From encoding strategy or algorithm point of view, are these AV1 encoders developed by Mozilla or EVE have any difference compare to the one from AOM? Or just mainly encoding speed up?

Both have methods to improve quality, as well. EVE gives a large improvement over libvpx quality via a number of methods. rav1e is not nearly as far along, but does already have psy optimization, unlike libaom. You can try it out with the --tune psychovisual flag if you like.

mzso
20th July 2018, 09:25
Both have methods to improve quality, as well. EVE gives a large improvement over libvpx quality via a number of methods. rav1e is not nearly as far along, but does already have psy optimization, unlike libaom. You can try it out with the --tune psychovisual flag if you like.

Is rav1e forked from libaom, or was it written from nothing?

LigH
20th July 2018, 14:35
New upload:

AOM v1.0.0-181-g3bffe09a5 (https://www.mediafire.com/file/by73glqlyag4ya7/aom_v1.0.0-181-g3bffe09a5.7z)

v0lt
20th July 2018, 20:01
Almost a month has passed since the freezing of the bitstream (2018-06-26). Official samples posted somewhere?

TD-Linux
20th July 2018, 23:17
Is rav1e forked from libaom, or was it written from nothing?

It's written from nothing, however it does link in some CDF tables and the transform SIMD code from libaom as we haven't written our own yet.

Almost a month has passed since the freezing of the bitstream (2018-06-26). Official samples posted somewhere?

If you run "make testdata" in libaom you'll get a ton of test ivf files that are used to verify the decoder. They are as close to "official samples" as exist right now.

Tommy Carrot
20th July 2018, 23:47
New upload:

AOM v1.0.0-181-g3bffe09a5 (https://www.mediafire.com/file/by73glqlyag4ya7/aom_v1.0.0-181-g3bffe09a5.7z)
:thanks:

vidschlub
23rd July 2018, 01:33
How long do people think till we start seeing files encoded with this on the web, even from the hardcore crazy people (anime)

I'm going to assume at least 12 months?

Tommy Carrot
23rd July 2018, 12:45
Well, the encoder has gotten 2-3 times faster in the last 4 months. It still needs to be at least 50-100 times faster to be anywhere near being usable as an encoder. Maybe they pick up the pace now that the bitstream is finalized, but i'd say it will probably take more than 12 months.

v0lt
23rd July 2018, 13:46
It still needs to be at least 50-100 times faster to be anywhere near being usable as an encoder.
You are an optimist. According to my calculations, the codec needs to be accelerated 1000 times.

Tommy Carrot
23rd July 2018, 14:31
Lol, i try to be realist. ;) AV1 is a much more complex codec than VP9 or h.265, so i can accept that it will be slower. 1 fps at 720p for the veryslow preset equivalent would be acceptable to me (assuming no serious quality degradation of course). Although you're right, that'd need probably more than 100x improvement.

excellentswordfight
23rd July 2018, 17:07
Lol, i try to be realist. ;) AV1 is a much more complex codec than VP9 or h.265, so i can accept that it will be slower. 1 fps at 720p for the veryslow preset equivalent would be acceptable to me (assuming no serious quality degradation of course). Although you're right, that'd need probably more than 100x improvement.
This got me curious, is that for private use? If so what is the use case for a encoder that slow? Cant be for storage space, even if bitrates were noticeably lower in 720p than x265, it would be so slow that it would take you an lifetime to fill an 3TB drive at that speed :)

Tommy Carrot
23rd July 2018, 17:45
This got me curious, is that for private use? If so what is the use case for a encoder that slow? Cant be for storage space, bitrates were AV1 would be noticeably better in 720p than x265 would be so low that it would take you an lifetime to fill an 3TB drive at that speed :)

Yes, for private use. To be honest i'm still using x264, because at the crf 18-22 range it's still performing very well, while being lightning fast compared to the newer codecs. Neither x265 nor VP9 are noticeably better (if at all) at that bitrate range. If AV1 can deliver similar quality at a significantly lower bitrate, i might switch to that, because i like to have the best possible quality at the lowest possible bitrate. X265 is simply not better enough to worth the hassle to switch to that (and VP9 is IMO worse than x264 at that bitrate range). I have more than enough storage space, but still, i dont want to have bloated videos if there are better alternatives, and i dont encode that much that i couldn't wait a couple of hours for an encode.

But more importantly, a usable encoder would mean youtube could finally improve the video quality, assuming of course that they dont use the improved efficiency to lower the video bitrates.

user1085
24th July 2018, 01:53
Yes, for private use. To be honest i'm still using x264, because at the crf 18-22 range it's still performing very well, while being lightning fast compared to the newer codecs. Neither x265 nor VP9 are noticeably better (if at all) at that bitrate range. If AV1 can deliver similar quality at a significantly lower bitrate, i might switch to that, because i like to have the best possible quality at the lowest possible bitrate. X265 is simply not better enough to worth the hassle to switch to that (and VP9 is IMO worse than x264 at that bitrate range). I have more than enough storage space, but still, i dont want to have bloated videos if there are better alternatives, and i dont encode that much that i couldn't wait a couple of hours for an encode.

But more importantly, a usable encoder would mean youtube could finally improve the video quality, assuming of course that they dont use the improved efficiency to lower the video bitrates.If you have to encode 4K HDR10 content, then your only option is x265 right?

Blue_MiSfit
24th July 2018, 04:40
Nope, not by a long shot. There's lots of rather good commercial encoding solutions for 4K HDR10 encoding today.

See Beamr, Ittiam, Ateme, etc...

user1085
24th July 2018, 08:14
Nope, not by a long shot. There's lots of rather good commercial encoding solutions for 4K HDR10 encoding today.

See Beamr, Ittiam, Ateme, etc...I meant for my personal collection

Blue_MiSfit
25th July 2018, 00:54
In that case, yeah x265 is likely your best option. There's always the Intel / nVidia encoders, and whatever Adobe has in Adobe Media Encoder (Mainconcept maybe?)

Blue_MiSfit
25th July 2018, 01:05
Holy crap guys, the latest Chrome Canary has a significantly improved AV1 decoder. You can play this http://video.1ko.ch/codec-comparison/videos/av1-2018-06_550.webm 1080p test stream using very little CPU.

hbbs
25th July 2018, 03:05
Holy crap guys, the latest Chrome Canary has a significantly improved AV1 decoder. You can play this http://video.1ko.ch/codec-comparison/videos/av1-2018-06_550.webm 1080p test stream using very little CPU.

It didn't work for me on today's canary anyway.

But this sample played on the latest mpv.

Do you have more samples?

hbbs
25th July 2018, 03:52
Firefox Nightly also is playing this demo above.

That's a lot of improvement from the time of that bitmovin demo.

On Firefox Nightly remember to toggle "media.av1.enabled" to true.

Blue_MiSfit
25th July 2018, 18:39
Yeah you need to enable AV1 decoding in the options.

https://www.reddit.com/r/AV1/comments/91gchg/psa_firefox_nightly_and_chrome_canary_can_now/

excellentswordfight
26th July 2018, 08:17
Yeah you need to enable AV1 decoding in the options.

https://www.reddit.com/r/AV1/comments/91gchg/psa_firefox_nightly_and_chrome_canary_can_now/
Is it lag free for you? I'm getting quite a lot of dropped frames. 20% ish usage on all cores, i7-7500U.

clsid
26th July 2018, 14:05
The video itself is just laggy and poor quality. I have it working in MPC-HC (private test build). No drops.

Benchmark in GraphStudioNext gives 32fps. It seems to be single threaded by default. Need to check compile options later.

soresu
26th July 2018, 14:29
I wonder how conducive AV1 is to decoding by GPU OpenCL, certainly seems like the ideal way to go prior to ASIC decoders being integrated into SoC's and GPU's. Presumably some of the hardware input from companies like AMD, nVidia and Intel covered this?

iwod
26th July 2018, 16:15
I wonder how conducive AV1 is to decoding by GPU OpenCL, certainly seems like the ideal way to go prior to ASIC decoders being integrated into SoC's and GPU's. Presumably some of the hardware input from companies like AMD, nVidia and Intel covered this?

OpenCL isn't silver bullet, copying data between GPU and CPU will likely be expensive for decoding operation.

Gravitator
26th July 2018, 17:26
The video itself is just laggy and poor quality. I have it working in MPC-HC (private test build). No drops.

Timing to the open version?
Park_Joy will bring to the clean water all the PR of the next-gen video format. :)

Blue_MiSfit
26th July 2018, 19:42
I see only about 5% CPU usage on my i7 6700k. Upon reviewing a bit more there are some frame drops happening, so there's still work to do here for sure.

The quality is rough, but it's 500 Kbps, so quite impressive TBH.

Nintendo Maniac 64
26th July 2018, 23:52
OpenCL isn't silver bullet, copying data between GPU and CPU will likely be expensive for decoding operation.

Weren't those expensive memory copying operations exactly what AMD's HSA and hUMA were supposed to solve?

I realize that, back when HSA and hUMA were introduced, AMD only had APUs using the sub-par "Bulldozer" architecture and its evolutions - this meant there wasn't exactly much interest in tailoring software towards AMD CPUs at the time, but Ryzen is definitely a completely different beast.

Now obviously this would only work on Ryzen APUs, but that's not exactly an issue on laptops when all mobile Ryzen chips are APUs anyway (not counting those uber-performance laptops that use a full-fat AM4 desktop Ryzen CPU). Besides, I would imagine that most non-APU Ryzen processors could at least "brute-force" their way via the abundance of CPU cores and threads to decode the video stream (assuming that AV1 decoding could be made to take advantage of that many threads).

...of course, this assumes that Ryzen APUs even support HSA and hUMA. I mean, AMD hasn't mentioned anything about them for a while now, so who knows?


EDIT: I was reading through some of the older posts in this thread and I just had to respond to this:
I'm sorry, tell us again about how this codec isn't designed for your 20-year-old Pentium 4. That has nothing to do with optimizability under AVX/AVX2 or Altivec, which are the only instruction sets that matter today.

The first Pentium 4 was released in late 2000, but those were the lame Willamette models that needed RDRAM. Much more popular were the Northwood models that supported DDR memory, but those didn't come out until early 2002.

So no, not 20 years ago.

And AVX isn't supported on even the newest Sky/Kaby/Coffee Lake-based Pentium and Celeron CPUs either (and no, I don't mean the low-power Atom-based Celerons & Pentiums), including the ever-popular 2c/4t Pentium CPUs like the G4560 and G5400.

mzso
27th July 2018, 12:13
Weren't those expensive memory copying operations exactly what AMD's HSA and hUMA were supposed to solve?

It did solve it. It's just that no-one bothered using it.

Too bad. If things wen the other way around it could have opened up a bunch of algorithms to use together. Intel (ARM) would have been forced to follow and we might have some pretty cool stuff by now. Maybe we'd be at a brink of two layer CPU+GPU APUs.

IgorC
27th July 2018, 18:35
Holy crap guys, the latest Chrome Canary has a significantly improved AV1 decoder. You can play this http://video.1ko.ch/codec-comparison/videos/av1-2018-06_550.webm 1080p test stream using very little CPU.
Thank you for the video.

Slow motion parts have very good quality (considering it's 1080p@550k). However high motion moment is looking ugly. :mad:
Rate-control isn't well tuned, I guess.

Nintendo Maniac 64
27th July 2018, 20:20
It did solve it. It's just that no-one bothered using it.

That's why I mentioned the whole "Bulldozer was a bit sub-par", because as Itanium proved, devs aren't really going to develop for something that's fast at new things if it's also a complete dog at old things.

And that's also why I mentioned Ryzen, because it's totally not a dog at all, and those Ryzen APUs are arguably even more competitive in mobile (at least if you ignore those 6core Intel parts, but I would be very surprised if mobile Zen2-based APUs weren't also sporting at least 6 cores).

But again, I have literally no idea if Ryzen APUs support HSA and hUMA, and I've even tried researching the subject.


If there's any consolation, I imagine that any future AMD-powered console would support this functionality, and heck even Intel's renewed focus on graphics may result in something similar in the future.

Barough
28th July 2018, 12:02
AOM AV1 v1.0.0-245-ge4d148435 (http://www.mediafire.com/file/vblp969d4whc5p0/)
Built on July 28, 2018, GCC 7.3.0

https://aomedia.googlesource.com/aom

utack
29th July 2018, 00:47
Is it just me, or is the tuning of libaom stil way off?
It completely murders some darker and "flat" areas, where x265 retains a lot of detail
Example (especially bottom right, from a 30s clip, same bitrate):
http://screenshotcomparison.com/comparison/117597

Is there some optimization coming, that takes human perception into consideration and distributes bitrate accordingly?

Tommy Carrot
29th July 2018, 01:18
I don't think it has any visual tuning yet, it's only being tuned for a variety of metrics. Also, AV1 uses golden frames (imho a bad legacy from vp9), so the frame quality varies quite considerably, so judging individual frames are not necessarily an accurate way to compare quality.

foxyshadis
29th July 2018, 06:35
Any codec that smooths that much is obviously PSNR-tuned.

It was funny waking up this morning and seeing Monty log on to the IRC channel with, "'mornin. How close are we to 1.0?" Crackin' the whip.

mandarinka
29th July 2018, 13:50
And AVX isn't supported on even the newest Sky/Kaby/Coffee Lake-based Pentium and Celeron CPUs either (and no, I don't mean the low-power Atom-based Celerons & Pentiums), including the ever-popular 2c/4t Pentium CPUs like the G4560 and G5400.

Very important point. I actually found that some multimedia devs weren't aware of this in the past, thinking they only need to write AVX2 now. It's rather unfortunate that Intel insists on this.

The Atom cores matter too though, IMHO. There is a huge number of devices with them and they actually improve a lot currently (Goldmont, Goldmont+), much more than Intel big cores. Yet they still keep only 128bit SIMD (SSE-SSE4) so it would really be good if the devs of important format's decoders took time to implement SSE* functions and not just AVX2 ones. After all, there is also a huge number of fast CPUs that don't have AVX2, like Sandy/Ivy Bridge CPUs a la i5-2500/2400 or i7-2600K.

---------------------------
Hmm, BTW. Are there some good estimates as to what CPU will be needed for comfortable decoding of 4K content (24 - 30 fps) in AV1 with all bells and whistles of the format used? (10bit etc, all the compression tools on, high bitrates including spikes in motion, VBR with no streaming-style constraints...). With some sane headroom.

Jamaika
29th July 2018, 15:30
Yet they still keep only 128bit SIMD (SSE-SSE4) so it would really be good if the devs of important format's decoders took time to implement SSE* functions and not just AVX2 ones. After all, there is also a huge number of fast CPUs that don't have AVX2, like Sandy/Ivy Bridge CPUs a la i5-2500/2400 or i7-2600K.
Little real. The creators of the new JPEG codecs google or dropbox aren't interested in prehistory. :(

Nintendo Maniac 64
29th July 2018, 20:43
prehistory

This is why I focused on the newest Pentiums like the G5400 - one can't use the "old" argument if they're literally the newest generation of Pentiums available.

Jamaika
29th July 2018, 21:34
Off top:
For me, a poor man and an enthusiast, let's say novelties, in Central Europe the computer ages after five years. Then the computer for free throws into the bucket and begins the path of cost-effective recycling to Asia. For me, an inconceivable fact.
I remember the times when Intel's new processors debuted on the market every two weeks. It was a market. The world is changing and for sure it isn't an era of Intel.
https://pclab.pl/zdjecia/artykuly/blind/2015/03/skylake/intel2.PNGhttps://www.fudzilla.com/images/stories/2016/April/intel-avx-512.jpg
https://linustechtips.com/main/topic/379471-intels-skylake-cpus-for-pcs-wont-support-avx-512-aka-avx3/

mzso
29th July 2018, 21:45
I don't think it has any visual tuning yet, it's only being tuned for a variety of metrics. Also, AV1 uses golden frames (imho a bad legacy from vp9), so the frame quality varies quite considerably, so judging individual frames are not necessarily an accurate way to compare quality.

I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.

Tommy Carrot
30th July 2018, 12:08
I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.
Maybe so, but it definitely has some disadvantages too. Golden frames are very noticeably higher quality than the rest of the frames, so they can cause uneven, fluctuating quality (the finer details are vanishing and coming back periodically). This can be rather distracting if you start noticing this tendency.

Granted, AV1 is much better in this regard than VP9, but this issue is still there.

LigH
30th July 2018, 13:27
Well, "B-frame pumping" already existed in MPEG-2 times. Very noticeable in the "Animatrix" DVD. May just be a matter of tuning?