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 October 2018, 12:15   #1121  |  Link
Kurosu
Registered User
 
Join Date: Sep 2002
Location: France
Posts: 432
Quote:
Originally Posted by mandarinka View Post
There just wasn't motivation on the side of devs it seems (preferences for the google/royalty-free formats etc).
I'd rather say that most capable devs had enough of (big) corps freeloading and/or are paid to do something else. In a sense, it is actually a good thing that they learnt such a lesson, as it indicates a maturing and more professional community. And if AoM is ready to play fair in that regard, then it's "not-AoM" loss.

As for HEVC, the mentioned WPP+frame threading could be available today. All in all, there's likely 30% speed-up left.

Source: said capable devs.

Last edited by Kurosu; 12th October 2018 at 12:37.
Kurosu is offline   Reply With Quote
Old 12th October 2018, 16:30   #1122  |  Link
Monarc
Registered User
 
Join Date: Jun 2002
Posts: 35
Quote:
Originally Posted by marcomsousa View Post
Code:
ffmpeg -benchmark -i Stream2_AV1_4K_22.7mbps.webm -f null -
Video: wrapped_avframe, yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)
frame= 3604 fps= 16 q=-0.0 Lsize=N/A time=00:02:24.16 bitrate=N/A speed=0.622x
bench: utime=1069.000s stime=12.891s rtime=231.970s
bench: maxrss=856880kB
Since the video was 25 fps, in benchmark give that my PC is only capable to decode at 15-16 fps (speed=0.622x) at with this 22.7mbps video.

CPU: Intel Core i7-8550U
Decoder: ffmpeg-20181007-0a41a8b-win64 - libaom-av1 1.0.0-691-gbb8157b89
on my Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz

ffmpeg -benchmark -i Stream2_AV1_4K_22.7mbps.webm -f null -

ffmpeg version n4.0.2
[libaom-av1 @ 0x55e28fe6f180] 1.0.0-759-g90a15f4f28

frame= 3604 fps=6.2 q=-0.0 Lsize=N/A time=00:02:24.16 bitrate=N/A speed=0.246x
video:1886kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=579.607s
bench: maxrss=602748kB



ffmpeg -threads 4 -benchmark -i Stream2_AV1_4K_22.7mbps.webm -f null -

frame= 3604 fps= 16 q=-0.0 Lsize=N/A time=00:02:24.16 bitrate=N/A speed=0.643x
video:1886kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=656.087s
bench: maxrss=737080kB
Monarc is offline   Reply With Quote
Old 13th October 2018, 00:26   #1123  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Kurosu View Post
I'd rather say that most capable devs had enough of (big) corps freeloading and/or are paid to do something else. In a sense, it is actually a good thing that they learnt such a lesson, as it indicates a maturing and more professional community. And if AoM is ready to play fair in that regard, then it's "not-AoM" loss.
Also, multithreaded decode speed isn't THAT important a feature for ffmpeg, which is mainly for transcoding. Lots of operations that include decode are going to be encoder-bound. And the other operations likely have work to do on unused cores. Multithreaded decode uses more memory and sometimes CPU, so an export-bound operation may actually be a little faster with a single-threaded decoder.

You are right that lots of ffmpeg and other open-source encoder/tool development is corporate funded, and so a lot of its development is driven by what companies want enough to pay for. And HEVC source is still pretty uncommon outside of some high end contribution streams from live events.

Quote:
As for HEVC, the mentioned WPP+frame threading could be available today. All in all, there's likely 30% speed-up left.

Source: said capable devs.
That's reasonable. Decoders hit the point of asymptotic speed increases a lot sooner than encoders as there is only one "right" answer. AV1 is going to have >>30% decoder perf headroom still. I am curious how the greater variety of tools will impact optimal decoder performance in AV1 versus HEVC. AV1 is MUCH better designed for both HW and multithreaded SW decoders than VP9 and earlier, which had limitations in the loop filter and frame signaling that made them almost single-threaded. Which was generally fine for a PC web browser of the era, but had some real limitations for battery operated devices or those with lots of slower cores.

We'll probably have a good sense of the fundamental real-world decoder perf differences between HEVC and AV1 in 2019.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 13th October 2018, 06:30   #1124  |  Link
Kurosu
Registered User
 
Join Date: Sep 2002
Location: France
Posts: 432
Quote:
Originally Posted by benwaggoner View Post
Also, multithreaded decode speed isn't THAT important a feature for ffmpeg, which is mainly for transcoding
True, the decoding speed increase is no longer useful for a lot of companies. Security is often more important.

Quote:
AV1 is MUCH better designed for both HW and multithreaded SW decoders than VP9 and earlier, which had limitations in the loop filter and frame signaling that made them almost single-threaded.
One of those bottlenecks in thread scaling, what I'd call entropic state sharing across frames, is still there in AV1. This is to me something that was decided irrespective of SW decoding. Another sign that indeed the interest in it is only transitory.

Quote:
We'll probably have a good sense of the fundamental real-world decoder perf differences between HEVC and AV1 in 2019.
And in 2020, hopefully, new products will all have HW decoding of AV1, so that would then no longer matter.
Kurosu is offline   Reply With Quote
Old 13th October 2018, 16:29   #1125  |  Link
Mjpeg
Registered User
 
Join Date: Jun 2018
Posts: 7
Bitmovin encoder speedup

New article from Streaming Media:
http://www.streamingmedia.com/Articl...ts-127956.aspx

On the second page there is an intriguing slide from Bitmovin that with a pure software encoder version of libaom, they attained a speedup for cpu-used=0 from 1000x of VP9 in the early days down to 40x today with improvements ongoing. The claim from AOM was always that there was lots of room for optimization work once the spec was settled and ... well maybe that's happening. The proof will be when those speedups are in mainline FFmpeg and show up in tests on this very thread!

The slide also quotes software decode of 3.4x of VP9 single-threaded.
Mjpeg is offline   Reply With Quote
Old 13th October 2018, 18:27   #1126  |  Link
utack
Registered User
 
Join Date: Apr 2018
Posts: 63
Quote:
Originally Posted by Mjpeg View Post
Regarding the "poor results for AV1".
The BBC paper used single pass encode
Quote:
The parameters “--passes=1” and “--lag-in-frames=0” were set to run AV1 in single pass mode
without the possibility of looking ahead in the video sequence before encoding
The Harmonic paper used a fixed GOP of less than a single second of video material
Quote:
--min-gf-interval=16 --max-gf-interval=16
The Ateme paper does not mention any configuration for the encoder

That is basically three results that are only good for academic publication count and the gutter in the real world


On another note, there is a 5 minute 720p clip with super diverse content out there now on youtube where VP9 and AV1 version have basically the same file size:
https://www.youtube.com/watch?v=WaWnLiffxJ4
You can do some direct comparison of quality

Last edited by utack; 13th October 2018 at 22:35.
utack is offline   Reply With Quote
Old 14th October 2018, 08:25   #1127  |  Link
marcomsousa
Registered User
 
Join Date: Jul 2018
Posts: 80
Quote:
Originally Posted by Clare View Post
I already patched my build with this. It seems that as soon as the first frame is finished rendering, it drops back to one core.

Another fix was merged
Quote:
Fix allocation of workers for enc row-mt

Workers allocated for row based multi-threading of encoder are
now evaluated as minimum of num of threads and total number of
sb rows in the frame to be encoded.

Change-Id: I07501f43514f1ee45dd6637fe56411432930396c
__________________
AV1 win64 VS2019 builds
Last build here
marcomsousa is offline   Reply With Quote
Old 14th October 2018, 09:41   #1128  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
Quote:
Originally Posted by Mjpeg View Post
New article from Streaming Media:
http://www.streamingmedia.com/Articl...ts-127956.aspx

On the second page there is an intriguing slide from Bitmovin that with a pure software encoder version of libaom, they attained a speedup for cpu-used=0 from 1000x of VP9 in the early days down to 40x today with improvements ongoing.
Might be worth noting that the slide is from a Google employee, the Bitmovin employee was just in the audience.

I'm intrigued to hear more about the AI strategies they are using and wonder how portable those are once the "trick" has been revealed by the AI.
dapperdan is offline   Reply With Quote
Old 14th October 2018, 11:29   #1129  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
Quote:
Originally Posted by Mjpeg View Post
On the second page there is an intriguing slide from Bitmovin that with a pure software encoder version of libaom, they attained a speedup for cpu-used=0 from 1000x of VP9 in the early days down to 40x today with improvements ongoing.
The speed improvements are nice, but many of those optimizations came at the cost of the quality. I'd estimate the compression efficiency dropped about 2-3% since the earlier versions.
Tommy Carrot is offline   Reply With Quote
Old 14th October 2018, 19:55   #1130  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
Personally, considering that BBC is directly involved in development of VVC, and given that they joined the AV1 party relatively late in the development cycle, I'm inclined to find their so called research analysis somewhat suspect.

The Streaming Media article mentions their credibility on the issue, coming from a member of AOMedia, without taking into account just how late they joined.

At the very least it seems a conflict of interest to post such a negative paper so early in the post standard development of AV1, even more so considering that VVC is 2 years away from even being standardised.

Does anyone here have any idea what level of patent/proposals BBC have in the VVC working group?

Edit: Sorry if this is on the wrong thread, it concerns both AV1 and VVC so I wasnt sure which to drop it in.

Last edited by soresu; 14th October 2018 at 19:59.
soresu is offline   Reply With Quote
Old 15th October 2018, 16:53   #1131  |  Link
Clare
Registered User
 
Join Date: Apr 2016
Posts: 61
AV1 Image File Format (AVIF) https://people.xiph.org/~negge/AVIF2018.pdf

Mile-High Video Workshop videos http://mile-high.video/files/mhv2018/

with topics such as:
  1. Video Encoding and HEVC
  2. Into the Depths: The Technical Details behind AV1
  3. AV1 vs. HEVC: Perceptual Evaluation of Video Encoders
  4. Codec Comparison from TCO and Compression Efficiency Perspective
  5. VVC – The Next-Generation Video Standard of the Joint Video Experts Team
  6. Pushing Encoding Quality and Speed with x265
  7. Massively Parallel Encoding
Clare is offline   Reply With Quote
Old 15th October 2018, 19:32   #1132  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Tommy Carrot View Post
The speed improvements are nice, but many of those optimizations came at the cost of the quality. I'd estimate the compression efficiency dropped about 2-3% since the earlier versions.
A 2.5x perf improvement with only a 2-3% efficiency tradeoff is a pretty good optimization option. That's ballpark to a x26? preset ratio in perf and quality.

And things have to get LOTS faster to do the psychovisual and rate control tuning to get AV1 into something that can be practically compared to other encoders/bitstreams. Quality won't matter within an order of magnitude of the current speeds. It's not like anyone is actually delivering in volume 1080p encoded with --preset placebo either!

Quality @ Bitrate @ Perf!
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 16th October 2018, 11:05   #1133  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 95
According to my tests on my F.Y.C clip (1280x720, 480 frames) aomenc right now has got roughly the same encoding quality @ bpp of 1 month ago, with a deviation within the 1%, but is also somewhere between 14-25% faster than 2 months ago for --cpu-used=4
Which means that clip now encodes, in single thread at CQ 20, in 66 minutes rather than 87 on my i7-4770.

aomenc 1.0.0-359-g1bc580401:
Code:
# aomenc --frame-parallel=0 --tile-columns=0 --auto-alt-ref=2 --cpu-used=4 --passes=2 --threads=1 --lag-in-frames=25 --end-usage=q --cq-level=20 -o test.av1.cq20.webm orig.i420.y4m
Pass 1/2 frame  480/481    92352B    1539b/f   36899b/s   21265 ms (22.57 fps)
Pass 2/2 frame  480/480  5995490B   99924b/f 2395780b/s 5245119 ms (0.09 fps)
aomenc 1.0.0-775-g7f492af02:
Code:
# aomenc --frame-parallel=0 --tile-columns=6 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --threads=1 --end-usage=q --cq-level=20 -o test.av1.cq20.webm orig.i420.y4m
Pass 1/2 frame  480/481    92352B    1539b/f   36899b/s   17764 ms (27.02 fps)
Pass 2/2 frame  480/480  6092708B  101545b/f 2434645b/s 3969928 ms (0.12 fps)

Last edited by SmilingWolf; 16th October 2018 at 11:21.
SmilingWolf is offline   Reply With Quote
Old 16th October 2018, 12:11   #1134  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by Clare View Post
AV1 Image File Format (AVIF) https://people.xiph.org/~negge/AVIF2018.pdf
Funnily enough there's barely any mention of AVIF. Like 8 pages.
mzso is offline   Reply With Quote
Old 16th October 2018, 16:53   #1135  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by mzso View Post
Funnily enough there's barely any mention of AVIF. Like 8 pages.
Well, everything about intra coding is relevant to AVIF.

It's interesting to see the use of VMAF for still images. I question its relevance, as VMAF was only calibrated on >=24p moving images. Has anyone published any data suggesting VMAF is useful for measuring still images?

Also, the image comparisons versus HEVC don't show the command line. HEVC doesn't have --preset stillimage like x264, but I've tried an adaption of those parameters in x265. I'd expect it would improve the quality of the HEVC (HEIF?) image significantly. I saw some of the new Adobe tools that came out the last few days also include an HEIF exporter, which would be interesting to compare. Looks like fixed QP is being used for both AV1 and HEVC, which is going to be suboptimal for both codecs. Particularly for anything that includes mixed natural/synthetic imagery.

It amused me that it ended with a frames-per-minute graph that doesn't reference frame size, nor whether this is for still only or for temporal encoding. The idea of a still image taking 38 seconds to encode is going to horrify anyone using an image server.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 16th October 2018, 17:08   #1136  |  Link
marcomsousa
Registered User
 
Join Date: Jul 2018
Posts: 80
Quote:
Originally Posted by Clare View Post
AV1 Image File Format (AVIF) https://people.xiph.org/~negge/AVIF2018.pdf
Presentation explained
https://www.youtube.com/watch?v=On9VOnIBSEs
__________________
AV1 win64 VS2019 builds
Last build here
marcomsousa is offline   Reply With Quote
Old 16th October 2018, 19:55   #1137  |  Link
marcomsousa
Registered User
 
Join Date: Jul 2018
Posts: 80
Google released today Chrome 70

Chrome 70 adds an AV1 decoder (it's enabled by default) to Chrome Desktop x86-64 based on the official bitstream specification. At this time, support is limited to “Main” profile 0 and does not include encoding capabilities. The supported container is MP4 (ISO-BMFF) (see From raw video to web ready for a brief explanation of containers).

To try AV1:
  • Update your stable Chome just type in the url: chrome://settings/help and restart Chrome
  • Go to the YouTube TestTube page.
  • Select "Prefer AV1 for SD" or "Always Prefer AV1" to get the desired AV1 resolution. Note that at higher resolutions, AV1 is more likely to experience playback performance issues on some devices.
  • Try playing YouTube clips from the AV1 Beta Launch Playlist.
  • Confirm the codec av01 in "Stats for nerds".
__________________
AV1 win64 VS2019 builds
Last build here

Last edited by marcomsousa; 16th October 2018 at 20:15.
marcomsousa is offline   Reply With Quote
Old 17th October 2018, 08:19   #1138  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
Quote:
Originally Posted by benwaggoner View Post

And things have to get LOTS faster to do the psychovisual and rate control tuning to get AV1 into something that can be practically compared to other encoders/bitstreams. Quality won't matter within an order of magnitude of the current speeds. It's not like anyone is actually delivering in volume 1080p encoded with --preset placebo either!
Netflix already use VP9, which is lacking good rate control and psychovisual tuning, but still delivering higher quality (VMAF) at lower bitrates than their other streams (according to their blog posts) and they have said they'd roll out AV1 when it was within 4-10x slower than VP9. Presumably based on getting higher quality that makes that tradeoff worthwhile for them at that point.
Bitmovin claims their latest encoder release is twice as fast as stock AV1 and 20x slower than VP9 so things don't seem to be that far off AV1 being delivered on a large scale.

They also have the extra bonus of being able to encode their in-house stuff without film grain and add it later, a feature they were keen to have added to AV1.

Last edited by dapperdan; 17th October 2018 at 08:55.
dapperdan is offline   Reply With Quote
Old 17th October 2018, 11:44   #1139  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by dapperdan View Post
Netflix already use VP9, which is lacking good rate control
Is that still true? My ipression these days from youtube are that the bitrates are quite stable. (Might be wrong)

Quote:
Originally Posted by dapperdan View Post
They also have the extra bonus of being able to encode their in-house stuff without film grain and add it later, a feature they were keen to have added to AV1.
Stupidest feature ever. They should have implemented an optional "hellyeahIwantnoiseLOL" decoder feature instead.
mzso is offline   Reply With Quote
Old 17th October 2018, 12:26   #1140  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Don't miss the detail that bitrate optimization for streaming mainly means ABR — and the smaller the assumed decoding buffer and allowed preload time, the closer it gets to CBR, which will cause quality fluctuations. Oh, the joy of the VBV model.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 21:10.


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