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 12th February 2019, 00:24   #1461  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
Quote:
Originally Posted by Nintendo Maniac 64 View Post
So um, as someone on the outside, I've got to ask - outside of DRM and satisfying "not invented here" syndrome, what benefit does xHE-AAC provide over something like Opus?
Both Opus and xHE-AAC are hybrid music/speech formats and have essentially same quality. xHE-AAC is slightly better than Opus at 16-32 kbps, quality at 48-64 kbps is the same for both and Opus is slightly better than all family LC-AAC/HE-AAC/xHE-AAC at higher bitrates.

Many people try to market a feature of xHE-AAC as switching between bitrates as something outstanding and so on. But in reality it's not a premium feature and Opus supports it from the very beginning. More here https://wiki.hydrogenaud.io/index.php?title=Opus

Also xHE-AAC is a high delay codec and it's not suitable for real time communications like VOIP calls etc. Company who wants real time communication should also adopt low-delay xHE-AAC fork (EVS). And if You want stereo EVS then this is just another extension. So we got mutltiple codecs and/or extensions:
1.xHE-AAC
2.low delay EVS
3.EVS stereo extension (aka IVAS)
...
It's sort of LC-AAC, HE-AAC, HE-AACv2, Low delay AAC (LD-AAC), Enhanced LD-AAC ( low delay HE-AAC) aka ELD-AAC, ELD-AAC v2 (HE-AACv2 low delay), xHE-AAC, EVS ( low delay xHE-AAC), IVAS (low delay stereo xHE-AAC)...

While Opus is just one single format for everything: high-,low-delay, stereo and multichannel codec.
So I'm not surprised that Opus is popular in internet community while xHE-AAC support is non-existent. Android 9 will get an xHE-AAC decoder but there is still no any encoder

Last edited by IgorC; 12th February 2019 at 00:43.
IgorC is offline   Reply With Quote
Old 12th February 2019, 00:58   #1462  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
Quote:
Originally Posted by Blue_MiSfit View Post
Maybe viewing through the ultra low bitrate lens, has anyone done very low bitrate 2 pass VBR tests with AV1? I'd be interested to see how that might fit into the above scenario regarding downloading content for offline playback.
Very low bitrate is definitely the strong point of AV1 (more precisely aomenc). At around crf 28-30 compression rates, it's starting to get better than x265, and the lower the bitrate, the bigger the advantage. XVC, and especially VVC are still better though, the VVC reference encoder is seriously amazing at ultra low bitrate scenarios.
Tommy Carrot is offline   Reply With Quote
Old 12th February 2019, 01:21   #1463  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Tommy Carrot View Post
Very low bitrate is definitely the strong point of AV1 (more precisely aomenc). At around crf 28-30 compression rates, it's starting to get better than x265, and the lower the bitrate, the bigger the advantage. XVC, and especially VVC are still better though, the VVC reference encoder is seriously amazing at ultra low bitrate scenarios.
Ooh, do you have any examples or command lines for the >x265 for very low bitrates? Low bitrate, low resolution video enables MUCH faster encode/evaluate/reencode cycles and would be a great place to evaluate AV1's potential strengths.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 12th February 2019, 01:41   #1464  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
Quote:
Originally Posted by benwaggoner View Post
Ooh, do you have any examples or command lines for the >x265 for very low bitrates? Low bitrate, low resolution video enables MUCH faster encode/evaluate/reencode cycles and would be a great place to evaluate AV1's potential strengths.
Nothing special, i pretty much use the default settings.
Code:
aomenc --end-usage=q --cq-level=xx --cpu-used=1 --kf-max-dist=250 -v -o av1.webm test.y4m
I haven't tried 2-pass bitrate mode though, only CQ mode with using the quantizer with the closest bitrate.

Last edited by Tommy Carrot; 12th February 2019 at 01:53.
Tommy Carrot is offline   Reply With Quote
Old 14th February 2019, 21:17   #1465  |  Link
Mr.Radar
Registered User
 
Join Date: Nov 2002
Location: Minnesota, USA
Posts: 34
Quote:
Originally Posted by Phanton_13 View Post
I think that I misled wen I reference DRM, I was referencing to Digital Radio Mondiale where xhe-aac is one of the codecs used.
For those who are unaware, Digital Radio Mondiale is the digital broadcasting standard used on the shortware radio bands. Due to the narrow bandwidth of shortwave broadcast channels and the high amount of error correction required to avoid dropouts the usable bitrates are very low. Here is a 2017 comparison between xHE-AAC and Opus at those bitrates. More recent versions of libopus should produce significantly more competitive results in the speech-focused samples (libopus 1.3 enabled wideband audio down to 9 kbps) but on music samples xHE-AAC would probably retain the edge since Opus at very low bitrates is effectively operating mostly as a speech codec in its SILK mode.
Mr.Radar is offline   Reply With Quote
Old 15th February 2019, 00:28   #1466  |  Link
Mr_Khyron
Member
 
Mr_Khyron's Avatar
 
Join Date: Nov 2002
Posts: 203
SVT-AV1 significantly reduces memory use

https://github.com/OpenVisualCloud/SVT-AV1/pull/55

Over 50% reduction in memory requirements

Mr_Khyron is offline   Reply With Quote
Old 15th February 2019, 08:45   #1467  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
It says "low core count (e.g. 4-core machines)" though, does that mean it doesnt apply at all to higher core counts, or that they alreeady have a similar optimisation implemented or in the pipe?
soresu is offline   Reply With Quote
Old 15th February 2019, 09:23   #1468  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
It probably means that memory usage didn't scale properly to different core counts. The more cores you run, the more memory its going to need, that is not unexpected from any encoder.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 16th February 2019, 01:42   #1469  |  Link
Mr_Khyron
Member
 
Mr_Khyron's Avatar
 
Join Date: Nov 2002
Posts: 203
SVT-AV1 Already Seeing Nice Performance Improvements Since Open-Sourcing

https://phoronix.com/scan.php?page=n...Speed-Progress
Quote:
It was just a few weeks ago that Intel open-sourced the SVT-AV1 project as a CPU-based AV1 video encoder. In the short time since publishing it, there's already been some significant performance improvements.

Since the start of the month, SVT-AV1 has added multi-threaded CDEF search, more AVX optimizations, and other improvements to this fast evolving AV1 encoder. With having updated the test profile against the latest state as of today, here's a quick look at the performance of this Intel open-source AV1 video encoder.
Mr_Khyron is offline   Reply With Quote
Old 16th February 2019, 03:14   #1470  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
Quote:
Originally Posted by soresu View Post
"low core count (e.g. 4-core machines)"
That's certainly amusing considering that Intel seemed to love branding quad cores as i7 up until recently.

Speaking of quad core i7 CPUs...

Quote:
Originally Posted by Mr_Khyron View Post
I'm going to go out on a limb and guess that, on the SVT-AV1 v2019-02-15 results, the lack of performance delta seen between the i7-7740X and Ryzen 2700X is due to the former's considerably faster AVX2 implementation even though the Ryzen has twice as many cores and threads as the i7?
__________________
____HTPC____  | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258
Radeon HD5870  | Intel iGPU      
2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600       
Nintendo Maniac 64 is offline   Reply With Quote
Old 16th February 2019, 07:38   #1471  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
btw. https://ci.appveyor.com/project/Open...uild/artifacts offers Windows binaries of the stv-av1 encoder (SvtAv1EncApp.exe and SvtAv1EncApp.dll are needed)
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 16th February 2019, 21:33   #1472  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Very cool. I'm playing with this now.

Default settings are quite fast - it did 12 fps for 480p on my i7 7700k with 50% CPU usage and 1.2 GB RAM usage.

Here's the basic usage guide:
https://github.com/OpenVisualCloud/S..._user_guide.md

A sample command:
.\SvtAv1EncApp.exe -i .\beauty_480p.yuv -b out.ivf -w 848 -h 480 -fps 24

Yes, I had to encode at 848x480 and not 854 - comically this encoder requires mod 8 input

Results aren't too bad - the default CQ 50 setting produced a 623 Kbps file that looks marginally okay, and CQ 40 produced a 1.2 Mbps file that looks a lot better. There are some odd artifacts, almost like the edges of objects wiggle a bit every other frame.

However, I'm getting very jerky playback for some reason. I've tried a LAV nightly build in MPC-HC, latest VLC, and ffplay, and they all show the issue. I confirmed my input YUV is 24 fps and the output webm is 24 fps. When I step through it frame by frame it's all there, but for some reason it's jerky on playback. I don't recall seeing this with aomenc encodes, and the decoder isn't close to maxing out one core, so I'm not sure what's up with that...

Last edited by Blue_MiSfit; 16th February 2019 at 21:48.
Blue_MiSfit is offline   Reply With Quote
Old 18th February 2019, 02:20   #1473  |  Link
tnti
Registered User
 
Join Date: Jan 2017
Posts: 9
Quote:
Originally Posted by Blue_MiSfit View Post
Very cool. I'm playing with this now.

Default settings are quite fast - it did 12 fps for 480p on my i7 7700k with 50% CPU usage and 1.2 GB RAM usage.

Here's the basic usage guide:
https://github.com/OpenVisualCloud/S..._user_guide.md

A sample command:
.\SvtAv1EncApp.exe -i .\beauty_480p.yuv -b out.ivf -w 848 -h 480 -fps 24

Yes, I had to encode at 848x480 and not 854 - comically this encoder requires mod 8 input

Results aren't too bad - the default CQ 50 setting produced a 623 Kbps file that looks marginally okay, and CQ 40 produced a 1.2 Mbps file that looks a lot better. There are some odd artifacts, almost like the edges of objects wiggle a bit every other frame.

However, I'm getting very jerky playback for some reason. I've tried a LAV nightly build in MPC-HC, latest VLC, and ffplay, and they all show the issue. I confirmed my input YUV is 24 fps and the output webm is 24 fps. When I step through it frame by frame it's all there, but for some reason it's jerky on playback. I don't recall seeing this with aomenc encodes, and the decoder isn't close to maxing out one core, so I'm not sure what's up with that...
https://github.com/OpenVisualCloud/SVT-AV1/issues/33
tnti is offline   Reply With Quote
Old 21st February 2019, 23:16   #1474  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
Quote:
Originally Posted by benwaggoner View Post
I worry that AV1's interframe CABAC dependencies will impair random access enough to make the practical maximum GOP duration a lot smaller. Some of that could probably be addressed via encoder tweaks, at the loss of a little efficiency.
You don't need to worry - AV1 probability dependencies can only come from one of the reference frames, so it doesn't place any additional impairment on seekability.

(also note that CABAC is a misnomer, as it's not binary. The spec doesn't give it an acronym, but dav1d uses MSAC).
TD-Linux is offline   Reply With Quote
Old 22nd February 2019, 03:01   #1475  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
Quote:
Originally Posted by TD-Linux View Post
You don't need to worry - AV1 probability dependencies can only come from one of the reference frames, so it doesn't place any additional impairment on seekability.
I think his concern that a decoder (or a stupid player, which is 99.9% of them) don't know this. A good container format (like mp4) can represent the reference structure in its atoms, and then a good decoder + good container + good encoder can do the right thing. But if any one of them fails, you'll have a worse seeking experience if you want to do frame-exact user experience. It's up to all devs to make sure that doesn't happen, and like I said, this is multi-factorial so it's easy to forget and screw up.
Beelzebubu is offline   Reply With Quote
Old 22nd February 2019, 21:41   #1476  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Beelzebubu View Post
I think his concern that a decoder (or a stupid player, which is 99.9% of them) don't know this. A good container format (like mp4) can represent the reference structure in its atoms, and then a good decoder + good container + good encoder can do the right thing. But if any one of them fails, you'll have a worse seeking experience if you want to do frame-exact user experience. It's up to all devs to make sure that doesn't happen, and like I said, this is multi-factorial so it's easy to forget and screw up.
Yeah, the goal is for the decoder to determine the minimum sequence of frames required to decode a particular frame. With a IbbbBbbbPbbbBbbbPbbbbBbbbI kind of structure, decoding the last "b" frame in an Open GOP should require just six frames (IPPBIb) in decode order typically. But that requires the reference list because sometimes a b could reference two B frames back and things like that. With multiple reference frames it's impossible to reliably know the hierarchy without knowing what each frame references.

And there are patterns that can be spec-legal but that existing encoders might not do. And then better encoders add those to improve quality.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd February 2019, 22:37   #1477  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
Quote:
Originally Posted by benwaggoner View Post
Yeah, the goal is for the decoder to determine the minimum sequence of frames required to decode a particular frame. With a IbbbBbbbPbbbBbbbPbbbbBbbbI kind of structure, decoding the last "b" frame in an Open GOP should require just six frames (IPPBIb) in decode order typically. But that requires the reference list because sometimes a b could reference two B frames back and things like that. With multiple reference frames it's impossible to reliably know the hierarchy without knowing what each frame references.
Yeah, if you want to do that you'll need a reference list parser. But that's been true for a very long time - even x264 produces streams that require you to do this.

But regardless, whatever structure you pick, the CDFs always follow that same structure, so they are "free" from a seekability point of view.

Last edited by TD-Linux; 22nd February 2019 at 22:42.
TD-Linux is offline   Reply With Quote
Old 23rd February 2019, 00:31   #1478  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by TD-Linux View Post
Yeah, if you want to do that you'll need a reference list parser. But that's been true for a very long time - even x264 produces streams that require you to do this.

But regardless, whatever structure you pick, the CDFs always follow that same structure, so they are "free" from a seekability point of view.
That's good news. I had heard suggestions otherwise.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th February 2019, 23:29   #1479  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Seems like dav1d is now like 40% faster than libaom on my i5-2500K (no AVX2). And there's a pull request for additional SSSE3 optimizations with like another 50% speedup.

https://code.videolan.org/videolan/d...599#note_29705
sneaker_ger is offline   Reply With Quote
Old 25th February 2019, 00:06   #1480  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Once the CDEF patch is merged, it should definitely beat AOM in nearly all situations, in 8-bit decoding anyway. 10-bit/12-bit hasn't been worked on much yet, performance wise.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   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 12:44.


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