x266 VVC Encoder

[benwaggoner]

Originally Posted by kurkosdr

The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.

It's impossible to extrapolate without knowing how the other encoders were tuned. The "twice as good as HEVC" seems really, really implausible, particularly given that we have much more mature HEVC encoders available, like x265.

As always: https://web.archive.org/web/20141103...x/archives/472

[benwaggoner]

Originally Posted by kurkosdr

The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.

Based on codec features, yeah, I suspect an equivalently well optimized EVC Baseline could outperform x264.

x264 has a crazy amount of optimization for a wide variety of use cases and content types, so making something in x264's ballpark is pretty monumental class. x265 itself got a big head start by building on top of x264's source code and algorithms.

[birdie]

Multicoreware Inc. claims the x266 encoder is not dead while providing zero new information about the state of its development.

[soresu]

Mmmph, sounds like they probably had little interest in putting any significant resource into x266, until they saw the AV2 announcement and got spooked.

[rwill]

Hey if you need some samples of what EVC Baseline is capable of just drop a request with the link to the (clean plz) source here.

[LigH]

I remember Jamaika providing xeve/xevd for a longer while, and MABS can compile it and link it into ffmpeg. But EVC is somewhere in between, by far not as complex as VVC.

[rwill]

Originally Posted by LigH

I remember Jamaika providing xeve/xevd for a longer while, and MABS can compile it and link it into ffmpeg. But EVC is somewhere in between, by far not as complex as VVC.

Was this in response to my post? Because I would not use xeve to encode.

[LigH]

Yes.

Is there any serious reason why you discourage the use of xeve?

[rwill]

Xeve is untuned and is missing a lot of things state of the art encoders have.

[Z2697]

Originally Posted by rwill

Was this in response to my post? Because I would not use xeve to encode.

Is it your in-house encoder? Could you perhaps drop *cough* *cough* an executable?

Unlikely things aside, I think Big Buck Bunny or Tears of Steel is good for a "widedly accepted benchmark".

[LigH]

I would like to suggest to continue talk about EVC in the related thread:

EVC - Essential Video Coding / MPEG-5

But I am no moderator. So it is just a private suggestion...

[rwill]

So, I encoded that Tears of Steel and Stem2 linked in Bens HEVC Encoding Challenge thread with my EVC Encoder with the settings we agreed on there.

Here are the results:

Stem2: https://drive.google.com/file/d/1O3g...ew?usp=sharing

Tears of Steel: https://drive.google.com/file/d/1Oxh...ew?usp=sharing

So the fanbois can wait until x265 and maybe x266 reach that kind of quality stability - if ever.

Did I mention that my encoders are developed for "to scale" so that they fix quality problems themselves in later passes when doing multipass? Just start the job and fetch the expected result later. No more handcrafted streams. Long way to go for some certain other encoder developer I guess.


So because its EVC, to play the streams in realtime in a player, the most easiest way is to convert them to a playable format like AVC or HEVC.
With xevd, x265 and mp4box being freely available one way to do it, for Stem2, would look like this:

xevdb_app.exe -i stem2_3840x2160_4mbit.evc -s --output-bit-depth 10 -o dec_3840x2160_10b.yuv

./x265-10b.exe --input dec_3840x2160_10b.yuv --input-res 3840x2160 --input-depth 10 --fps 24000/1001 --sar 1 --hrd --aud --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --max-cll "10000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --preset slow --tune ssim --crf -8.0 -b 3 --b-pyramid --b-adapt 0 --ssim --psnr -o temp.265

mp4box -add temp.265 -new stem2_3840x2160_4mbit_playable.mp4

There will be a small generational loss but nothing big.

[Z2697]

Originally Posted by rwill

So, I encoded that Tears of Steel and Stem2 linked in Bens HEVC Encoding Challenge thread with my EVC Encoder with the settings we agreed on there.

Here are the results:

Stem2: https://drive.google.com/file/d/1O3g...ew?usp=sharing

Tears of Steel: https://drive.google.com/file/d/1Oxh...ew?usp=sharing

So the fanbois can wait until x265 and maybe x266 reach that kind of quality stability - if ever.

Did I mention that my encoders are developed for "to scale" so that they fix quality problems themselves in later passes when doing multipass? Just start the job and fetch the expected result later. No more handcrafted streams. Long way to go for some certain other encoder developer I guess.


So because its EVC, to play the streams in realtime in a player, the most easiest way is to convert them to a playable format like AVC or HEVC.
With xevd, x265 and mp4box being freely available one way to do it, for Stem2, would look like this:

xevdb_app.exe -i stem2_3840x2160_4mbit.evc -s --output-bit-depth 10 -o dec_3840x2160_10b.yuv

./x265-10b.exe --input dec_3840x2160_10b.yuv --input-res 3840x2160 --input-depth 10 --fps 24000/1001 --sar 1 --hrd --aud --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --max-cll "10000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --preset slow --tune ssim --crf -8.0 -b 3 --b-pyramid --b-adapt 0 --ssim --psnr -o temp.265

mp4box -add temp.265 -new stem2_3840x2160_4mbit_playable.mp4

There will be a small generational loss but nothing big.

I'm not sure there's much fanboism going on. It's just what we got, unless you can release your encoders.

XEVD does support y4m output though, if the space is not a concern (probably, your commands are using YUV medium file already) we can output Y4M and directly play it.
When you are doing your own testing, do you have better ways to play it, maybe some industiral hardware, or your secret sauce decoder?

And what's the "fix quality problems themselves" really mean? Doesn't the x264 multipass already fix some problems with single pass ABR?

[rwill]

Originally Posted by Z2697

I'm not sure there's much fanboism going on. It's just what we got, unless you can release your encoders.

Well or the community bands together again, forks x265 or starts fresh, and make something truly open source. Its really sad, I know quite some people that would be able to contribute to x265 but won't due to Multicorewares contribution policy.

Originally Posted by Z2697

XEVD does support y4m output though, if the space is not a concern (probably, your commands are using YUV medium file already) we can output Y4M and directly play it.
When you are doing your own testing, do you have better ways to play it, maybe some industiral hardware, or your secret sauce decoder?

I do not recommend to play back the raw file because harddrives are kinda slow. I also do not recommend to write raw video on SSDs because of their wear level. When the players I use do not support a format I, most of the time, use shorter clips where the raw video fits into RAM and I play that without lag.

Originally Posted by Z2697

And what's the "fix quality problems themselves" really mean? Doesn't the x264 multipass already fix some problems with single pass ABR?

The goal is that each additional pass makes the result better in regards to VBV constrained bit distribution problems and converging to a consistent quality target for the whole sequence while removing artifacts that might be perceived as disrupting. Now most amateur users of x264/x265 don't care about VBV and CRF bitrate control is producing ok'ish consistent quality. Problems arise with x26x when trying to do professional encodes that have certain constraints. Professional employees are paid by the hour so tweaking video settings to work around a quality problem, which can take hours or even days, is to be avoided.

[LigH]

Is there any sane reason to post all of this in a thread about a future x266 encoder despite EVC not being VVC even, instead of in a thread about EVC?

[rwill]

Originally Posted by LigH

Is there any sane reason to post all of this in a thread about a future x266 encoder despite EVC not being VVC even, instead of in a thread about EVC?

Hausmeister.