Alliance for Open Media codecs

[LigH]

And I believe MABS even only selects -O2.

MSYS2 can't include GCC 8.2.0 in the 32-bit branch because it doesn't build itself without errors. I like how MABS keeps MSYS2 up-to-date before updating and compiling the projects. I don't want to miss this feature completely due to very rare compiler issues limiting the speed of the generated code; ultimately it has to be fixed in GCC, and when this happens, MABS will update MSYS2 to it.

I could dig in my archives and find an older MSYS with GCC 7.x too, but I don't want to stuff my drive for a rather little reason. I hope I am not the only provider of binaries...

[SmilingWolf]

Nope, the only custom GCC flags MABS uses are the ones that won't cause UMA (because typing unaligned memory access all the time is tiring): https://github.com/jb-alvarado/media-autobuild_suite/blob/ccd2fd49bc9fbccec428f02e1b895e219c3cc02b/build/media-suite_compile.sh#L837
Every other compiler flag is left to the default, which implies -O3

Anyway, I think I have almost worked out what's wrong with issue 2145 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2145) and might be able to propose a temporay fix and an explanation shortly. So that would be one out of everybody's hair

As for binaries, as I said I can compile 64bit stuff on my VM now (the first ones are right above, in my first post (http://forum.doom9.org/showpost.php?p=1851277&postcount=902)), if there's need for something particular I guess I can tweak my setup. E.g. I might be able to stuff an extra 32bit toolchain on the VM. Just, no WinXP support, please

[easyfab]

with MABS, personnaly I create a custom_build_options file ( see L. 63-66 media-suite_compile.sh) with

export CFLAGS="-march=native -O3 -pipe"
export CXXFLAGS="${CFLAGS}"

[TD-Linux]

1) there is a general lack of configurable settings and I heard some rumor that this might actually be somewhat a policy (like the nonexistent user-facing configurabiltiy in Theora?) and not just effect of being early in development.


I plan to add debugging options exactly for the purpose of getting feedback from users - the first obvious thing to add is the internal cdef-dist parameters to tune them. That said, they will remain debug options - for example, we may change how cdef-dist works internally when we find a better way to do it, and that will break the options. If you find a combination of debug options that looks better, I'd rather you report it as a bug and we use that information to change the defaults.

BTW we are getting segmentation soon - once we get it I'll let you know, it'll make the effect of cdef-dist far stronger.


2) a smaller thing: there is very little feedback given by the commandline encoder. A FPS counter probably isn't completely important, but there is one thing that really would help with testing, and that is a achieved bitrate being reported at the end. I was rather suprised Rav1e didn't report this, because I wanted to encode a comparison clip with 2pass with another encoder and this is rather complicating. I have to figure it out based on filesize but the output's already in a container that has some unknown overhead... I used bitrate calculator like in 2006 but note that those generally only have 1 second precision, which is not very exact for short testing samples.

I would happily take patches for this. That said, the top priority is actually to get it integrated with ffmpeg, which will give you a printout of the framerate and bitrate, plus allow muxing and many more input formats.

[SmilingWolf]

av1-1.0.0-552-gbb82e05fb: https://mega.nz/#!99ASgKAJ!l7Lc4n9KEs2eHeaebwnmLyHDVUrRf9FgrYxXAEaoByw

As promised, the explanation for BUG=aomedia:2145 has dropped (https://bugs.chromium.org/p/aomedia/issues/detail?id=2145#c6). Does anybody know if one of x264/x86inc.asm maintainers could take a look?
There are some contacts in the header of the file, I suppose my best bet is e-mailing Henrik Gramner, who seems responsible for most of the recent commits, yes?

[nevcairiel]

If a register is being used has to be flagged by the ASM function in question (in its cglobal line), x86inc.asm cannot detect that automatically, the code has to tell it. If its not pushing regs that are in fact being used, then the cglobal line may be wrong. From the code it looks like the macro is being passed a "7" for numbers of register used, while RSI would be the 9th in their counting (ie. r8). I don't see it directly being used in quantize_b, but it maybe used behind a symbolic name to load a parameter.

[SmilingWolf]

Cr*p and I just sent a mail to Henrik.

Yes, RSI is used here (https://aomedia.googlesource.com/aom/+/f36be56b39c1125264a6c4b9a7e835855e5d50c8/aom_dsp/x86/quantize_avx_x86_64.asm#182) for dequantq

Ok let me test that real quick.
Thanks for the input!

[nevcairiel]

If dequant is the highest parameter being used, changing the 7 to a 9 at the end of the file might be all that is needed.

[SmilingWolf]

YES! Fix confirmed!

EDIT: and patch sent: https://bugs.chromium.org/p/aomedia/issues/detail?id=2145#c7

[Aleksoid1978]

av1-1.0.0-552-gbb82e05fb: https://mega.nz/#!99ASgKAJ!l7Lc4n9KEs2eHeaebwnmLyHDVUrRf9FgrYxXAEaoByw

As promised, the explanation for BUG=aomedia:2145 has dropped (https://bugs.chromium.org/p/aomedia/issues/detail?id=2145#c6). Does anybody know if one of x264/x86inc.asm maintainers could take a look?
There are some contacts in the header of the file, I suppose my best bet is e-mailing Henrik Gramner, who seems responsible for most of the recent commits, yes?

Hello. Can you compile static lib for use with any project, like ffmpeg ?? I need x86/x64 AV1 decoder only.

I don't know why - but on my home/work PC i can't compile, cmake error on AVX2(my PC don't support AVX2).

[marcomsousa]

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-First-Look-127133.aspx

I like more the second round testing at lower data rates and this comment:

You should focus your tests on the data rates at which your video will most likely be deployed. At this point, H.264 and any newer codec should produce near perfect quality at 6 Mbps, making that data rate irrelevant for forward-looking testing. HEVC and VP9 take the near perfect quality level down to between 3.5Mbps to 4Mbps, and AV1 and future codecs should bring this down into the 2Mbps to 3.5Mbps range.

[SmilingWolf]

Hello. Can you compile static lib for use with any project, like ffmpeg ?? I need x86/x64 AV1 decoder only.

I don't know why - but on my home/work PC i can't compile, cmake error on AVX2(my PC don't support AVX2).

You should post a log and some infos on your building env. Missing AVX2 at compile or even configure time looks like an outdated version of GCC rather than an issue with your CPU.
Maybe there is an older version/toolchain in your $PATH that's interfering?
GCC 7/8 can emit AVX2 instructions even when running on an old Pentium 4.

[Aleksoid1978]

Use VS 2017 or GCC 8.2.0 - there is no difference.

[SmilingWolf]

Can you post the full cmake -G "MSYS Makefiles" etc. etc. log on pastebin as it appears on screen?
Or, better/more complete, the contents of <yourBuildDir>/CMakeFiles/CMakeError.log and CMakeOutput.log?

[Blue_MiSfit]

Decoding using vlc nightly on the above ~1 Mbps 1080p encode from YouTube is working very well - takes about 10% CPU on my i7-6700k

[mzso]

The era of HW encoders is behind us. HEVC was too complex to do with ASIC or even with GPU pixel shaders. Encoding with modern complex codecs like AV1 is going to be CPU, and maybe FPGA.

How can something be too complex for ASIC? (And not for FPGA, which is essentially an ASIC you can program)

Holy cow, as soon as the extensions get support I'm going to be downloading everything both ways and testing. Hopefully AV1 broad release lives up to its promise.

Why not just download with youtube-dl?

[mzso]

Is there some hidden way on youtube to find AV1 encoded videos? (I vaguely remember that they used to have something for VP9 when it was deployed)

Anyways, did anyone find more videos on Youtube than the one posted before?

[Aleksoid1978]

Can you post the full cmake -G "MSYS Makefiles" etc. etc. log on pastebin as it appears on screen?
Or, better/more complete, the contents of <yourBuildDir>/CMakeFiles/CMakeError.log and CMakeOutput.log?

cmake output - https://pastebin.com/spXmNAJS

CMakeError.log - https://pastebin.com/aPnpqnGF

CMakeOutput.log - https://pastebin.com/JpnNx4Xm

P.S. i think some message test on russian and we can't see it in CMake logs :)

[Blue_MiSfit]

Why not just download with youtube-dl?

I think foxyshadis was referring to the availability of MSE decoders in the browsers.

[marcomsousa]

YES! Fix confirmed!

EDIT: and patch sent: https://bugs.chromium.org/p/aomedia/issues/detail?id=2145#c7

Yours two patch requests was merge in master (https://aomedia.googlesource.com/aom/+log/master), congrats.

[SmilingWolf]

cmake output - https://pastebin.com/spXmNAJS

CMakeError.log - https://pastebin.com/aPnpqnGF

CMakeOutput.log - https://pastebin.com/JpnNx4Xm

P.S. i think some message test on russian and we can't see it in CMake logs :)

It's the path :D

The "++" in "D:/Aleksoid/C++/Source/aom/" create an invalid regular expression that makes some of the cmake tests fail. The AVX2 one just happens to be the first file tested that triggers the problem.
Just rename the path to something like CPP and all the problems should go away

Yours two patch requests was merge in master (https://aomedia.googlesource.com/aom/+log/master), congrats.

Confirming that with these additions the master branch, as of commit 67645b8, compiles and works again with GCC 8.2 without adding any extra C/CXX option on the CMake command line.
Ping @LigH :)

EDIT:
New build, GCC 8.2 based, no extra C/CXX flags, 32/64bits, HBD/LDB, static libraries included (decoder+encoder, sorry Aleksoid1978 but this solution was simply faster than having 8 different build configs)
av1-1.0.0-566-g67645b8f5: https://mega.nz/#!BsxmTYyJ!dnoSK66ucCz8DciOrhbgJtgW6Mebh7QnZnFkEzEop08

Following the comments on issue 2147 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2147) I think I'll drop the CONFIG_LOWBITDEPTH=0 builds from now on
The CONFIG_LOWBITDEPTH=1 ones should work perfectly for 8/10/12 bits video and work faster for 8 bits on top, so no reason to keep the HBD-only builds around

[LigH]

Thanks, I noticed via aomedia mail notification. I assume wiiaboo will revert the MABS patch soon.

[GTPVHD]

https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS

AV1 beta testing on Youtube.

[Pushman]

It has very high bitrate now.
At time of writing, these transcodes are encoded at a very high bitrate for decoder performance testing.

[ChaosKing]

I can't play the "halo infinite trailer" video (720p) lagfree with mpv. It seems that is uses gpu decoding? bcs cpu is only at max 5%

[nevcairiel]

There is no GPU decoding for AV1 anywhere yet. But maybe the decoder has a bottleneck somewhere.

[sneaker_ger]

With mpv 2018-09-02 the 720p version of the halo trailer stutters here as well. I'm not sure it is related to shere AV1 decoding performance as LAV nightly (via MPC-HC) decodes completely smooth on i5-2500K with maybe 15% - 30% CPU. (Not that you have told us anything about your hardware ...)

[ChaosKing]

Ryzen 1700 @3.6ghz. gpu Rx480 8GB. I testet it in Chrome 70 now and it is very smooth.
I thought of gpu decoding bcs in the task manager you can see a "GPU 3d" if you show the gpu modules column when playing in mpv.

[mzso]

It has very high bitrate now.

AKA, decent bitrate. :)

Sadly, they play nowhere near smoothly on my R5 1600, even though 6/12 cores are utilized to around 30-40%.

[Gravitator]

AKA, decent bitrate. :)

Sadly, they play nowhere near smoothly on my R5 1600, even though 6/12 cores are utilized to around 30-40%.

Check how it will be with the disabled SMT/HT?

[clsid]

It seems to already use only the physical cores by default. So that won't have any effect.

[TD-Linux]

With mpv 2018-09-02 the 720p version of the halo trailer stutters here as well. I'm not sure it is related to shere AV1 decoding performance as LAV nightly (via MPC-HC) decodes completely smooth on i5-2500K with maybe 15% - 30% CPU. (Not that you have told us anything about your hardware ...)

ffmpeg bug, should be fixed in newer builds of mpv:+ffmpeg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/309c3a0e81be553626711912e90015c26f4b09ba

[Clare]

ffmpeg bug, should be fixed in newer builds of mpv:+ffmpeg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/309c3a0e81be553626711912e90015c26f4b09ba

Still dropping many frames in 1080p with this commit.
CPU usage is around 10-13%.

[Nintendo Maniac 64]

I just did some performance testing with the 1080p 30fps AV1 encode of the Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview (https://www.youtube.com/watch?v=_fAOe8oz8qM) video in MPC-HC v1.8.1 x64 with its built-in LAVfilters; I originally tried the Halo video but I found the X Games video to be much more demanding (but also much more motion-sick inducing, especially when playing at slower than real-time).

With my 4c/8t Nehalem Xeon x3470 I was only seeing ~25% CPU utilization at maximum even though I was unable to play back the video in real-time (it was somewhere between 16fps and 20fps). Mathematically that should mean that it's only using 2 threads, but disabling SMT and setting my BIOS to only enable 2 cores resulted in noticably worse performance, yet setting the BIOS to enable 3 cores without SMT resulted in the same 16-20fps performance I was originally seeing yet at only ~67% CPU utilization.

At least with the LAVfilters bundled with MPC-HC v1.8.1 x64, it would seem that the AV1 decoder can only utilize 3 cores and no SMT, yet even then the 2 less loaded cores are only hitting around half of their according core's available utilization.


And for reference, the 720p 30fps AV1 encode of that same video played back without a hitch on my Xeon - heck it left enough headroom that I could turn on a bunch of motion interpolation which greatly helped alleviate the motion sickness I got from watching the 1080p AV1 encode playback at sub-20fps frame rates (it's times like this that I thank the devs over at Nintendo for making F-Zero X and F-Zero GX native 60fps games).



Now I'm a bit out-of-the-loop, but I couldn't help but notice that YouTube-DL was using the .MP4 extension for AV1 downloads - is that in fact correct behavior? (and no, I don't mean AVC1, otherwise my PC would have been playing back the videos easy-peasy).

[SmilingWolf]

Now I'm a bit out-of-the-loop, but I couldn't help but notice that YouTube-DL was using the .MP4 extension for AV1 downloads - is that in fact correct behavior? (and no, I don't mean AVC1, otherwise my Xeon would have been playing back the videos easy-peasy).

I can only answer to this part: the ISO-BMFF bindings for AV1 have been finalized first (just a few days ago in fact), while the Matroska/WebM ones are still WIP

So MP4-only for the time being

Also:
GCC 8.2, static builds, 32/64bits, CONFIG_LOWBITDEPTH=1
av1-1.0.0-577-g8ae39302e: https://mega.nz/#!14REmAwB!AO8Sta2C3ok4LZYyH9N7QKeZHfdcaKVcSKPnnuyEOeI

[marcomsousa]

I just did some performance testing with the 1080p 30fps AV1 encode of the Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview (https://www.youtube.com/watch?v=_fAOe8oz8qM) video in MPC-HC v1.8.1 x64 with its built-in LAVfilters

I was able to play 1080p with MPC-HC v1.8.1 x64 in real time, with some hitches in middle part of the video.
CPU at 62%
Intel Core i7-8550U (Kaby Lake-R U4+2)

With ffplay.exe 20180912 I play this 1080p video, realy realy slow, but play well the 720p video.


Now I'm a bit out-of-the-loop, but I couldn't help but notice that YouTube-DL was using the .MP4 extension for AV1 downloads - is that in fact correct behavior?
It's correct, since webm support for av1 isn't finalized. Also youtube-dl download what youtube give, and Youtube have av1 in mp4 container with mp4 schema (av01.0.05M.08).

[SmilingWolf]

With ffplay.exe 20180912 I play this 1080p video, realy realy slow, but play well the 720p video.

ffplay 20180912 is, for whatever reason, a very poor version to test with. Don't know if it depends on the aom library revision used, on the ffmpeg revision, or something in the middle, but on my system it performs at half the perf on my own minimal ffmpeg+aom build

CPU: Intel i7-4770 @ 3.4 GHz

Zeranoe build:
# ffmpeg -threads 4 -i "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4" -benchmark -f null -
ffmpeg version N-91931-gb69ea742ab Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180813
[libaom-av1 @ 0000000000485ac0] 1.0.0-507-g5d963cb57
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4':
frame= 1736 fps= 18 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=0.602x
video:909kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=95.473s stime=0.187s rtime=96.195s
bench: maxrss=234036kB

My own:
# ./ffmpeg -threads 4 -i "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4" -benchmark -f null -
ffmpeg version N-91943-g1b98bfb932 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180913
[libaom-av1 @ 0000000000338500] 1.0.0-577-g8ae39302e
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4':
frame= 1736 fps= 37 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=1.24x
video:909kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=98.234s stime=1.076s rtime=46.544s
bench: maxrss=272452kB

[Mr_Khyron]

http://download.opencontent.netflix.com/?prefix=AV1/
************** Netflix AV1 Encodes Readme **************************************

This is the readme for the Netflix AV1 Encodes.

The assets covered in this readme can be browsed on the Netflix OpenContent
bucket here:
http://download.opencontent.netflix.com/?prefix=AV1/

Each asset has its license posted to its main directory in the file license.txt.

********** Downloading with AWS CLI ********************************************

You can download single files directly through your web browser on the
OpenContent page, but for large files and long frame sequence, you may wish to
use command line tools such as aws cli.
Detailled instructions are posted here:
http://download.opencontent.netflix.com.s3.amazonaws.com/TechblogAssets/README.txt

********** Encoding and Packaging **********************************************

The IVF files were produced using AOM aomenc (Libaom v1.0) using 2-pass, CQP,
tiles on higher resolutions, and Film Grain. Additionally, the following
parameters were used for all encodes:
--passes=2 --fpf=twopassStats --i420 --profile=0 --arnr-maxframes=7
--arnr-strength=5 --lag-in-frames=25 --aq-mode=0 --bias-pct=100
--minsection-pct=1 --maxsection-pct=10000 --end-usage=q --min-q=0 --max-q=63
--input-bit-depth=[8|10] --cpu-used=1 --auto-alt-ref=1 --max-gf-interval=12
--min-gf-interval=[4|5|6] --frame-parallel=0 --threads=8
--tile-columns=[1|2|4] --ivf

The IVF files were then packaged into (non-fragmented and non-encrypted) MP4
files conforming to https://aomediacodec.github.io/av1-isobmff/using
GPAC's MP4Box (GPAC version 0.7.2-DEV-rev654-gb6f7409ce-master) as follows:

MP4Box -add input.ivf output.mp4

********************************************************************************

Last updated: 2018 Sept 4
Copyright NETFLIX INC.
100 Winchester Circle, Los Gatos, CA 95032, USA
:)

[sneaker_ger]

Screenshots 8 vs 10 bit (8 bit has 40% more bitrate):
Netflix Chimera 8 bit (https://abload.de/img/chimera-av1-8bitipemd.png)
Netflix Chimera 10 bit (https://abload.de/img/chimera-av1-10bitreea9.png)

Is this an inherent problem of AV1 8 bit or just because it isn't very tuned yet (bitrate allocation, aq, psy)? Though 10 bit encode also has some problems, those "boxes" on the power lines between the two skyscrapers on the left go missing. Then again 10 bit was given much lower bitrate here ..

[MoSal]

ffmpeg bug, should be fixed in newer builds of mpv:+ffmpeg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/309c3a0e81be553626711912e90015c26f4b09ba

That's not the (only) issue. Note the decoding bottleneck in this sample (https://archive.org/download/unsorted_files/halo_av1.mkv) five seconds in, at the scene change.

[marcomsousa]

Zeranoe build:
libaom-av1 @ 0000000000485ac0] 1.0.0-507-g5d963cb57
My own:
[libaom-av1 @ 0000000000338500] 1.0.0-577-g8ae39302e
ffmpeg/Zeranoe build don't have the 70 optimization commits that you have in libaom-av1.

ffmpeg-20180913-1b98bfb-win64

ffmpeg -threads 4 -i 1080.mp4 -benchmark -f null -
ffmpeg version N-91943-g1b98bfb932 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180813
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil 56. 19.101 / 56. 19.101
libavcodec 58. 30.100 / 58. 30.100
libavformat 58. 18.100 / 58. 18.100
libavdevice 58. 4.103 / 58. 4.103
libavfilter 7. 31.100 / 7. 31.100
libswscale 5. 2.100 / 5. 2.100
libswresample 3. 2.100 / 3. 2.100
libpostproc 55. 2.100 / 55. 2.100
[libaom-av1 @ 000001e19c898940] 1.0.0-507-g5d963cb57
Stream mapping:
Stream #0:0 -> #0:0 (av1 (libaom-av1) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
major_brand : dash
minor_version : 0
compatible_brands: iso6av01mp41
encoder : Lavf58.18.100
Stream #0:0(und): Video: wrapped_avframe, yuv420p, 1920x1080, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
Metadata:
creation_time : 2018-09-12T19:11:12.000000Z
handler_name : ISO Media file produced by Google Inc. Created on: 09/12/2018.
encoder : Lavc58.30.100 wrapped_avframe
frame= 1736 fps= 19 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=0.637x
video:909kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=88.703s stime=0.938s rtime=90.919s
bench: maxrss=233580kB

[SmilingWolf]

Sure, which was one of the options considered in my post. The 20180913 build with the current ffmpeg HEAD (91943-g1b98bfb932) wasn't out when I tested, so I couldn't be sure.
Still, to double performance in just about 8 days (Zeranoe aom revision: 20180906-5d963cb) is really a LOT, especially considering a lot of the commits are either bugfixes or encoding-related.

Turns out the commit that really made the difference is f820da0 - Turn on the row-based multi-thread decoder by default (https://aomedia.googlesource.com/aom/+/f820da02be8caa59c3e1c372cca048ac296ca5fb).

# time ./aomdec.850e126ac.exe --threads=4 -o /dev/null "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.ivf"

real 1m0,929s
user 0m0,000s
sys 0m0,000s

# time ./aomdec.f820da02b.exe --threads=4 -o /dev/null "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.ivf"

real 0m37,947s
user 0m0,000s
sys 0m0,000s

[LigH]

New uploads:

AOM v1.0.0-577-g8ae39302e noVO (https://www.mediafire.com/file/odgwmafp1dp6n4i/aom_v1.0.0-577-g8ae39302e_noVO.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0 with -fno-tree-slp-vectorize)
AOM v1.0.0-577-g8ae39302e (https://www.mediafire.com/file/i8lcorwl2c5x7oq/aom_v1.0.0-577-g8ae39302e.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0) – no crash in 2-pass for me

rav1e 0.1.0 (1fa32bb / 2018-09-14) (https://www.mediafire.com/file/944vj5j3j495329/rav1e_0.1.0_2018-09-14_1fa32bb.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

[birdie]

AV1 in MP4 has been standardized: https://cdn.rawgit.com/AOMediaCodec/av1-isobmff/v1.0.0/index.html

[Tommy Carrot]

Thanks Ligh and Smilingwolf for the builds. For some reason, Smilingwolf's build is considerably faster (finished the same encode in 40 minutes vs 67). I used your unpatched build, Ligh, and 64 bit versions. I don't know if this happens because of difference in the compiler settings, or because Smilingwolf sets CONFIG_LOWBITDEPTH=1. The outputs are identical.

[Nintendo Maniac 64]

It's correct, since webm support for av1 isn't finalized. Also youtube-dl download what youtube give, and Youtube have av1 in mp4 container with mp4 schema (av01.0.05M.08).

Again, kind of out-of-the-loop, but since AV1 will support MP4 and WebM unlike VP8/9, one has to wonder which container would be "better?"

(I would imagine that AV1 in MP4 would have better compatibility on Apple devices in the future, but I wasn't really concerned about the difference in support as so much if either of the MP4 or WebM containers are objectively "better" on a technological level than the other).

[mzso]

Again, kind of out-of-the-loop, but since AV1 will support MP4 and WebM unlike VP8/9, one has to wonder which container would be "better?"

(I would imagine that AV1 in MP4 would have better compatibility on Apple devices in the future, but I wasn't really concerned about the difference in support as so much if either of the MP4 or WebM containers are objectively "better" on a technological level than the other).

I don't think that mp4 store opus/vorbis for one. Probably the most efficient lossy audio codecs.

[Nintendo Maniac 64]

CPU at 62%
Intel Core i7-8550U

Interesting how both of our CPUs have the exact same 4c/8t configuration, yet you're seeing more than 2x the CPU utilization than I am...


Mathmatically that would mean that you're utilizing at least 5 threads, which would equal out to being something like 4 cores and 1 SMT thread.

I do know that that my Nehalem predates AVX and that newer CPUs also have stronger SMT (this is particularly true with Zen cores), so I've got to wonder if something between those two variables is resulting in AV1 utilizing multiple threads much better on your Kabylake i7 than it does on my Nehalem Xeon.

I mean, I know that Sky/Kaby/Coffee lake will have anywhere from 30% to 50% higher single core IPC than Nehalem, but I wouldn't think that would account for any difference in how many cores are being utilized at any given time (outside of SMT threads being used, but I'm not even seeing any utilization on my fourth hardware core let alone SMT).

[sneaker_ger]

I don't think that mp4 store opus/vorbis for one.
http://opus-codec.org/docs/opus_in_isobmff.html

[mzso]

http://opus-codec.org/docs/opus_in_isobmff.html

Version 0.6.8 (incomplete)

last updated: April 28, 2016

So, not done yet. If it'll ever be.