Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > VP9 and AV1

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th June 2018, 11:26   #721  |  Link
wiak
Registered User
 
Join Date: Jul 2003
Location: somewhere north
Posts: 260
Quote:
Originally Posted by MoSal View Post
I tested a cheap locally-assembled TV with Chinese parts the other day. VP9 4K@60fps is supported out of the box. Opus was the codec that's not supported.

No one will forget AV1, not even the no name chip manufacturers. Here is hope, from now on, they will not forget Opus either.
LG OLED telly dont support opus either sooo heh
__________________
Woah! Ninja?! http://nwgat.ninja/ (AV1 Overview)
"Not available in your region" has now been redefined as "Go Pirate, you filthy scum" Nwgat
wiak is offline   Reply With Quote
Old 27th June 2018, 11:34   #722  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
Due to general interest:

My AOM builds are a result of jb-alvarado's media-autobuild_suite, which has building ffmpeg as main purpose, but also offers several more features.

During the configuration, among several other options, I enabled building of separate executables (not only libraries used in ffmpeg), and building of AOM.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 27th June 2018, 17:18   #723  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
I've done a few tests with the 1.0 build (thanks Ligh!). I've compared it to the 0.1.0-9043 build from april, i mainly tested --cpu-used 0 to 2, because above that the quality isn't really better than current gen codecs, while it's still horrendously slow. Overally the encoding speed is improved to around twice as fast in each speed settings, while the quality is very similar (both filesize and metrics). In some cases there are definite visual improvements, but in most cases it has more or less the same quality.

This encoder still needs a lot of work, it's still too slow even for short tests, not to mention everyday use. The quality is fairly impressive, definitely better than x265 or VP9, but IMO it falls short to XVC and VVC.
Tommy Carrot is offline   Reply With Quote
Old 27th June 2018, 18:51   #724  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally Posted by Tommy Carrot View Post
I've done a few tests with the 1.0 build (thanks Ligh!). I've compared it to the 0.1.0-9043 build from april, i mainly tested --cpu-used 0 to 2, because above that the quality isn't really better than current gen codecs, while it's still horrendously slow. Overally the encoding speed is improved to around twice as fast in each speed settings, while the quality is very similar (both filesize and metrics). In some cases there are definite visual improvements, but in most cases it has more or less the same quality.

This encoder still needs a lot of work, it's still too slow even for short tests, not to mention everyday use. The quality is fairly impressive, definitely better than x265 or VP9, but IMO it falls short to XVC and VVC.
Are there VVC encoder already? Or are you implying XVC?
iwod is offline   Reply With Quote
Old 27th June 2018, 18:55   #725  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
Quote:
Originally Posted by iwod View Post
Are there VVC encoder already? Or are you implying XVC?
Well, the jvet encoder posted in the vvc thread. It should be more or less the same, just an earlier version.
Tommy Carrot is offline   Reply With Quote
Old 27th June 2018, 20:41   #726  |  Link
blurred
Registered User
 
Join Date: Jul 2016
Posts: 14
Response by author of the benchmark from https://encode.ru/threads/1890-Bench...ll=1#post57093
Quote:
Quote:
Firstly, the AV1 range coder only uses 1 multiplication per CDF entry, the 16 is the "worst case" (keep in mind that they can be done in parallel, e.g. with SIMD, so it's actually better to use more than less as the multiply is the cheapest part in software).
For SSE2 decoding in AV1 you need 4 SIMD multiplications (_mm_mullo_epi32) + 4 comparisons (_mm_cmpgt_epi32) + combining (after _mm_movemask_ps) 4 SSE2 registers
It is unlikely that this will be faster than scalar decoding.
For AV1 hardware implementations, you need 16 32x32 multipliers, otherwise parallel multiplications are not possible.
Also 16 comparisons + other operations are additionaly required.
Quote:
Secondly, the difference is nowhere near 7x when we benchnmarked the two - rANS was faster, but by a factor of about 2.
For this benchmark and current implementations, rANS decoding is SEVEN times faster than AV1.
On ARM the scalar version is 5 times faster.
The AV1 nibble entropy coder is even slower than a bitwise range coder.
Quote:
However, the requirement to buffer and reverse the symbols was unfortunately insurmountable.
This is only required in encoding which is usually done in software.
This irrelevant argument is always used in their discussions.
The benchmark shows that TurboANXN, even with reverse encoding is more than 4 times faster than the current AOMedia AV1 encoder.
Quote:
Also keep in mind that AV1 adjusts the probabilities on a per-symbol basis.
The entropy coder CDFs are designed to make adapting the probabilities very fast (with only adds and shifts).
This puts some constraints on the design that don't exist in the linked benchmark (which uses fixed probabilities as far as I can tell).
The benchmark is using adaptive probabilities.
Quote:
There is so much clever that gets done, even in decoders.
And there are so many different kinds of parallelization, SIMD, ASIC, etcetera available.
And surprising numbers of decoders don't implement basic stuff like skipping non-reference frames when doing seeking, due to the system layer and the decoder layers not being tightly coupled enough.
This is indepedant from entropy coding. Here we are comparing the AV1 entropy coder against rANS and they are interchangeable.
Quote:
Also rANS is quite recent and higthly optimised, plus it uses 32/64bit aritmetic and SIMD instructions while daala range coder uses only 16bit aritmethic.
And you can do betwen 2 and 4 1 clock 16bit multipliers in the same number of gates that of a 32bit 1 clock multiplier.
According to the AV1 source code, 32 bits operations are used. rANS is 32 bits only.

I think the decision against rANS is politically motivated (Not-invented-here-Syndrom).
Otherwise, why not simply let the (now removed) rANS version in the repository for comparisons.
Hardware comparisons (complexity,energie consumption,costs,...) are only possible after implementing both optimized versions.

Note, we are considering here only adapative rANS. Do not confuse this with block based ANS as used in zstd,lzfse, lzturbo...
blurred is offline   Reply With Quote
Old 28th June 2018, 18:22   #727  |  Link
Phanton_13
Registered User
 
Join Date: May 2002
Posts: 95
Quote:
Originally Posted by blurred View Post
Response by author of the benchmark...
According to the AV1 source code, 32 bits operations are used. rANS is 32 bits only.
They are actually doing 16 arithmetic using 32 bit operations due that modern processor are faster unsing 32 bits operations that using 16bit operations, also varios presentations and documents indicates that dala range coder uses 15x16-> 31bit multiplications.


Quote:
Originally Posted by blurred View Post
I think the decision against rANS is politically motivated (Not-invented-here-Syndrom).
Otherwise, why not simply let the (now removed) rANS version in the repository for comparisons.
The political motivation can also be viewed in the reverse and if it was included tell that it was for political reasons... An inventor of something can always and most of the time tell that the reason that other don't use it is political motivated. Other times something cam be included to make someone happy (this have hapened in hevc and x264).

Also the patent situation, not only by google but also by others that do the same dirts it's posibility of inclusion.

For me instead of whine for it not being included the correct is to continue perfecting for it to be included in AV2.

Last edited by Phanton_13; 28th June 2018 at 18:40.
Phanton_13 is offline   Reply With Quote
Old 29th June 2018, 06:06   #728  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,556
Quote:
Originally Posted by blurred View Post
Response by author of the benchmark from https://encode.ru/threads/1890-Bench...ll=1#post57093
Quote:
For SSE2 decoding in AV1 you need ....
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.
foxyshadis is offline   Reply With Quote
Old 29th June 2018, 08:40   #729  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
AV1 development is becoming disappointing. With the promise of a February delivery for the final bitstream format I expected youtube providing AV1 streams by now. (At least for new/popular videos)
mzso is offline   Reply With Quote
Old 29th June 2018, 14:05   #730  |  Link
wiak
Registered User
 
Join Date: Jul 2003
Location: somewhere north
Posts: 260
Quote:
Originally Posted by mzso View Post
AV1 development is becoming disappointing. With the promise of a February delivery for the final bitstream format I expected youtube providing AV1 streams by now. (At least for new/popular videos)
they shot them self in the foot during NAB, when they so called released the codec

but currently most tools with not encode, case in point ffmpeg has strict mode on and dont even do webm, aomenc does webm, the encoding and decoding parts are to slow to be ustable even on a modern ryzen 8-core

atleast with 1.0.x series we can finally decode stuff encoded in older builds

still useless for anything other than thinkering

and this is from a user perspective

a proper roadmap with set dates on when stuff is getting implemented like faster encoding, multi-threading, browser support?

am convinced that aomedia runs on valve time https://developer.valvesoftware.com/wiki/Valve_Time

anyway, will check back in 3 months time, pace out (but i guess they are still more than a year off)
__________________
Woah! Ninja?! http://nwgat.ninja/ (AV1 Overview)
"Not available in your region" has now been redefined as "Go Pirate, you filthy scum" Nwgat
wiak is offline   Reply With Quote
Old 29th June 2018, 14:59   #731  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,336
Quote:
Originally Posted by wiak View Post
but currently most tools with not encode, case in point ffmpeg has strict mode on and dont even do webm, aomenc does webm
The container bindings are not finalized yet, which is why tools don't really create those yet. But both MP4 and MKV/WebM bindings are being worked on right now, and once those are final, expect at least FFmpeg to pick them up too.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 30th June 2018, 01:30   #732  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 94
Quote:
Originally Posted by wiak View Post
the encoding and decoding parts are too slow to be usable even on a modern ryzen 8-core
No kidding. I tested with --cpu-used=8 --tile-columns=4 expecting acceptable speed and awful quality.

The opposite turned out to be true. The speed is still slow. And the quality wasn't bad. It wasn't very good either, but still beets a tuned x265-slower profile with the specific sample I tested (1Mbps / 1080p / 30fps).

Code:
aomenc -o t.webm t.y4m -t 4 --target-bitrate=256 --enable-qm=1 \
--aq-mode=1 --film-grain-test=1 --cpu-used=8 --tile-columns=4
Code:
ffmpeg -i t.y4m -c hevc -crf 38 -preset slower -x265-params \
sao=0:deblock=-2,-2:psy-rdoq=5:qcomp=.75:ipratio=1.25:pbratio=1.18 t.mkv
The quality of --film-grain-test=1 is impressive. Better than no test, but --film-grain-test=2 adds too much grain.

On the decoding side. ffav1 should be available soon-ish.
__________________
saldl: a command-line downloader optimized for speed and early preview.

Last edited by MoSal; 30th June 2018 at 04:47.
MoSal is offline   Reply With Quote
Old 5th July 2018, 15:38   #733  |  Link
paul97
Registered User
 
Join Date: Mar 2018
Posts: 10
Has AOMedia already started optimizing AV1 (especially its speed) after the bitstream freezed on the 25th of June?
paul97 is offline   Reply With Quote
Old 5th July 2018, 18:06   #734  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally Posted by paul97 View Post
Has AOMedia already started optimizing AV1 (especially its speed) after the bitstream freezed on the 25th of June?
Well you can be assured they have plans. But it will take time, counted in months, not days or weeks.
iwod is offline   Reply With Quote
Old 5th July 2018, 22:07   #735  |  Link
Mjpeg
Registered User
 
Join Date: Jun 2018
Posts: 7
Article: Constrained Directional Enhancement Filter

Great Chris Montgomery article on CDEF

https://hacks.mozilla.org/2018/06/av...cement-filter/

I'm thrilled to see a royalty-free option here, so I'll try to be patient as they speed up the encoder.
Mjpeg is offline   Reply With Quote
Old 6th July 2018, 00:04   #736  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
Quote:
Originally Posted by Phanton_13 View Post
They are actually doing 16 arithmetic using 32 bit operations due that modern processor are faster unsing 32 bits operations that using 16bit operations, also varios presentations and documents indicates that dala range coder uses 15x16-> 31bit multiplications.
Since those slides were made, they shrank even further - they are only 7x9 multiplications. Lower latency for this multiply was critical for hardware throughput, so we shrank it as much as we could without significant compression losses. See https://aomedia.googlesource.com/aom...p/entdec.c#199

Quote:
Has AOMedia already started optimizing AV1 (especially its speed) after the bitstream freezed on the 25th of June?
Yup! You can always follow the latest development of libaom on Gerrit. Here's the most recent merged changes: https://aomedia-review.googlesource.com/q/status:merged
TD-Linux is offline   Reply With Quote
Old 6th July 2018, 00:19   #737  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 94
Had some time to do some tests with --cpu-used=4 and no tiles.

As the bitrate goes up, libaom continues to be superior compared to tuned x265 when it comes to I frames. For non-I frames, the story is different. Tuned x265 (see my previous comment) non-I frames look superior to libaom P frames which look terrible. Even when I give more bitrate to P frames (--max-intra-rate=700), they continue to look terrible.

The flexibility in the API and CLI options is quite lacking. The documentation is not great either (I had to check the source code to know what to pass to some options).

Again, this is with --cpu-used=4 which is probably analogous to veryfast in x264/x265. And it is needless to say that none of this is due to inherent limitations in the codec itself.
__________________
saldl: a command-line downloader optimized for speed and early preview.
MoSal is offline   Reply With Quote
Old 7th July 2018, 08:08   #738  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
Quote:
Originally Posted by Mjpeg View Post
Great Chris Montgomery article on CDEF

https://hacks.mozilla.org/2018/06/av...cement-filter/
Interesting tidbit from Monty in the comments, sounds like Mozilla is working on its own AV1 encoder.

"That’s much more to do with the way the encoder is tuned, and you’re seeing VPx’s traditional tuning biases here. The VP encoders have always been rather merciless to mid-frequency content, and I think the current AOM encoder isn’t yet using any sort of activity masking.

Compare AV1 to Daala on those images; the substantial difference there is difference in encoder tuning philosophy. We’ll be bringing that to the encoder we’re working on here at Moz."
dapperdan is offline   Reply With Quote
Old 7th July 2018, 08:45   #739  |  Link
Quikee
Registered User
 
Join Date: Jan 2006
Posts: 41
Quote:
Originally Posted by dapperdan View Post
Interesting tidbit from Monty in the comments, sounds like Mozilla is working on its own AV1 encoder.
Yup - rav1e - https://github.com/xiph/rav1e
Quikee is offline   Reply With Quote
Old 7th July 2018, 22:15   #740  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
https://www.bbc.co.uk/rd/blog/2018-0...eg-and-aomedia
hajj_3 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:39.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.