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 7th January 2019, 13:18   #1361  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
I was afraid to click an uncommented URL ... but did anyway.

This article is about HEVC licensing. Only marginally related to AOM.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 16th January 2019, 01:42   #1362  |  Link
TomV
VP Eng, Kaleidescape
 
Join Date: Jan 2018
Location: Mt View, CA
Posts: 51
Hey AV1 experts... can you share your command line for your highest subjective quality encodes? In other words, what's your recommended settings for the equivalent of --preset veryslow?
TomV is offline   Reply With Quote
Old 16th January 2019, 12:57   #1363  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
The preset equivalent for aomenc is --cpu-used. Contrary to what would be logical, it has nothing to do with threading. --cpu-used=0 is the equivalent of preset placebo, while 8 is fastest (more precisely the least slow) preset. I would not go over 6, after that the quality regression is really noticeable.
Tommy Carrot is offline   Reply With Quote
Old 16th January 2019, 13:24   #1364  |  Link
utack
Registered User
 
Join Date: Apr 2018
Posts: 63
Quote:
Originally Posted by Tommy Carrot View Post
I would not go over 6, after that the quality regression is really noticeable.
What kind of SSIM difference is noticeable?
Speed 1, 5 and 8
utack is offline   Reply With Quote
Old 16th January 2019, 16:11   #1365  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
I'm talking about visual quality. --cpu-used 7 and 8 are looking significantly worse than 6, while the encoding speed doesn't improve that much.
Tommy Carrot is offline   Reply With Quote
Old 16th January 2019, 18:51   #1366  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by TomV View Post
Hey AV1 experts... can you share your command line for your highest subjective quality encodes? In other words, what's your recommended settings for the equivalent of --preset veryslow?
Probably more like —preset very slow —tune film (or grain, or animation). The psychovisual tuning that’s implicit in x264/5’s RF model, and explicit in —tune and other parameters, are an important component.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 16th January 2019, 18:55   #1367  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by utack View Post
What kind of SSIM difference is noticeable?
Speed 1, 5 and 8
Mean of per frame SSIM is not a great metric, honestly. The mean of any per-frame metric isn’t going to catch variability of quality, and any spatial-only metric will be bad at catching frame strobing or other visual discontinuities.

The latest VMAF is the least-bad metric available, by a good margin. But even it isn’t very useful at comparing between high quality encodes and some kinds of artifacts.

Encoding history is littered with encoders with promising PSNR and SSIM scores that just didn’t look very good.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 17th January 2019, 17:14   #1368  |  Link
TomV
VP Eng, Kaleidescape
 
Join Date: Jan 2018
Location: Mt View, CA
Posts: 51
Quote:
Originally Posted by Tommy Carrot View Post
The preset equivalent for aomenc is --cpu-used. Contrary to what would be logical, it has nothing to do with threading. --cpu-used=0 is the equivalent of preset placebo, while 8 is fastest (more precisely the least slow) preset. I would not go over 6, after that the quality regression is really noticeable.
Yes, I'm aware of that. I've been using --cpu-used=1 Thanks.
TomV is offline   Reply With Quote
Old 17th January 2019, 17:20   #1369  |  Link
TomV
VP Eng, Kaleidescape
 
Join Date: Jan 2018
Location: Mt View, CA
Posts: 51
Quote:
Originally Posted by benwaggoner View Post
Probably more like —preset very slow —tune film (or grain, or animation). The psychovisual tuning that’s implicit in x264/5’s RF model, and explicit in —tune and other parameters, are an important component.
--preset is not an option (I get an error message)
There is a --tune option (psnr, ssim, cdef-dist, daala-dist), and a --tune-content option (default, screen)

Here's the help file. It seems like every option that would improve visual quality is on by default.

C:\Test>aomenc --help
Usage: aomenc <options> -o dst_filename src_filename

Options:
--help Show usage options and exit
-c <arg>, --cfg=<arg> Config file to use
-D, --debug Debug mode (makes output deterministic)
-o <arg>, --output=<arg> Output filename
--codec=<arg> Codec to use
-p <arg>, --passes=<arg> Number of passes (1/2)
--pass=<arg> Pass to execute (1/2)
--fpf=<arg> First pass statistics file name
--limit=<arg> Stop encoding after n input frames
--skip=<arg> Skip the first n input frames
--good Use Good Quality Deadline
-q, --quiet Do not print encode progress
-v, --verbose Show encoder parameters
--psnr Show PSNR in status line
--webm Output WebM (default when WebM IO is enabled)
--ivf Output IVF
--obu Output OBU
--q-hist=<arg> Show quantizer histogram (n-buckets)
--rate-hist=<arg> Show rate histogram (n-buckets)
--disable-warnings Disable warnings about potentially incorrect encode settings.
-y, --disable-warning-prompt Display warnings, but do not prompt user to continue.
--test-decode=<arg> Test encode/decode mismatch
off, fatal, warn

Encoder Global Options:
--yv12 Input file is YV12
--i420 Input file is I420 (default)
--i422 Input file is I422
--i444 Input file is I444
-u <arg>, --usage=<arg> Usage profile number to use
-t <arg>, --threads=<arg> Max number of threads to use
--profile=<arg> Bitstream profile number to use
-w <arg>, --width=<arg> Frame width
-h <arg>, --height=<arg> Frame height
--forced_max_frame_width Maximum frame width value to force
--forced_max_frame_height Maximum frame height value to force
--stereo-mode=<arg> Stereo 3D video format
mono, left-right, bottom-top, top-bottom, right-left
--timebase=<arg> Output timestamp precision (fractional seconds)
--fps=<arg> Stream frame rate (rate/scale)
--global-error-resilient=< Enable global error resiliency features
-b <arg>, --bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
--lag-in-frames=<arg> Max number of frames to lag
--large-scale-tile=<arg> Large scale tile coding (0: off (default), 1: on)
--monochrome Monochrome video (no chroma planes)
--full-still-picture-hdr Use full header for still picture

Rate Control Options:
--drop-frame=<arg> Temporal resampling threshold (buf %)
--resize-mode=<arg> Frame resize mode
--resize-denominator=<arg> Frame resize denominator
--resize-kf-denominator=<a Frame resize keyframe denominator
--superres-mode=<arg> Frame super-resolution mode
--superres-denominator=<ar Frame super-resolution denominator
--superres-kf-denominator= Frame super-resolution keyframe denominator
--superres-qthresh=<arg> Frame super-resolution qindex threshold
--superres-kf-qthresh=<arg Frame super-resolution keyframe qindex threshold
--end-usage=<arg> Rate control mode
vbr, cbr, cq, q
--target-bitrate=<arg> Bitrate (kbps)
--min-q=<arg> Minimum (best) quantizer
--max-q=<arg> Maximum (worst) quantizer
--undershoot-pct=<arg> Datarate undershoot (min) target (%)
--overshoot-pct=<arg> Datarate overshoot (max) target (%)
--buf-sz=<arg> Client buffer size (ms)
--buf-initial-sz=<arg> Client initial buffer size (ms)
--buf-optimal-sz=<arg> Client optimal buffer size (ms)

Twopass Rate Control Options:
--bias-pct=<arg> CBR/VBR bias (0=CBR, 100=VBR)
--minsection-pct=<arg> GOP min bitrate (% of target)
--maxsection-pct=<arg> GOP max bitrate (% of target)

Keyframe Placement Options:
--enable-fwd-kf=<arg> Enable forward reference keyframes
--kf-min-dist=<arg> Minimum keyframe interval (frames)
--kf-max-dist=<arg> Maximum keyframe interval (frames)
--disable-kf Disable keyframe placement

AV1 Specific Options:
--cpu-used=<arg> CPU Used (0..8)
--auto-alt-ref=<arg> Enable automatic alt reference frames
--sharpness=<arg> Loop filter sharpness (0..7)
--static-thresh=<arg> Motion detection threshold
--row-mt=<arg> Enable row based multi-threading (0: off, 1: on (default))
--tile-columns=<arg> Number of tile columns to use, log2
--tile-rows=<arg> Number of tile rows to use, log2
--enable-tpl-model=<arg> RDO modulation based on frame temporal dependency
--arnr-maxframes=<arg> AltRef max frames (0..15)
--arnr-strength=<arg> AltRef filter strength (0..6)
--tune=<arg> Distortion metric tuned with
psnr, ssim, cdef-dist, daala-dist
--cq-level=<arg> Constant/Constrained Quality level
--max-intra-rate=<arg> Max I-frame bitrate (pct)
--max-inter-rate=<arg> Max P-frame bitrate (pct)
--gf-cbr-boost=<arg> Boost for Golden Frame in CBR mode (pct)
--lossless=<arg> Lossless mode (0: false (default), 1: true)
--enable-cdef=<arg> Enable the constrained directional enhancement filter (0: false, 1: true (default))
--enable-restoration=<arg> Enable the loop restoration filter (0: false, 1: true (default))
--enable-rect-partitions=< Enable rectangular partitions (0: false, 1: true (default))
--enable-dual-filter=<arg> Enable dual filter (0: false, 1: true (default))
--enable-intra-edge-filter Enable intra edge filtering (0: false, 1: true (default))
--enable-order-hint=<arg> Enable order hint (0: false, 1: true (default))
--enable-tx64=<arg> Enable 64-pt transform (0: false, 1: true (default))
--enable-dist-wtd-comp=<ar Enable distance-weighted compound (0: false, 1: true (default))
--enable-masked-comp=<arg> Enable masked (wedge/diff-wtd) compound (0: false, 1: true (default))
--enable-interintra-comp=< Enable interintra compound (0: false, 1: true (default))
--enable-smooth-interintra Enable smooth interintra mode (0: false, 1: true (default))
--enable-diff-wtd-comp=<ar Enable difference-weighted compound (0: false, 1: true (default))
--enable-interinter-wedge= Enable interinter wedge compound (0: false, 1: true (default))
--enable-interintra-wedge= Enable interintra wedge compound (0: false, 1: true (default))
--enable-global-motion=<ar Enable global motion (0: false, 1: true (default))
--enable-warped-motion=<ar Enable local warped motion (0: false, 1: true (default))
--enable-filter-intra=<arg Enable filter intra prediction mode (0: false, 1: true (default))
--enable-smooth-intra=<arg Enable smooth intra prediction modes (0: false, 1: true (default))
--enable-paeth-intra=<arg> Enable Paeth intra prediction mode (0: false, 1: true (default))
--enable-cfl-intra=<arg> Enable chroma from luma intra prediction mode (0: false, 1: true (default))
--enable-obmc=<arg> Enable OBMC (0: false, 1: true (default))
--enable-palette=<arg> Enable palette prediction mode (0: false, 1: true (default))
--enable-intrabc=<arg> Enable intra block copy prediction mode (0: false, 1: true (default))
--enable-angle-delta=<arg> Enable intra angle delta (0: false, 1: true (default))
--disable-trellis-quant=<a Disable trellis optimization of quantized coefficients (0: false (default) 1: true)
--enable-qm=<arg> Enable quantisation matrices (0: false (default), 1: true)
--qm-min=<arg> Min quant matrix flatness (0..15), default is 8
--qm-max=<arg> Max quant matrix flatness (0..15), default is 15
--reduced-tx-type-set=<arg Use reduced set of transform types
--frame-parallel=<arg> Enable frame parallel decodability features (0: false (default), 1: true)
--error-resilient=<arg> Enable error resilient features (0: false (default), 1: true)
--aq-mode=<arg> Adaptive quantization mode (0: off (default), 1: variance 2: complexity, 3: cyclic refresh)
--deltaq-mode=<arg> Delta qindex mode (0: off (default), 1: deltaq 2: deltaq + deltalf)
--frame-boost=<arg> Enable frame periodic boost (0: off (default), 1: on)
--noise-sensitivity=<arg> Noise sensitivity (frames to blur)
--tune-content=<arg> Tune content type
default, screen
--cdf-update-mode=<arg> CDF update mode for entropy coding (0: no CDF update; 1: update CDF on all frames(default); 2: selectively update CDF on some frames
--color-primaries=<arg> Color primaries (CICP) of input content:
bt709, unspecified, bt601, bt470m, bt470bg, smpte240, film, bt2020, xyz, smpte431, smpte432, ebu3213
--transfer-characteristics Transfer characteristics (CICP) of input content:
unspecified, bt709, bt470m, bt470bg, bt601, smpte240, lin, log100, log100sq10, iec61966, bt1361, srgb, bt2020-10bit, bt2020-12bit, smpte2084, hlg, smpte428
--matrix-coefficients=<arg Matrix coefficients (CICP) of input content:
identity, bt709, unspecified, fcc73, bt470bg, bt601, smpte240, ycgco, bt2020ncl, bt2020cl, smpte2085, chromncl, chromcl, ictcp
--chroma-sample-position=< The chroma sample position when chroma 4:2:0 is signaled:
unknown, vertical, colocated
--min-gf-interval=<arg> min gf/arf frame interval (default 0, indicating in-built behavior)
--max-gf-interval=<arg> max gf/arf frame interval (default 0, indicating in-built behavior)
--gf-max-pyr-height=<arg> maximum height for GF group pyramid structure (1 to 4 (default))
--sb-size=<arg> Superblock size to use
dynamic, 64, 128
--num-tile-groups=<arg> Maximum number of tile groups, default is 1
--mtu-size=<arg> MTU size for a tile group, default is 0 (no MTU targeting), overrides maximum number of tile groups
--timing-info=<arg> Signal timing info in the bitstream (model unly works for no hidden frames, no super-res yet):
unspecified, constant, model
--film-grain-test=<arg> Film grain test vectors (0: none (default), 1: test-1 2: test-2, ... 16: test-16)
--film-grain-table=<arg> Path to file containing film grain parameters
--denoise-noise-level=<arg Amount of noise (from 0 = don't denoise, to 50)
--denoise-block-size=<arg> Denoise block size (default = 32)
--enable-ref-frame-mvs=<ar Enable temporal mv prediction (default is 1)
-b <arg>, --bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
--input-bit-depth=<arg> Bit depth of input
--input-chroma-subsampling chroma subsampling x value.
--input-chroma-subsampling chroma subsampling y value.
--sframe-dist=<arg> S-Frame interval (frames)
--sframe-mode=<arg> S-Frame insertion mode (1..2)
--annexb=<arg> Save as Annex-B

Stream timebase (--timebase):
The desired precision of timestamps in the output, expressed
in fractional seconds. Default is 1/1000.

Included encoders:

av1 - AOMedia Project AV1 Encoder 0.1.0-11038-g437d957f8 (default)

Use --codec to switch to a non-default encoder.
TomV is offline   Reply With Quote
Old 17th January 2019, 19:43   #1370  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by TomV View Post
--preset is not an option (I get an error message)
There is a --tune option (psnr, ssim, cdef-dist, daala-dist), and a --tune-content option (default, screen)
Sorry, I wasn't clear I was offering x264/5 syntax for what you want an AV1 equivalent to. Which does not (yet?) exist in libaom.

Libaom has very little psychovisual optimization compared to the x26? codecs, or psychovisual tuning options. Libaom is mare like a speed-optimized reference encoder right now. Production AV1 encoders will need to have much more psychovisual tuning.

I'm kinda surprised no one has started making a xAV1 based on x264 like x265 started. Although so many fundamental structures derived from the VPx series would make it a lot harder to start. HEVC was enough of a H.264 subset that getting an x265 that did SOMETHING wasn't THAT hard. AV1-as-an-ecosystem has a serious disadvantage in not having a well-tuned, production-grade, open-source VPx encoder to start from.

Libvpx never got the obsessive focus from thousands of quality/efficiency/speed obsessed video pirates that was the foundation of what x264 is today.

Just look at the H.264, or even the HEVC, forums here, and all the posts over many years. That's the kind of community focus that makes for a great encoder.

Look at the "Posts" column:

https://forum.doom9.org/forumdisplay.php?f=17
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book

Last edited by benwaggoner; 17th January 2019 at 19:47. Reason: missing word
benwaggoner is offline   Reply With Quote
Old 17th January 2019, 21:25   #1371  |  Link
TomV
VP Eng, Kaleidescape
 
Join Date: Jan 2018
Location: Mt View, CA
Posts: 51
Quote:
Originally Posted by benwaggoner View Post
Sorry, I wasn't clear I was offering x264/5 syntax for what you want an AV1 equivalent to. Which does not (yet?) exist in libaom.
Oh. That was my original question... "what's your recommended settings for the equivalent of --preset veryslow?" Of course I'm intimately familiar with x265 syntax. I defined a fair amount of it.
TomV is offline   Reply With Quote
Old 17th January 2019, 23:22   #1372  |  Link
zub35
Registered User
 
Join Date: Oct 2016
Posts: 56
benwaggoner If the codec will always be so slow to encode on x86 CPUs, then this encoder will be exclusively for large companies that are capable of acquiring a HW encoder.
AV1 it is a medal from two sides:
1. free and high quality 2. the need to purchase special HW encoders.
Therefore, what is the point of the community to develop it in of quality improvement.
AV1 in its current form (x86), is simply a way of advertising and popularization, nothing more.
p.s. AV1 - "free" (need buy HW) codec for only youtube...

Last edited by zub35; 17th January 2019 at 23:39.
zub35 is offline   Reply With Quote
Old 18th January 2019, 00:31   #1373  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
Quote:
Originally Posted by zub35 View Post
benwaggoner If the codec will always be so slow to encode on x86 CPUs, then this encoder will be exclusively for large companies that are capable of acquiring a HW encoder.
AV1 it is a medal from two sides:
1. free and high quality 2. the need to purchase special HW encoders.
Therefore, what is the point of the community to develop it in of quality improvement.
AV1 in its current form (x86), is simply a way of advertising and popularization, nothing more.
p.s. AV1 - "free" (need buy HW) codec for only youtube...
rav1e is a reasonably fast encoder, it can do several fps and will get faster with time.

Also youtube won't be the only ones adopting this. Facebook, bbc iplayer, netflix etc and many others will be adopting this.
hajj_3 is offline   Reply With Quote
Old 19th January 2019, 10:18   #1374  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by zub35 View Post
benwaggoner If the codec will always be so slow to encode on x86 CPUs, then this encoder will be exclusively for large companies that are capable of acquiring a HW encoder.
It's not completely set in stone, but I really believe H.264/AVC might be the last codec easily encodable in pure x86/x64. lntel and AMD have agreed on some extensions to make H.265/HEVC and AV1 not suck quite as much, but the obvious direction is in GPU or fixed-function encoding.
foxyshadis is offline   Reply With Quote
Old 19th January 2019, 11:01   #1375  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
Quote:
Originally Posted by foxyshadis View Post
lntel and AMD have agreed on some extensions to make H.265/HEVC and AV1 not suck quite as much
source?
hajj_3 is offline   Reply With Quote
Old 20th January 2019, 03:20   #1376  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 56
I think that is the reason H.264/AVC ditched some complicated features whether they can be implemented by hardware decoder or not. In some extensions, heavy taxing on cpu loading from software encoding perspective is quite possible.
alex1399 is offline   Reply With Quote
Old 20th January 2019, 08:23   #1377  |  Link
Gravitator
Registered User
 
Join Date: May 2014
Posts: 292
How do I beat a pulsating noise?
I need to save/delete it across the entire sample (using the AOM settings).
> Encoded sample
> Original sample
Quote:
aomenc --passes=2 --pass=1 --target-bitrate=800 --end-usage=vbr --fpf="PATH TO THE .stats FILE" --profile=0 --cpu-used=6 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --overshoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=1 --arnr-maxframes=7 --arnr-strength=5 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tune-content=default --tile-columns=0 --tile-rows=0 --aq-mode=0 --min-gf-interval=0 --max-gf-interval=0 --threads=2 --width=1920 --height=816 --i420 --input-bit-depth=10 --bit-depth=10 --row-mt=0 --cdf-update-mode=1 -o NUL -

aomenc --passes=2 --pass=2 --target-bitrate=800 --end-usage=vbr --fpf="PATH TO THE .stats FILE" --profile=0 --cpu-used=6 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --overshoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=1 --arnr-maxframes=7 --arnr-strength=5 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tune-content=default --tile-columns=0 --tile-rows=0 --aq-mode=0 --min-gf-interval=0 --max-gf-interval=0 --threads=2 --width=1920 --height=816 --i420 --input-bit-depth=10 --bit-depth=10 --row-mt=0 --cdf-update-mode=1 -o OUTPUTFILE -
__________________
Win10x64, Xeon E5450, GTX 750 2GB, DDR3 8GB.
Gravitator is offline   Reply With Quote
Old 21st January 2019, 19:26   #1378  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by foxyshadis View Post
It's not completely set in stone, but I really believe H.264/AVC might be the last codec easily encodable in pure x86/x64. lntel and AMD have agreed on some extensions to make H.265/HEVC and AV1 not suck quite as much, but the obvious direction is in GPU or fixed-function encoding.

HEVC is certainly encodable on x64, although 32-bit becomes impractical at high quality at very high frame sizes. The trend for even live encoding has been towards highly multithreaded CPU encoding. Fixed-function ASIC style hardware is too inflexible when there are SO many options for how to encode every block, with lots of psychovisual tuning to be done. The more complex codecs get, the more high quality encoders are on CPU. And arithmetic entropy coding really benefits from peak single-thread performance. I think there is hope for hybrid CPU/GPU/ASIC/FPGA models, but I don’t see professional quality encoding not to heavily use CPU anytime soon.

I don’t think there is anything intrinsically hard about AV1 for software encoding. If anything SW encoding could be easier than HW encoding due to parallelization limitations. The bigger issue is that VPx hasn’t had a truly competitive quality @ perf encoder in YEARS. And a reference encoder isn’t a great starting point, which libaom sort of is. If one wanted to build a quality @ perf optimized encoder from scratch, especially for low latency live encoding, I’d start by just implementing the mandatory features of a bitstream and then add features incrementally, seeing what their quality @ perf is. Starting with an encoder that HAS to use ALL codec features like a reference encoder does can be harder than going front the ground up.


Sent from my iPhone using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 21st January 2019, 19:30   #1379  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by hajj_3 View Post
rav1e is a reasonably fast encoder, it can do several fps and will get faster with time.



Also youtube won't be the only ones adopting this. Facebook, bbc iplayer, netflix etc and many others will be adopting this.

Do we have data on quality @ perf @ bitrate?

It’s pretty easy to make a fast encoder. But making one that is fast and produces competitive quality at a given bitrate is a lot harder.

AV1 is new enough that I don’t expect encoders to give us a clear sense of what the potential quality @ perf for the bitstream is yet. There is a lot of quality and perf optimization to be in the ballpark to compare.


Sent from my iPhone using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th January 2019, 23:13   #1380  |  Link
utack
Registered User
 
Join Date: Apr 2018
Posts: 63
A new Speech on AV1 by Tim Terriberry
https://www.youtube.com/watch?v=qubPzBcYCTw
utack 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 16:59.


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