x266 VVC Encoder

[LigH]

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

EVC - Essential Video Coding / MPEG-5 (https://forum.doom9.org/showthread.php?t=176055)

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/1O3gvz0M_w6958dnYB0ZFHYSxX3azXlQU/view?usp=sharing

Tears of Steel: https://drive.google.com/file/d/1OxhckgOvOiND5AsvfNMLIN0ufmp9skBo/view?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]

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/1O3gvz0M_w6958dnYB0ZFHYSxX3azXlQU/view?usp=sharing

Tears of Steel: https://drive.google.com/file/d/1OxhckgOvOiND5AsvfNMLIN0ufmp9skBo/view?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]

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.


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.


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]

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.