Alliance for Open Media codecs

[Mr_Khyron]

SVT-AV1 v0.7.5
https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.7.5

- RDOQ for 10-bit
- Inter Intra Class pruning at MD-Staging
- Global Motion Vector support for 8-bit and 10-bit
- Interpolation Filter Search support for 10-bit
- Palette Prediction support
- 2-pass encoding support
- ATB 10-bit support at the encode pass
- Simplified MD Staging [only 3 stages]
- Inter-Inter and Inter-Intra Compound for 10-bit
- Intra Paeth for 10-bit
- Filter Intra Prediction
- New-Near and Near-New support
- OBMC Support for 8-bit and 10-bit
- RDOQ Chroma
- ATB Support for Inter Blocks
- Temporal Filtering for 10-bit
- Eight-pel support in predictive ME
- MCTS Tiles support
- Added AVX512 Optimizations
- Added AVX2 Optimizations

[Nintendo Maniac 64]

As usual, a new version of SVT-AV1 is released just in time for Phoenix to benchmark the previous 0.7 version on the new i9-10980XE and Threadripper 3960X and 3970X. :p (they unfortunately didn't have a Ryzen 3950X to benchmark)

https://www.phoronix.com/scan.php?page=article&item=amd-linux-3960x-3970x&num=8

Also included are benchmarks of rav1e v0.1 (1080p), dav1d v0.5.0 (1080p, 4k, and 10bit 1080p).


AV1 performance-per-watt charts can be found on this page (scroll down):
https://www.phoronix.com/scan.php?page=article&item=amd-linux-3960x-3970x&num=12

...and AV1 performance-per-dollar charts can be found on this page (also scroll down):
https://www.phoronix.com/scan.php?page=article&item=amd-linux-3960x-3970x&num=13

[Mr_Khyron]

https://www.mediatek.com/products/smartphones/dimensity-1000

MediaTek Dimensity 1000

We’re redefining the flagship smartphone experience with MediaTek Dimensity mobile series. MediaTek's technological and product leadership is exhibited in our new series of 5G-integrated SoC’s (system on chip) designed for premium-to-flagship smartphones.

Through the clever combination of the most powerful and innovative technologies in a leading design, this tiny 7nm chip is the new era of mobility, where everyone, and everything is seamlessly connected.

With MediaTek Dimensity, Expect Incredible.
Blur-busting displays, fast 4K multimedia & AV1 decoding

HFR (high frame rate) displays are not just an essential feature for gamers to attack the action, but they’re also beneficial to the everyday experience with notably smoother scrolling of webpages and animations in apps. The MediaTek Dimensity 1000 brings this supreme sensation to smartphones with FullHD+ displays up to 120Hz and 2K+ up to 90Hz.

In addition to enabling hardware video encoding and decoding at 4K 60FPS, the MediaTek Dimensity 1000 is the world’s 1st mobile SoC with AV1 format support: the latest and most advanced video streaming technology supported by major global technology and content makers, helping to enable new levels of visual detail, crisper sound and higher resolutions in the latest wave of streaming media.

[hajj_3]

The Mediatek Dimensity 1000 chip can hardware decode 4k 60fps AV1, it can't encode in AV1 in case anyone was wondering. Still fantastic news though :)

[soresu]

The Mediatek Dimensity 1000 chip can hardware decode 4k 60fps AV1, it can't encode in AV1 in case anyone was wondering. Still fantastic news though :)

Encoder ASICs usually take longer to appear if memory serves, I certainly remember HEVC decoders came before encoders in mobile.

[Adonisds]

The Mediatek Dimensity 1000 chip can hardware decode 4k 60fps AV1, it can't encode in AV1 in case anyone was wondering. Still fantastic news though :)

These 4k60 hardware decoders, are they only capable of decoding 1/4 of that in HDR mode?

[Blue_MiSfit]

Why would that be the case? The decoder doesn't have to work any harder to decode HDR (assuming you're already doing 10 bit, which you should be).

[soresu]

Why would that be the case? The decoder doesn't have to work any harder to decode HDR (assuming you're already doing 10 bit, which you should be).

Perhaps he means tone mapping for displaying HDR content on SDR screens?

[Nintendo Maniac 64]

Phononix benchmarked the performance of Windows 10 vs Linux in both rav1e v0.1 and SVT-AV1 v0.7 on a Threadripper 3970X: https://www.phoronix.com/scan.php?page=article&item=3970x-windows-linux&num=5

[Adonisds]

Why would that be the case? The decoder doesn't have to work any harder to decode HDR (assuming you're already doing 10 bit, which you should be).

Perhaps he means tone mapping for displaying HDR content on SDR screens?

No, I'm assuming SDR is done with 8 bits and HDR with 10. Why do you assume people would use 10 bit for SDR? Youtube currently uses 8 bits for SDR AV1.

I'm also assuming that these decoders advertised as 4k60 capable are only capable of that in 8 bits. I would a bit surprised if that was not the case.

So possibly they are not really ready for HDR content. And since AV1 is a codec for a time in the future when HDR could be common, that is dissapointing. I would think that since Netflix is pushing hard for it, at least 10bit 4k24 would be supported.

[Adonisds]

No, I'm assuming SDR is done with 8 bits and HDR with 10. Why do you assume people would use 10 bit for SDR? Youtube currently uses 8 bits for SDR AV1.

I'm also assuming that these decoders advertised as 4k60 capable are only capable of that in 8 bits. I would a bit surprised if that was not the case.

So possibly they are not really ready for HDR content. And since AV1 is a codec for a time in the future when HDR could be common, that is dissapointing. I would think that since Netflix is pushing hard for it, at least 10bit 4k24 would be supported.

Looks like I'm wrong in my second assumption, thankfully. At least the WAVE510A decoder does decode 10 bit 4k60

Edit: looks like I also misunderstood what Blue_MiSfit said. He just said decoders should do 10bit, not SDR videos. Well, that was all pointless. But let my mistakes all be public. I'm just gonna go hide in shame.

[Blue_MiSfit]

All good :)

10 bit SDR is totally valid, especially in the premium case where source content is at least 10 bit 4:2:2. It's unfortunate that the first wave of hardware HEVC decoders were 8 bit, else all HEVC would be 10 bit today.

We only encode 10 bit HEVC on the service I work on (SDR, HDR10, and Dolby Vision)

[NikosD]

Anandtech agrees that MediaTek's Dimensity 1000 could be the first consumer mobile SoC to support hardware-decoding of AV1
Media encoding capabilities fall in at 4K60, but here the biggest surprise lies in the chipset's support for AV1 video decoding.
As far as we're aware, this make the D1000 the very first consumer mobile SoC to support the format, which is a great leap forward in terms of future-proofing the devices which are based on the new chip.

[benwaggoner]

Perhaps he means tone mapping for displaying HDR content on SDR screens?HDR tone mapping is generally done in the SoC or GPU. It shouldn't impact decoder performance, but might increase battery draw.

Of course, doing 1080p on a phone is nearly placebo for most TV/film content. 4K is beyond overkill for such a small screen.

Generally decoders support the same resolution/fps in all supported bit modes. It's more expensive to go beyond 8-bit, but not in a way that makes it materially cheaper to only support >8-bit at lower resolutions.

Sent from my SM-T837V using Tapatalk

[huhn]

isn't 10 bit HEVC still generally better then 8 bit but the difference is very very small?

and the whole story of 8bpp and 16bpp x265. wasn't that an very important part why x264 10 bit was much better thanks to 10 bit bpp instead of 8.
is the 8 bpp x265 even alive?

how does AV1 handle this is this even comparable?

isn't a 8 bit quality pipe absolutely impossible anyway? just the level/RGB conversation pretty much proves it or even the chroma upscale.

[Blue_MiSfit]

I didn't mean to imply that encoding 8 bit content in 10 bit AV1 would be the right thing to do.

I just meant that given premium content almost always being > = 10 bit 4:2:2 it makes sense to preserve 10 bit, especially when picky studios are highly critical of how subtle gradients are handled in their content.

[Blue_MiSfit]

Regarding Google working on their own AV1 decoder, I'd imagine this has to do with being the masters of their own destiny so they can use the decoder however they want on Android / anywhere else, free from any potential licensing incompatibility with dav1d.

[nevcairiel]

Regarding Google working on their own AV1 decoder, I'd imagine this has to do with being the masters of their own destiny so they can use the decoder however they want on Android / anywhere else, free from any potential licensing incompatibility with dav1d.

dav1d has one of the most liberal licenses anywhere (2-clause BSD), Android already uses libraries under far stricter licenses.

Nevermind that Chrome already uses dav1d as well, so its not like Google somehow doesn't know about it, or something like that.

The reason is probably some BS politics, and has no logical backing.

[Blue_MiSfit]

Hmm. That's unfortunate, I wonder if we'll ever know the real story here :)

[benwaggoner]

I didn't mean to imply that encoding 8 bit content in 10 bit AV1 would be the right thing to do.

I just meant that given premium content almost always being > = 10 bit 4:2:2 it makes sense to preserve 10 bit, especially when picky studios are highly critical of how subtle gradients are handled in their content.Premium content is NOT >=10-bit 4:2:2. 10-bit 4:2:0 is all that anyone is distributing to consumers via streaming and disc. The masters are, certainly, but it's not like those look visually better than distribution codecs at a sufficient bitrate.

Sent from my SM-T837V using Tapatalk

[benwaggoner]

isn't 10 bit HEVC still generally better then 8 bit but the difference is very very small?



and the whole story of 8bpp and 16bpp x265. wasn't that an very important part why x264 10 bit was much better thanks to 10 bit bpp instead of 8.

is the 8 bpp x265 even alive?



how does AV1 handle this is this even comparable?



isn't a 8 bit quality pipe absolutely impossible anyway? just the level/RGB conversation pretty much proves it or even the chroma upscale.There is a significant but shrinking number of devices, mainly handheld, that support 8-bit HEVC but not 10-bit.

More common is devices with 10-bit decoders that then feed into 8-bit compositors, GPUs, or display controllers.

Sent from my SM-T837V using Tapatalk

[foxyshadis]

Do we have any evidence that 8-bit sources encode better in 10-bit than 8-bit in AV1?

If nothing else, 8b RGB to 10b YUV to 8b RGB is substantially higher quality than 8b YUV to 8b RGB (especially near white and black), and 10b YUV can decode to higher depth RGB wherever the panel supports it. It sure beats having to deband afterward, or drop in a shedload of noise (and bits) to hide banding. Those with 6b RGB panels will continue to wail, because hardware companies refuse to incorporate simple tricks like dithering on budget hardware until they're promoted as a requirement, but that's can't be helped.

It's true that AV1 and HEVC fixed AVC's rather staggering difference in quality between 8- and 10-bit encoding, but there's still some utility if the toolchain wants to keep quality at the forefront.

[Blue_MiSfit]

Premium content is NOT >=10-bit 4:2:2. 10-bit 4:2:0 is all that anyone is distributing to consumers via streaming and disc.

Of course. That's what I said (specifically referencing masters being >= 10 bit)

[benwaggoner]

Of course. That's what I said (specifically referencing masters being >= 10 bit)Ah, my apologies for the confusion, then.

Sent from my SM-T837V using Tapatalk

[huhn]

There is a significant but shrinking number of devices, mainly handheld, that support 8-bit HEVC but not 10-bit.

More common is devices with 10-bit decoders that then feed into 8-bit compositors, GPUs, or display controllers.
i don't see anything that diminished the benefit of using more bit deep in encoding here.
If nothing else, 8b RGB to 10b YUV to 8b RGB is substantially higher quality than 8b YUV to 8b RGB (especially near white and black), and 10b YUV can decode to higher depth RGB wherever the panel supports it. It sure beats having to deband afterward, or drop in a shedload of noise (and bits) to hide banding. Those with 6b RGB panels will continue to wail, because hardware companies refuse to incorporate simple tricks like dithering on budget hardware until they're promoted as a requirement, but that's can't be helped.

the fact that AMD supports native 6 bit output with there own dithering which helps a lot of sub optimal screens show the benefit of doing this correctly.
the best panel i have ever tested in term of banding is a 6 bit FRC panel the processing just doesn't add banding on such a "bad" device.

and i totally agree using more bits in encoding to delay the dithering until the end device or at least the presentation of a device is a clear benefit.

just reading about 4:2:2 master is letting me wonder if this is just a bad habit that simple didn't stop instead of 16 RGB or higher even the aged BBB has this as a master and what reason could be there not to do that.

[Blue_MiSfit]

I always figured the 10 bit 4:2:2 thing most likely goes back to SDI / HD-SDI which was traditionally 10 bit 4:2:2. Capturing the full bandwidth of this signal into a file based format in a way that's perceptually lossless was long since considered "good enough" and widely used mezzanine file formats like ProRes do a great job of this - especially relative to the old days of 50-80 Mbps 1080p MPEG-2 service masters.

Given the context of final distribution always being 8 bit 4:2:0 until recently, perceptually lossless 10 bit 4:2:2 was indeed always good enough.

Now that we're doing HDR, 10 bit is mandatory, and 12 or even 16 bit (ProRes 4444 / 4444 XQ or JPEG 2000) is common for source material when encoding for Dolby Vision. Sure, this gets shaped into a 10 bit IPT file but allegedly more of the input can be recovered after Dolby magic.

Studio archival masters are generally 16 bit full range RGB TIFFs or the OpenEXR equivalent (not sure about the specifics of that), and probably DPX for older stuff. Maybe 16 bit lossless JPEG 2000 if the studio is IMF native.

[hajj_3]

New rav1e build released with 20% speed improvement: https://github.com/xiph/rav1e/releases/tag/p20191215

[hajj_3]

Rav1e 0.2.0 released, 40-70% faster than than v0.1.0 depending on the encoding settings.

changelog:
Optional serialization/deserialization of the encoding parameters through the feature serialize
Optional cli advanced commands to use it.
The builds are now using the dwarf debug format for the targets that support it, before it was a mixture of dwarf and stabs due to the nasm defaults.
Added a --benchmark hidden flag for the cli for MacOS and Linux.
documentation is now available on docs.rs.
Changes
Segmentation support is now a tunable SpeedSetting and currently it is default off since it can produce desyncs, this does cause a 3% decrease in quality.
Fixes
#1903 - edge-of-frame miscomputation
#1858 - desync on speed 0 and 1 when certain quantizers are selected
Known issues
#1930 - segmentation encoding may cause desync

[Mr_Khyron]

SVT-AV1 0.8 is out
https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.8.0

x Preset Optimizations
x Single-core execution memory optimization [-lp 1 -lad 0]
x Rate estimation update enhancements
x On / off flags for feature run-time switching
x Auto-max partitioning algorithm support
x Multi-pass partitioning depth support
x Remove deprecated RC mode 1 and shifter RC mode 2 and mode 3 to mode 1 and mode 2 respectively
x Update cost calculation for CDEF Filtering
x Intra-Inter compound for 10-bit
x Eigth-pel optimization
x AVX512 Optimizations
x AVX2 Optimizations

[SmilingWolf]

Status report!
"Padoru padoru!" edition

1st edition: https://forum.doom9.org/showthread.php?p=1852449#post1852449
2nd edition: https://forum.doom9.org/showthread.php?p=1857587#post1857587
3rd edition: https://forum.doom9.org/showthread.php?p=1860475#post1860475
4th edition: https://forum.doom9.org/showthread.php?p=1871939#post1871939
5th edition: https://www.reddit.com/r/AV1/comments/cfao4x/codecs_performance_report_5th_and_a_half_edition/
Whatever paragraph I don't repeat here can be assumed to be the same as in the aforementioned post

First of all: graphs!
Click to enlarge

Y axis: chosen metric
X axis: bits per pixel

720p:
https://i.ibb.co/jVQm93Q/hvmaf-720.png (https://ibb.co/jVQm93Q) https://i.ibb.co/T0R7ydf/msssim-720.png (https://ibb.co/T0R7ydf) https://i.ibb.co/ysNYgg4/psnrhvsm-720.png (https://ibb.co/ysNYgg4)

1080p:
https://i.ibb.co/gJ5c6Qs/hvmaf-1080.png (https://ibb.co/gJ5c6Qs) https://i.ibb.co/SQkMnXL/msssim-1080.png (https://ibb.co/SQkMnXL) https://i.ibb.co/2vx59Sq/psnrhvsm-1080.png (https://ibb.co/2vx59Sq)

BD rates for 720p:
Codecs ladder: | x264 relative:
x264 -> rav1e | x264 -> rav1e
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -23.2215 1.01158 | MSSSIM -23.2215 1.01158
PSNRHVS -24.4172 1.36951 | PSNRHVS -24.4172 1.36951
HVMAF -15.8889 1.38478 | HVMAF -15.8889 1.38478
----------------------------|----------------------------
rav1e -> svtav1 | x264 -> svtav1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -5.56998 0.20639 | MSSSIM -28.4361 1.23111
PSNRHVS -6.41119 0.290801 | PSNRHVS -30.1248 1.65609
HVMAF -15.6008 1.20241 | HVMAF -29.5127 2.45437
----------------------------|----------------------------
svtav1 -> vp9 | x264 -> vp9
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM 4.20075 -0.151838 | MSSSIM -25.2711 1.10719
PSNRHVS 4.84265 -0.215506 | PSNRHVS -26.5998 1.48648
HVMAF -1.42341 -0.19208 | HVMAF -29.8597 2.33372
----------------------------|----------------------------
vp9 -> x265 | x264 -> x265
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -1.31186 0.0508852 | MSSSIM -26.3349 1.18403
PSNRHVS -5.36837 0.2586 | PSNRHVS -30.5296 1.7606
HVMAF -1.84033 0.341593 | HVMAF -30.9904 2.59114
----------------------------|----------------------------
x265 -> av1 | x264 -> av1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -23.2948 0.961133 | MSSSIM -43.3907 2.06939
PSNRHVS -18.5938 0.914589 | PSNRHVS -43.484 2.58526
HVMAF -19.3808 1.25801 | HVMAF -44.4219 3.59302

BD rates for 1080p:
Codecs ladder: | x264 relative:
x264 -> rav1e | x264 -> rav1e
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -32.2826 1.19743 | MSSSIM -32.2826 1.19743
PSNRHVS -30.8004 1.43869 | PSNRHVS -30.8004 1.43869
HVMAF -24.0161 1.68074 | HVMAF -24.0161 1.68074
----------------------------|----------------------------
rav1e -> svtav1 | x264 -> svtav1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -7.09315 0.212708 | MSSSIM -37.5209 1.44372
PSNRHVS -6.91838 0.253513 | PSNRHVS -36.0074 1.70477
HVMAF -14.4798 1.05647 | HVMAF -34.513 2.60239
----------------------------|----------------------------
svtav1 -> vp9 | x264 -> vp9
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM 1.75731 -0.0570674 | MSSSIM -36.6065 1.39502
PSNRHVS 0.61474 -0.0275689 | PSNRHVS -35.7951 1.68578
HVMAF -5.87037 0.0512821 | HVMAF -38.5344 2.64173
----------------------------|----------------------------
vp9 -> x265 | x264 -> x265
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM 9.95155 -0.292103 | MSSSIM -30.4864 1.15663
PSNRHVS 4.66281 -0.165867 | PSNRHVS -32.9136 1.56443
HVMAF 5.65708 -0.054123 | HVMAF -34.5119 2.53192
----------------------------|----------------------------
x265 -> av1 | x264 -> av1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -31.9542 1.15077 | MSSSIM -52.2509 2.19044
PSNRHVS -26.5316 1.11388 | PSNRHVS -50.3241 2.54395
HVMAF -22.5904 1.34136 | HVMAF -49.1759 3.58479

Encoders:
x264 158-2984-3759fcb
x265 3.2-7-37648fca915b
libvpx-vp9 1.8.2-23-g50d1a4aa7
rav1e 0.2.0-32-g350ac84
SVT-AV1 0.8.0-5303-0952998d
libaom 1.0.0-60-g3e421b069

Cmdlines:
echo -n "16 19 22 26 29 32" | xargs -d " " -n 1 -P 1 -I {} x264 --preset veryslow --tune ssim --crf {} -o test.x264.crf{}.264 orig.i420.y4m
echo -n "16 20 23 27 30 34" | xargs -d " " -n 1 -P 1 -I {} x265 --preset veryslow --tune ssim --crf {} -o test.x265.crf{}.hevc orig.i420.y4m
echo -n "12 21 30 38 47 56" | xargs -d " " -n 1 -P 6 -I {} vpxenc --codec=vp9 --frame-parallel=0 --tile-columns=0 --auto-alt-ref=6 --good --cpu-used=0 --tune=psnr --passes=2 --threads=1 --end-usage=q --cq-level={} --test-decode=fatal --ivf -o test.vp9.cq{}.ivf orig.i420.y4m
echo -n "030 056 082 108 134 160" | xargs -d " " -n1 -P6 -I {} rav1e -o test.rav1e.cq{}.ivf --quantizer {} -s 5 --tune Psychovisual orig.i420.y4m
echo -n "13 21 29 37 45 53" | xargs -d " " -n1 -P1 -I{} SvtAv1EncApp.exe -i orig.i420.yuv -b test.svtav1.cq{}.ivf -w 1280 -h 720 -q {} -scm 0 -enc-mode 8 -fps-num 24000 -fps-denom 1001 -intra-period 47 -output-stat-file fp_stats{}.stat -enc-mode-2p 3
echo -n "13 21 29 37 45 53" | xargs -d " " -n1 -P1 -I{} SvtAv1EncApp.exe -i orig.i420.yuv -b test.svtav1.cq{}.ivf -w 1280 -h 720 -q {} -scm 0 -enc-mode 3 -fps-num 24000 -fps-denom 1001 -intra-period 47 -input-stat-file fp_stats{}.stat
echo -n "12 21 30 38 47 56" | xargs -d " " -n 1 -P 3 -I {} aomenc --frame-parallel=0 --tile-columns=0 --auto-alt-ref=1 --cpu-used=3 --passes=2 --threads=2 --row-mt=1 --end-usage=q --cq-level={} -o test.av1.cq{}.webm orig.i420.y4m
VMAF: model used: vmaf_b_v0.6.3, pooling: harmonic_mean, bagging score (arithmetic mean of 21 models' scores)

Start-to-end times:
x264: 0 hours, 34 minutes and 58 seconds
x265: 4 hours, 13 minutes and 57 seconds
libvpx-vp9: 3 hours, 17 minutes and 52
rav1e: 9 hours, 8 minutes and 25 seconds
SVT-AV1: 5 hours, 6 minutes and 13 seconds
libaom: 7 hours, 26 minutes and 5 seconds

This concludes this report.
As always, I'm open to any kind of feedback to improve my comparisons and my encodes.

[foxyshadis]

Good to see that VMAF-wise, SVT-AV1 has reached parity with vpxenc and x265, at least for 8-bit, and is only a little slower than x265. That's a pretty big milestone, and the codebase is still in a lot of flux, so there's probably some headroom.

BTW, SVT has supported y4m for a long time now, they just haven't updated their readme.The encoder guide in general is pretty outdated, but I want to see where the holiday cleanup goes before I send pull requests.

[Nintendo Maniac 64]

Phoronix benchmarked SVT-AV1 v0.8 on a variety of CPUs (i7, i9, Xeon, Ryzen, Threadripper, Epyc):

https://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-AV1-0.8-Benchmarks

[ts1]

SmilingWolf, have you made any tweaks to PSNRHVS? AFAIK by default cweight is set to 1, that's too high, set it to 0.125.
Or just use this (https://bugs.chromium.org/p/aomedia/issues/attachmentText?aid=426755) already tweaked and improved version from libaom (only with this version first video must be original and distorted is second).

[VincAlastor]

SVT-AV1 0.8 is out
https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.8.0
Hello thank you for the update notification.

I have experimented with the SVT-AV1 encoder. Except that the cmd windows in staxrip freezes after 10.000 frames (but the encoding continues), there is a big problem.

I muxed the finished elementary stream in mkv. If I now play it and jump back or forward for more than 5 min, the player (with current LAVfilters) needs a lot of time until the playback continues.

If I download a youtube AV1 video in mp4 container the player doesn't need too much time to skip.

However, mp4box does not want to mux .opus streams, so I cannot really use the mp4 container. Do you have a solution?

ffmpeg -i -nostdin -f rawvideo -pix_fmt yuv420p - | SvtAv1EncApp.exe -i stdin -fps-num 24000 -fps-denom 1001 -n 548203 -w 1920 -h 816 -enc-mode 6 -q 48 -b


edit:
if i mux youtube AV1 mp4 into mkv, i also can skip fast trough the file. So is there a SVT-AV1 bug?

[fg118942]

Hello thank you for the update notification.

I have experimented with the SVT-AV1 encoder. Except that the cmd windows in staxrip freezes after 10.000 frames (but the encoding continues), there is a big problem.

I muxed the finished elementary stream in mkv. If I now play it and jump back or forward for more than 5 min, the player (with current LAVfilters) needs a lot of time until the playback continues.

If I download a youtube AV1 video in mp4 container the player doesn't need too much time to skip.

However, mp4box does not want to mux .opus streams, so I cannot really use the mp4 container. Do you have a solution?

ffmpeg -i -nostdin -f rawvideo -pix_fmt yuv420p - | SvtAv1EncApp.exe -i stdin -fps-num 24000 -fps-denom 1001 -n 548203 -w 1920 -h 816 -enc-mode 6 -q 48 -b


edit:
if i mux youtube AV1 mp4 into mkv, i also can skip fast trough the file. So is there a SVT-AV1 bug?

Try adding "-irefresh-type 2" to the command line.

[VincAlastor]

Try adding "-irefresh-type 2" to the command line.

thank you very much. That parameter was very helpful.

But let's hope we don't need it long, because open GOPs are more efficiently pretty sure.

[foxyshadis]

thank you very much. That parameter was very helpful.

But let's hope we don't need it long, because open GOPs are more efficiently pretty sure.

That's a decoder bug; open GOPs don't need to decode previous GOPs, but dav1d is still pretty new. Anyway, open GOPs only give you noticeable gains if you have a very short GOP. Of course, SVT-AV1 has disabled scene detection and the default (-2) is at as close to 1s as possible anyway.

Just using a longer GOP will help much more.

[Beelzebubu]

That's a decoder bug [..] but dav1d is still pretty new

No, it's a player or file bug. The player likely selects keyframes from the index (in Mkv parleance: seekhead), and for whatever reason, the muxer didn't add invisible keyframes (non-IDR in AV1) to the index (i.e. broken file), or the demuxer (player) doesn't recognize them and ignores them.

dav1d simply decodes frames in order presented by the player (along with some reordering etc.), it cannot seek further back by itself.

[VincAlastor]

No, it's a player or file bug. The player likely selects keyframes from the index (in Mkv parleance: seekhead), and for whatever reason, the muxer didn't add invisible keyframes (non-IDR in AV1) to the index (i.e. broken file), or the demuxer (player) doesn't recognize them and ignores them.

dav1d simply decodes frames in order presented by the player (along with some reordering etc.), it cannot seek further back by itself.

Friends and me experimented last week with SVT-AV1 files - more than one, in many players with different versions of filters and mkvtoolnix. The only thing what solve the problem was disabling open GOPs for now. Please try, hope you can show us a solution to use SVT-AV1 with default open GOPs.

[Spyros]

LG announced (http://www.lgnewsroom.com/2020/01/lg-to-unveil-2020-real-8k-tv-lineup-featuring-next-gen-ai-processor-at-ces-2020/) that their new 8K TVs will support AV1.

Not only do LG 8K TVs deliver Real 8K, they are also future-proofed to provide customers peace of mind with multiple ways to enjoy the Real 8K experience. The new models offer the capability to play native 8K content thanks to support of the widest selection of 8K content sources from HDMI and USB digital inputs, including codecs such as HEVC, VP9 and AV1, the latter being backed by major streaming providers including YouTube. LG’s 8K TVs will support 8K content streaming at a rapid 60FPS and are certified to deliver 8K 60P over HDMI.


As far as I know these are the first TVs with AV1 hardware decoding. I wonder if they will also support Opus.

[birdie]

LG announced (http://www.lgnewsroom.com/2020/01/lg-to-unveil-2020-real-8k-tv-lineup-featuring-next-gen-ai-processor-at-ces-2020/) that their new 8K TVs will support AV1.


As far as I know these are the first TVs with AV1 hardware decoding. I wonder if they will also support Opus.

These TVs will feature quite powerful SoCs and Opus is a very low complexity codec, so I see no reason not to support it.

Besides, YouTube started using it years ago along with VP9 and each device which supports YT must support Opus by default.

[Spyros]

Samsung will also support AV1 (https://news.samsung.com/global/samsung-electronics-unveils-2020-qled-8k-tv-at-ces):

At the same time, the QLED 8K lineup is among the first in the industry to support the playback of native 8K content. In 2020, consumers will be able to enjoy and stream AV1 codec videos filmed in 8K on QLED 8K TVs. All Samsung TVs in the 2020 8K line will ship with this capability built-in.



These TVs will feature quite powerful SoCs and Opus is a very low complexity codec, so I see no reason not to support it.

Besides, YouTube started using it years ago along with VP9 and each device which supports YT must support Opus by default.

That's true, thanks to Youtube (and all the other streaming services that will follow) manufacturers have reason to support both codecs.

My previous message was based on seeing Samsung support VP9 but only Vorbis (https://developer.samsung.com/tv/develop/specifications/media-specifications/2019-tv-video-specifications), not Opus (as of 2019), but I was wrong. This is only for the .webm container, Opus is already supported in .mp4, .mkv etc. I don't know if LG has similar documentation somewhere.

[soresu]

These TVs will feature quite powerful SoCs and Opus is a very low complexity codec, so I see no reason not to support it.

Besides, YouTube started using it years ago along with VP9 and each device which supports YT must support Opus by default.

I think he may have meant ASIC support?

As you say it's low complexity so it wouldn't require an ASIC to run it in a wall powered device like a high end 4K TV, but anything that reduces thermal output is welcome, it's annoying hearing a fan coming from a TV.

[Atak_Snajpera]

Does aomenc really support piping from ffmpeg?

my cmd line (simplified)
ffmpeg.exe -loglevel panic -i 1.avs -strict -1 -f yuv4mpegpipe - | aomenc.exe --cq-level=20 --cpu-used=3 --skip=0 --limit=1343 --kf-min-dist=0 --kf-max-dist=240 --output=1.ivf -


No ETA and crash at the end.
https://i.postimg.cc/44PWn9yw/Capture.png

[poisondeathray]

Does aomenc really support piping from ffmpeg?

2pass definitely works ok for yuv4mpegpipe or rawvideo pipe - so the pipe works

I haven't done 1pass encoding with aomenc, but that suggests something wrong with the 1pass syntax

EDIT: try adding --end-usage=cq --passes=1 , that completes works here for 1pass

[utack]

Does aomenc really support piping from ffmpeg?

No ETA and crash at the end.


As of recently I have also had it crash at the very end, and the last few frames of the stream never got encoded
Current git version on linux
I will try to reproduce it and see where it started

[Atak_Snajpera]

2pass definitely works ok for yuv4mpegpipe or rawvideo pipe - so the pipe works

I haven't done 1pass encoding with aomenc, but that suggests something wrong with the 1pass syntax

EDIT: try adding --end-usage=cq --passes=1 , that completes works here for 1pass

Ok thanks. Those two extra switches solve my issue.

[benwaggoner]

I think he may have meant ASIC support?

As you say it's low complexity so it wouldn't require an ASIC to run it in a wall powered device like a high end 4K TV, but anything that reduces thermal output is welcome, it's annoying hearing a fan coming from a TV.
Vorbis is quite low complexity. The CPUs in SoCs that can do AV1 decode will have ample power to decode Opus in a small fraction of available MIPS.

A bigger challenge can be if the SW audio decoder is integrated into the DRM system, which is sometimes hinky.

That said, xHE-AAC support is growing rapidly and has or will eclipse Opus's. Since it's just a new feature of the AAC porting kit, it'll get deeper integration in many cases.

I'm really impressed that we already have TVs launching with these specs for AV1. I'd love to know how much the SoC had to get bigger for that AV1 support. The extra transistors required for AV1 support is a really important factor in AV1's market viability.

[Blue_MiSfit]

Do you usually have to encrypt audio? I usually get a pass on that, specifically since the lower security of the audio path mandates multi key (to avoid stealing the audio key and using it for the video) and that's tricky on a lot of platforms.

I want to use Opus today, but the spec for putting it in fMP4 and using it in DASH are not finished (last I checked)! I even whined about this but sounds like there's not a ton of motivation to finish it, which is a real shame.

[benwaggoner]

Do you usually have to encrypt audio? I usually get a pass on that, specifically since the lower security of the audio path mandates multi key (to avoid stealing the audio key and using it for the video) and that's tricky on a lot of platforms.
The need to encrypt audio is becoming less common overall. But some platforms have had perf issues mixing encrypted and non encrypted media at the same time. And encryption would be required for high quality streaming audio.

I want to use Opus today, but the spec for putting it in fMP4 and using it in DASH are not finished (last I checked)! I even whined about this but sounds like there's not a ton of motivation to finish it, which is a real shame.
I think xHE-AAC has stolen Opus's thunder, since the licensing and code is free for any AAC licensee. Plus it outperforms Opus some.