Alliance for Open Media codecs

[hajj_3]

Originally Posted by IgorC

???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

xHE-AAC was added to the DRM+ digital radio standard which india is rolling out. It may still become popular in the future if DRM+ becomes popular.

I can't see it becoming popular online due to the patent costs especially as Opus 1.3 has improved lower bitrates recently and will continue to improve.

[foxyshadis]

Originally Posted by marcomsousa

Can doom9 promote AV1 and give an sub-forum like for HEVC?

So we can have more specialized posts:

• News
• Software adoptions
• HW decode compatible
• HW encode compatible
• Tune with parametres (libaom-av1)
• Tune with parametres (ffmpeg)
• Tune with parametres (others)
• 10bit and 12bit
• Quality compare
• Performance compare
• Custom Builds
• Containers
• Etc...

As much as I'm hoping AV1 sets the world on fire, especially once it's released from Google's "performance? who needs optimization when you have the world's largest server farm?" attitude, Doom9 is about interest more than promotion. So far there just aren't that many posts about AV1; compare the HEVC forum. Some of those threads are obvious duplicates or way too niche, but if you want to go ahead and found a dedicated AV1 tuning or comparison thread, go ahead.

News goes in the news forum, naturally.

[hydra3333]

Originally Posted by foxyshadis

So far there just aren't that many posts about AV1; compare the HEVC forum.

OK. Possibly only for now, though ? A novice like me and perhaps most punters may have reasonably inferred that with google and so many (almost all ?) large industry players signed up and behind it that it is likely to receive growing attention. Just a thought.

[IgorC]

Sorry for offtopic. Last one and probably will get it somewhere else.

Originally Posted by iwod

Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.

It's difficult to say. I'm not a lawyer. I just saw some patent related estimations here http://www.ecodis.de/audio.htm
Especially when laws change per country. Also there are decoding and encoding related patents. MP3 decoding related patents have expried in 2015 but encoder patents in 2017. https://www.cs.helsinki.fi/group/pak...docs/legal.pdf

It might be the case that patents of LC-AAC have already expired.
Will investigate.

[Nintendo Maniac 64]

Originally Posted by marcomsousa

The new ffmpeg builds with a newer libaom-av1 improves performance a lot (like SmilingWolf said)

MPC-HC v1.8.2 also got released - could you perhaps confirm/deny whether its built-in LAVfilters also contain these performance improvements?

Thing is, I saw no performance gains when using 1.8.2 vs 1.8.1, so I need to confirm/deny whether my performance issue is persisting or whatnot.


I did however notice that, out of the three cores being utilized on my Xeon x3470, one of them is pretty much fully pegged and the other two are about half utilization - this would then equal the ~25% utilization I'm seeing.

Now normally I would let this all go as simply a case of "not having fast enough single-threaded performance" and be done with it, but the fact that you and others were seeing over 60% utilization on your own 4c/8t CPUs (which implies it was balancing the load across more than 4 threads) makes me thing something still isn't quite right here - I mean, weaker single-threaded performance shouldn't result in fewer threads being utilized, and if anything you'd want it to be the opposite, no?

[lvqcl]

I downloaded aom-master.tar.gz (that is, the latest sources), recompiled libaom amd ffmpeg libs myself, and I cannot see speed increase over vanilla LAVFilters-0.72.0-13.

Also: according to LAVFilters sources, it uses AV1 library v1.0.0-552-gbb82e05fb which does have that "row-based multi-thread decoding" patch.

[Selur]

Got a few additional questions about aomenc, since I couldn't find any doc about it.

• Does anyone know where I can lookup the default values for all the options where the help doesn't provide a default value?
• What are the allowed values for '--usage' and '--profile'?
• What is the difference between 'Usage' and 'Bitstream' profile?
• What are the 'forced_max_frame_width' and 'forced_max_frame_height' values for? Does the force to encoder to internally not downscale width/height?
• What is the recommend value for '--timebase' and when should one change this value?
• What is the 'resize-mode'-option for and what are valid values for it?
• What are the 'superres' options for?
• What are S-frames and what are the sframe-modes?
• What does the 'input-chroma-subsampling' options for and what are valid values for them?

Thanks for anyone who help with some answers.

Cu Selur

[SmilingWolf]

Originally Posted by Selur

Got a few additional questions about aomenc, since I couldn't find any doc about it.

• Does anyone know where I can lookup the default values for all the options where the help doesn't provide a default value?

You can check some defaults here: https://aomedia.googlesource.com/aom...eed_features.c
Not the most user friendly way but that's all there is for now unfortunately

As for the other questions, my best guess is that they are described one way or the other in the spec.
Or in the sources... somewhere. Yeah not quite the best for end users.

[easyfab]

encoding default :
https://aomedia.googlesource.com/aom...cx_iface.c#107

[Selur]

Thanks!
about s-frames (switching frames): https://www.youtube.com/watch?v=o5sJX6VA34o seems to be only interesting for abr low latency live streaming, so not interesting when you don't have multiple streams of different bitrates available.

[Blue_MiSfit]

Very cool. I should go to Demuxed this year!

[lvqcl]

Found this comment in libaom code:

// TODO(hkuang): Fix the pthread_cond_broadcast in windows wrapper.

Apparently it was made in this commit for vp9. I wonder is it still true?

(Also, libaom phtreads wrapper has a lot of code for pre-Vista Windows. Why? Nobody bothered to clean it up? )

[LigH]

The last issue (unaligned memory access in GCC 8.2.0) was marginally related to cleaning up VP9 remains...

[marcomsousa]

I have diferent Coding path when encoding with differents aom builds with the same y4m.

Coding path: LBD
Coding path: HBD

Can't you explain why and how to change this?

[SmilingWolf]

My builds come with the CONFIG_LOWBITDEPTH build option enabled.
It enables 8bit content optimized codepaths, which work roughly 2x (in theory) - 1.75x (in practice) faster than the high (10-12) bit depth codepaths because you can stuff 8 bits in just 8 bits of memory, while to use 10-12bits you need to use 16 bits of memory, halving the throughput.
The default of that build options is 0, which means the 8bits codepaths are never used, and a lot of builds out there just use default settings (MABS ones in primis).

Lotsa yadda yadda on my part, issues 2062 and 2147 probably explain better what this means for end users

Side note: today's build are complete, few minutes they'll be up on MEGA.
There's a little feature I've been keen to try for a long time now: loop filter bitmask for decoding, which promises a 6% decoding performance increase in single thread

[LigH]

I will mention this in the MABS project, maybe wiiaboo agrees to enable it (or even make a choice to build either or both, like for x264 and x265, unless that are able to provide a multilib solution as well).

[SmilingWolf]

I think there's no need for CONFIG_LOWBITDEPTH=0 builds, with CONFIG_LOWBITDEPTH=1 the appropriate codepaths are selected automatically based on input and output bit depths.

Today's build:
av1-1.0.0-629-g7b9ddd4bf: https://mega.nz/#!cg5njRjA!WZkuEg2g7...vEcCgQL5_vRMY8

Cautionary note: the issues tracker has been populating quite fast the last couple of days, so there's a chance this is not the most stable build to work with.
I have just finished a series of encodes that took all week , so I'll be able to try it and report back if anything nasty happens.
Also, some coding features have been temporarily disabled for row-mt to accomodate some corner cases

Silver lining: the code is being modified to enable easier debugging of threading related issues, so maybe we'll see some newfound stability on that front in the coming days/weeks

[marcomsousa]

I'm building (yet another version) AOM with Visual Studio 2017 from sources.

They are automatically builds

AV1 executable builds: here
I also open source the build scripts at Github: here

I note that with VS2017 generates a lot of *.exe compare with gcc

• aomdec.exe
• decode_with_drops.exe
• decode_to_md5.exe
• twopass_encoder.exe
• dump_obu.exe
• lightfield_decoder.exe
• lightfield_bitstream_parsing.exe
• lightfield_encoder.exe
• aom_cx_set_ref.exe
• lightfield_tile_list_decoder.exe
• aomenc.exe
• lossless_encoder.exe
• noise_model.exe
• scalable_decoder.exe
• resize_util.exe
• scalable_encoder.exe
• set_maps.exe
• simple_encoder.exe
• simple_decoder.exe

At this moment I'm only saving aomenc.exe and aomdec.exe.
You can do pull requests to improve this script.

[SmilingWolf]

All of that EXEs are generated under MSYS2 too, they are simply not installed by "make install" because they are examples or test tools, not meant for the end user.

# find . -name \*.exe -type f
./aomdec.exe
./aomenc.exe
./CMakeFiles/3.12.1/CompilerIdC/a.exe
./CMakeFiles/3.12.1/CompilerIdCXX/a.exe
./examples/aom_cx_set_ref.exe
./examples/decode_to_md5.exe
./examples/decode_with_drops.exe
./examples/lightfield_bitstream_parsing.exe
./examples/lightfield_decoder.exe
./examples/lightfield_encoder.exe
./examples/lightfield_tile_list_decoder.exe
./examples/lossless_encoder.exe
./examples/noise_model.exe
./examples/scalable_decoder.exe
./examples/scalable_encoder.exe
./examples/set_maps.exe
./examples/simple_decoder.exe
./examples/simple_encoder.exe
./examples/twopass_encoder.exe
./resize_util.exe
./tools/dump_obu.exe

Love the AppVeyor integration! Thanks!

[LigH]

Just chatted a bit in IRC ... gnafu believes that CONFIG_LOWBITDEPTH=1 is a) still necessary to be set at compile time, b) in general useful, because it enables an optimized code path for 8 bit precision only, but does not alter the behaviour of higher bit depths.

I hope he is right.