Benwaggoner HEVC encoding challenge [Archive]

View Full Version : Benwaggoner HEVC encoding challenge

benwaggoner

1st October 2018, 19:57

Forteen88

2nd October 2018, 07:43

Thanks. But why not set this? --profile main10
10-bits might help a little with banding maybe.
Is there any reason not to set --profile main10 in x265? Most of latest years GPU:s supports 10-bit H.265-decoding partially or fully.

EDIT: OK, thanks Blue_MiSfit, although watching video at this high resolution on an Android phone (small screen) is just wasteful.

Blue_MiSfit

2nd October 2018, 09:09

Older devices with early HEVC decoders?

I know some FireTV devices and Android phones are 8 bit only :(

smok3

2nd October 2018, 10:50

I like the chalenge, but the source is something i don't want to watch, any other possible candidates?

benwaggoner

2nd October 2018, 16:37

I like the chalenge, but the source is something i don't want to watch, any other possible candidates?
Sure. Anything that's publicly available and has an appropriate license.

I like Tears of Steel as something that's reasonably short that has a variety of appropriate characteristics. Live action, CGI, film grain, motion graphics in credits.

Any test is going to be somewhat arbitrary and focused on a particular scenario. The one here is very much about encoder features at least as much as bitstreams. It stresses psychovisual tuning and rate control, and ignores encoding performance.

An obvious followup test would be 1-pass CBR with fixed 2 second Closed GOP.

Something incorporating quality @ perf would be interesting, but it's way harder to compare and verify performance.

benwaggoner

2nd October 2018, 16:43

Thanks. But why not set this? --profile main10
10-bits might help a little with banding maybe.
Is there any reason not to set --profile main10 in x265? Most of latest years GPU:s supports 10-bit H.265-decoding partially or fully.

One big reason for me is that comparing 10-bit encodes is a lot harder, since different setups can use very different conversion methods. Something that gets a nice dither on one platform might get banding due to truncation on another. Sticking to 8-bit reduces

Also, I wanted to be able to compare 8-bit only codecs.

I'd love to do a HDR-10 test as a followup. I've not found good HDR test content with an appropriate license yet, though.

EDIT: OK, thanks Blue_MiSfit, although watching video at this high resolution on an Android phone (small screen) is just wasteful.
Yeah, this is really meant for bigger screens. A 250-500 Kbps SD version would an interesting followup test. Among other things, it would make getting an AV1 encode a lot more feasible.

K.i.N.G

8th October 2018, 20:30

I'd love to do a HDR-10 test as a followup. I've not found good HDR test content with an appropriate license yet, though.

You can get the source files (which include 32 bit exr files) from the Tears of Steel project.
It's all open source...

https://media.xiph.org/tearsofsteel/

Sparktank

8th October 2018, 20:58

You can get the source files (which include 32 bit exr files) from the Tears of Steel project.
It's all open source...

https://media.xiph.org/tearsofsteel/

AFAIK, TOS hasn't been upgraded for HDR.
It's all SDR.

You can find custom edits on youtube where users graded it themselves.

K.i.N.G

8th October 2018, 21:02

AFAIK, TOS hasn't been upgraded for HDR.
It's all SDR.

Thats why I mention the exr files and not the actual exported movie...
The source files are exr which are 32bit (or 16bit at worst, but standard exr is 32bit) thus you can safely grade/master them to 10 HDR, even 12bit if you want. There's plenty of dynamic range/headroom.

I'm not sure in which format the actual filmed/video parts are available though... I'm quite busy so i haven't checked.
I suppose they are in raw format with sufficient dynamic range aswell... but that would be a guess

benwaggoner

10th October 2018, 04:13

Thats why I mention the exr files and not the actual exported movie...
The source files are exr which are 32bit (or 16bit at worst, but standard exr is 32bit) thus you can safely grade/master them to 10 HDR, even 12bit if you want. There's plenty of dynamic range/headroom.
I looked into this a few years back. While we have lots of precision in the source, it was all graded and rendered for 709 SDR. One could probably use those assets to remaster it to HDR, but that would require regrading, rerendering the CGI stuff, and recompositing. Feasible, certainly, and a lot less work than doing a project from scratch. But still a sizable effort to make it look like "Real" HDR, and that's even assuming they did the RAW acquisition preserving the highlights and such.

I've been involved in a number of HDR remastering projects, and doing it well is quite a lot of effort. Particularly for something as CGI-centric as Tears of Steel.

K.i.N.G

15th October 2018, 10:12

I looked into this a few years back. While we have lots of precision in the source, it was all graded and rendered for 709 SDR. One could probably use those assets to remaster it to HDR, but that would require regrading, rerendering the CGI stuff, and recompositing. Feasible, certainly, and a lot less work than doing a project from scratch. But still a sizable effort to make it look like "Real" HDR, and that's even assuming they did the RAW acquisition preserving the highlights and such.

The 32bit exr's that are available seem to have the 709 grading baked in indeed (which is weird) but its not that big of a deal since they kept the dynamic range and full exposure info in there (they aren't clipped). So, no problems there.
Those exr's seem to be saved in 'only' 1080p though...

I've been involved in a number of HDR remastering projects, and doing it well is quite a lot of effort. Particularly for something as CGI-centric as Tears of Steel.

CGI data is pretty much ideal. It doesn't get any better than that.
Of course you always have those people who render everything clipped and bake weird color corrections right into the renders, that's another story. But that also happens with video footage, so no difference in that regard.
CGI with the rec.709 profile baked in is still miles easier to work with than video footage with the camera's color response + some custom curve baked in though.

benwaggoner

15th October 2018, 19:24

The 32bit exr's that are available seem to have the 709 grading baked in indeed (which is weird) but its not that big of a deal since they kept the dynamic range and full exposure info in there (they aren't clipped). So, no problems there.
Those exr's seem to be saved in 'only' 1080p though...

I am sure there are UHD ones as well. I think I downloaded them once some years ago. Maybe off an FTP?

My .y4m was generated from the 16-bit PNG sequence.

[QUOTE]CGI data is pretty much ideal. It doesn't get any better than that.
The final has film grain added to the CGI, but if the EXR is clean plates, awesome!

Of course you always have those people who render everything clipped and bake weird color corrections right into the renders, that's another story. But that also happens with video footage, so no difference in that regard.
CGI with the rec.709 profile baked in is still miles easier to work with than video footage with the camera's color response + some custom curve baked in though.
My understanding is they didn't do anything specific to prevent >>709 things from happening. But they did all the work in 709, so wouldn't have known or worried about if anything in particular was clipped or whatever.

It would be awesome if someone put in the time to do a HDR master! From what you've found so far, it might not even be that big a project. Maybe a day or two for someone with the right skills, software, and hardware. Two days to remastered an hour show to HDR with decent sources is pretty luxurious, and this is only 11 minutes.

But anyway, I'd love to see anyone else's best encodes with the SDR clip, in x265, different HEVC, or even other codecs. In particular, I'd love to see a VP9 expert's best VP9 effort.

jonatans

24th October 2018, 08:06

Hi Ben, great challenge that you have arranged!

Here are encodes with the xvc codec at three different rates:

There is no strict rate control in xvc yet so the margins to the target rates are quite large.

851 kbps: https://drive.google.com/file/d/1xrMoGWVuqj1YS51uSkJCg4mbBToxdQKy/view?usp=sharing (15% under target rate)
1361 kbps: https://drive.google.com/file/d/1cRsdnWZ7gLmE97VDfcCeVo0mIk9p3yIt/view?usp=sharing (9% under target rate)
1924 kbps: https://drive.google.com/file/d/1K46lL6QsG1qhf0Ed_7vod-ZU-bJj7_7M/view?usp=sharing (4% under target rate)

To play the files you need a player with xvc support such as this build of ffplay: https://drive.google.com/file/d/1gyjo8Q2WHrJQZf2fhPbkcT_Z-M3nVioq/view?usp=sharing

The zip file also contains the build of ffmpeg that was used to encode the files using the following command:
ffmpeg.exe -i d:/ToS_1920x800_xdither.y4m -c:v libxvc -speed-mode 2 -qp X -max-keypic-distance 120 -threads 16 enc.mp4
with X being 28, 25 and 23, respectively.

It can be noted that these encodes are single pass, with no lookahead (beyond the 16 picture sub-GOP structure), and that reference pictures are stored with 10-bit precision internally (there is no 8 bit profile of xvc).

I would be happy to hear what people think of it! Thanks!

smok3

24th October 2018, 08:34

jonatans; Tryed with the latest build of mpv (Debian) and I guess that is not yet supported out of the box?

mpv xvc_tos_851kbps.mp4
Playing: xvc_tos_851kbps.mp4
(+) Video --vid=1 (*) ( 1920x800 24.000fps)
Failed to initialize a decoder for codec ''.
Video: no video
No video or audio streams selected.

Exiting... (Errors when loading file)

mpv --version
mpv 0.29.0-75-gda1073c247 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects
built on Wed Oct 24 09:29:52 CEST 2018
ffmpeg library versions:
libavutil 56.19.101
libavcodec 58.33.102
libavformat 58.19.102
libswscale 5.2.100
libavfilter 7.37.100
libswresample 3.2.100
ffmpeg version: N-92246-gc2ac3b8e6

jonatans

24th October 2018, 11:18

jonatans; Tryed with the latest build of mpv (Debian) and I guess that is not yet supported out of the box?

Correct.

In order to play the xvc files you need to use a player with xvc support such as the version of ffplay provided in the zip file I uploaded (https://drive.google.com/file/d/1gyjo8Q2WHrJQZf2fhPbkcT_Z-M3nVioq/view?usp=sharing)

Blue_MiSfit

25th October 2018, 21:52

WOW.

That is quite impressive at 851 Kbps. Like, dramatically better than HEVC.

jonatans

26th October 2018, 07:50

WOW.

That is quite impressive at 851 Kbps. Like, dramatically better than HEVC.

Thanks! :)

ShortKatz

4th November 2018, 19:51

The zip file also contains the build of ffmpeg that was used to encode the files using the following command:
ffmpeg.exe -i d:/ToS_1920x800_xdither.y4m -c:v libxvc -speed-mode 2 -qp X -max-keypic-distance 120 -threads 16 enc.mp4

Hi jonatans, how can I build a version of ffmpeg that supports xvc? I would need it for Mac and would like to include this ffmpeg in my version of HandBrake than. Thanks.

abaxas

5th November 2018, 10:14

Increase me-range (or whatever it's called in x265) for a ultra small increase in quality for a massive increase in encoding time.

Not sure if it applies to x265 but there is an ultra small quality bump for single thread encoding. Noting 4 encodes running on 1 core each will complete much faster than 4x single encodes running on all 4 cores.

Emulgator

7th November 2018, 00:41

Originally Posted by Blue_MiSfit
WOW.
That is quite impressive at 851 Kbps. Like, dramatically better than HEVC.
Second that. That 851kbit/s file blew my socks off. 0.024bit/pixel and perfectly watchable.
Single Hair visible and stays through motion, a little mosquito around titles
the girl's moving robotic arm pulls only minimum morphing artefacts through the leaves.
Giving bitrate of 1921 even that arm's morphing wake is almost gone, titles mosquito improve,
not missing any detail from a good blu-ray encode...
How was encoding time if I may ask ?

BTW, back in 2009 DS had test-encoded Big Buck Bunny with x264 Build 999+1 at around 0.03bpp,
yielding good results, but BBB is not as challenging as TOS motionwise, good parts of the picture stay static in BBB..
https://forum.doom9.org/showthread.php?p=1247874&highlight=considered+low#post1247874

jonatans

7th November 2018, 11:15

Hi jonatans, how can I build a version of ffmpeg that supports xvc? I would need it for Mac and would like to include this ffmpeg in my version of HandBrake than. Thanks.

Thanks ShortKatz. It would be great if you can include support for xvc in your HandBrake version. We have made the ffmpeg version available here: https://github.com/perher/FFmpeg/tree/release/4.0-xvc

We will also push some changes, probably later today, to the xvc repo (https://github.com/divideon/xvc) with the most recent modifications related to the binding with ffmpeg. I will let you know when it's available and provide some instructions for building.

jonatans

7th November 2018, 11:27

Second that. That 851kbit/s file blew my socks off.

Thanks! :)

How was encoding time if I may ask ?

I didn't capture the exact encoding time but if I recall correctly it was in the order of 24 hours per encode on my 4-core laptop (which would correspond to an average encoding speed of 0.2 fps).

jonatans

8th November 2018, 11:43

The xvc repo has been updated with the latest changes related to integration with ffmpeg: https://github.com/divideon/xvc/commits/master

As mentioned in an earlier post, the ffmpeg version with xvc support is available here: https://github.com/perher/FFmpeg/tree/release/4.0-xvc

That ffmpeg version can be built using the normal process (e.g. as described at https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu) with the additional steps of checking out and building xvc:
cd ~/ffmpeg_sources && \
git -C xvc pull 2> /dev/null || git clone --depth 1 https://github.com/divideon/xvc && \
mkdir xvc_build && \
cd xvc_build && \
PATH="$HOME/bin:$PATH" cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$HOME/ffmpeg_build" -DBUILD_TESTS=OFF ../xvc && \
PATH="$HOME/bin:$PATH" make && \
make install

And then add --enable-libxvc when building ffmpeg.

We have not tested integration with HandBrake which as far as I understand would require creation of a new module definition for xvc in HandBrake's contrib folder.

Atak_Snajpera

10th November 2018, 17:27

I didn't capture the exact encoding time but if I recall correctly it was in the order of 24 hours per encode on my 4-core laptop (which would correspond to an average encoding speed of 0.2 fps).
Cool now we just need dual EPYC (ROME) 128C/256T and we can start thinking about encoding our movie collections with amazing ~7 fps ... ;)

benwaggoner

12th November 2018, 18:50

Cool now we just need dual EPYC (ROME) 128C/256T and we can start thinking about encoding our movie collections with amazing ~7 fps ... ;)
THAT would be an amazing degree of parallelization!

Wishbringer

13th November 2018, 11:10

With mentioned settings in 1st post, that parallelization isn't possible.
Hanging at 50% utilization with an Ryzen 2700x
Increased to 95% with -ctu 32 and -merange 26 (at FullHD).
The highend quality settings aren't optimized for parallelism.

Edit: oops xvc, not x265... sorry (have no experience with xvc, maybe parallelization is there much better)

Atak_Snajpera

13th November 2018, 15:24

THAT would be an amazing degree of parallelization!

Easy if you divide movie in chunks...

benwaggoner

13th November 2018, 17:12

Easy if you divide movie in chunks...
There are a lot of downsides to doing a lot of chunks on a small clip without a reasonably sophisticated control system. Generally fixed Closed GOPs. And VBV around the stitch points has to be conservative.

Obviously it CAN be done, but it limits the peak efficiency somewhat.

benwaggoner

16th November 2018, 18:24

Thanks! :)
I didn't capture the exact encoding time but if I recall correctly it was in the order of 24 hours per encode on my 4-core laptop (which would correspond to an average encoding speed of 0.2 fps).
That's about the encoding time I got on a 6-core system using --preset placebo --subme 7 --cu-lossless --tskip --me sea

I'll do a test encode to the same ABR this weekend with all the whistles on and see what x265 can do. Probably not as good, but it'd be nice to have an apples-to-apples comparison.

Still hoping someone will provide their best-effort AV1 and/or VP9 encodes!

SmilingWolf

17th November 2018, 10:14

Still hoping someone will provide their best-effort AV1 and/or VP9 encodes!

I could try a VP9 encode, but I have absolutely no idea what a best effort vpxenc cmdline would look like. Even the MSU preset from the 2017 report doesn't help, since most of the knobs they set are defaults anyway, while some others just go on blindly favoring blurring. Plus, they set --cpu-used to 1, so I don't really know what to think about those settings.

In a recent set of tests (https://www.reddit.com/r/AV1/comments/9x8tgy/great_comparison_between_x264_x265_libaom_and/e9tgc7n/) I run I used this:
vpxenc --codec=vp9 --frame-parallel=0 --tile-columns=2 --good --cpu-used=0 --tune=psnr --passes=2 --threads=2 --end-usage=q --cq-level={} --test-decode=fatal --ivf -o test.vp9.cq{}.ivf orig.i420.y4m

Perhaps I could set --tile-columns to 0 and call it a day.

EDIT: just to make sure, I'm downloading the ToS_1920x800_xdither.7z file. Is this good for the test?

rwill

17th November 2018, 17:43

https://1drv.ms/v/s!AuR0uLTdXhL-bHDTK8EQR8MZKxs
https://1drv.ms/v/s!AuR0uLTdXhL-bbn61I4WUO3vouY
https://1drv.ms/v/s!AuR0uLTdXhL-btPdKqFN4UHhpjY

Mpeg2 for shits and giggles.

SmilingWolf

18th November 2018, 15:21

libvpx (VP9) 1.7.0-1363-gfa1e85b09
ffmpeg -i ToS_1920x800_xdither.y4m -c:v libvpx-vp9 -enable-tpl true -row-mt false -tile-columns 0 -tile-rows 0 -auto-alt-ref 1 -frame-parallel false -cpu-used 0 -deadline good -b:v <1/1.5/2>M -maxrate 4M -bufsize 12M -g 120 -pass 2 <outfile.mkv>

1M (937 kb/s): https://mega.nz/#!Q1wF0Q6Z!hv5R2ZECI02pi-S1ObiXwg4Gvcyol7r8YoadlVH8cAI
1.5M (1400 kb/s): https://mega.nz/#!I451lSpD!P3pYAUzMw6tUuPdPcsjL0YYl1gtvI0WXme2YkEdsESs
2M (1931 kb/s): https://mega.nz/#!F4phRQBZ!RG_bsXj3nnNxSddb33b4xzV2SCE4hg8hSlY03CrI1ks

It gets especially bad around the 5:00 mark. Also, that "halo" effect which surrounds moving objects is really really annoying

jonatans

20th November 2018, 11:08

I created a lower bitrate xvc encode as well.

This one is below 0.5 mbps (462 kbps) but still I think it keeps it together quite ok.

https://drive.google.com/open?id=1i2rTHjBdAx1iN8im9JLAHbfQnGIDksUO

You need a player with xvc support to play it (such as the ffplay build from my earlier post: https://forum.doom9.org/showthread.php?p=1855884#post1855884)

It took 20 hours to encode on my 4 core desktop computer.

jethro

20th November 2018, 22:14

https://1drv.ms/v/s!AuR0uLTdXhL-bHDTK8EQR8MZKxs
https://1drv.ms/v/s!AuR0uLTdXhL-bbn61I4WUO3vouY
https://1drv.ms/v/s!AuR0uLTdXhL-btPdKqFN4UHhpjY

Mpeg2 for shits and giggles.

2Mbit is definitely watchable

SeeMoreDigital

20th November 2018, 23:39

https://1drv.ms/v/s!AuR0uLTdXhL-bHDTK8EQR8MZKxs
https://1drv.ms/v/s!AuR0uLTdXhL-bbn61I4WUO3vouY
https://1drv.ms/v/s!AuR0uLTdXhL-btPdKqFN4UHhpjY

Mpeg2 for shits and giggles.How about MPEG-1 ;)

SmilingWolf

21st November 2018, 20:53

libaom 1.0.0-943-ga7f959f06
aomenc --frame-parallel=0 --tile-columns=1 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --pass=2 --fpf=<file.log> --threads=2 --end-usage=vbr --target-bitrate=1000 --maxsection-pct=400 --buf-sz=12000 --kf-max-dist=120 --test-decode=fatal --ivf -o <file.ivf> <file.y4m>

0.5M (484 kb/s): https://mega.nz/#!1owA1CaB!NHTMNqAS6gxsruYoznKKv9kewBcb4q213Bq5D2fLbLI
1M (921 kb/s): https://mega.nz/#!so5SUSCB!79tHA8d78cD_dMYPL6jTjYOxVUQMebyXW7mYInkS5rQ
1.5M (1364 kb/s): https://mega.nz/#!MggEgQzA!71cMBPcjPPF_SyVqjBObyLwoG7s5TiIlZ7GG6330B3Q

The aomenc CLI requires an unholy mix of times, percents and bitrates and it took tre different manuals to understand which options I needed, so I can only hope the encoded files honor the limits imposed by the challenge.
Seriously, this thing needs a proper manual

rwill

24th November 2018, 13:12

How about MPEG-1 ;)

For progressive content MPEG-1 and MPEG-2 are very similar. then again resolutions larger than 352x288 and bitrates higher than 1.25Mbit are only in MPEG-2 profiles and levels as far as is know. That does not mean that unconstrained MPEG-1 video would not be able to reach almost the same quality as MPEG-2 video. The standards are only 2 years apart ( 1992 and 1994 ? ).

Now H.261 from 1989 would be interesting but it only supports QCIF and CIF resolutions without standard breaking modifications.

benwaggoner

26th November 2018, 18:45

For progressive content MPEG-1 and MPEG-2 are very similar. then again resolutions larger than 352x288 and bitrates higher than 1.25Mbit are only in MPEG-2 profiles and levels as far as is know. That does not mean that unconstrained MPEG-1 video would not be able to reach almost the same quality as MPEG-2 video. The standards are only 2 years apart ( 1992 and 1994 ? ).

Now H.261 from 1989 would be interesting but it only supports QCIF and CIF resolutions without standard breaking modifications.
I tried some MPEG-1 encodes, actually, and they were recognizable but pretty dreadful. Also MPEG-2 ASP, which were not all that much better. And VC-1 dynamic resolution Smooth Streaming, which was surprisingly robust, but still well short of H.264. And plays back correctly in hardly anything.

VP9 and VVC are the ones I’m most interested in adding to the hopper. And maybe we should add a 750 Kbps version based on the excellent showing of xvc?

easyfab

26th November 2018, 22:35

I just tried the first 1500 frames with AV1 @1000 kb/s. aomenc is really slow 34 fpm ( cpu-used 4 )

Here the file is someone is interested to see the result : https://www.sendspace.com/file/dcf6ii

peharps I'll try to encode it entirely if I find some time.

SaurusX

7th December 2018, 15:18

Benwaggoner, I'm sure you know, but Amazon is considered the gold standard for video encodes often times beating out blu-ray. Now that I've buttered you up, I have a question: What's your opinion on using HEVC and animation? As it is, there is no animation tune given by the x265 developers and it appears it's because the combination of hard edges, flat cels, grain, and detailed backgrounds tends to throw HEVC for a loop. There are a few dedicated scene groups with their own "optimized" encoder settings, but none have really seemed to get it. Has Amazon "gotten it"?

sneaker_ger

7th December 2018, 15:23

Amazon is considered the gold standard for video encodes
You misspelled "Netflix". ;)

As it is, there is no animation tune given by the x265 developers and it appears it's because the combination of hard edges, flat cels, grain, and detailed backgrounds tends to throw HEVC for a loop.
When I tested x265 years ago it did very well on animation, except very grainy/old ones. Easily beat x264 and by a considerable margin. Much better edges than x264.
https://forum.doom9.org/showthread.php?p=1693498#post1693498
https://forum.doom9.org/showthread.php?p=1693681#post1693681

benwaggoner

7th December 2018, 19:41

You misspelled "Netflix". ;)

When I tested x265 years ago it did very well on animation, except very grainy/old ones. Easily beat x264 and by a considerable margin. Much better edges than x264.
https://forum.doom9.org/showthread.php?p=1693498#post1693498
https://forum.doom9.org/showthread.php?p=1693681#post1693681
Speaking just for myself, I consider HEVC as having some helpful features for cel animation that reduce the need to have a separate preset. More precise prediction modes are a huge help. Having the option of transform skip and (at high bitrates) lossless CUs can also be a big help.

A preset might be able to find a better speed/quality tradeoff, but I don't know that actual peak compression efficiency would improve THAT much. That said, I haven't taken a whack at doing a new cel animation setting since the 2.4 lambda tables were introduced.

Another complicating factor is that modern anime can have grain effects, CGI elements at 24p, and other things beyond the classic hand-drawn cels that traditional "--tune animation" was meant for. Particularly in title sequences. Encoding "Kabaneri of the Iron Fortress" is quite different than "Dumbo."

A good followup test to this one would be to use some anime! Anyone know of any good Creative Commons licensed 1080p24 anime/cel animation?

3rd January 2019, 10:40

My core x265 options are:
--aq-mode 3 --qg-size 64 --rc-lookahead 120 --cbqpoffs -1 --crqpoffs -1 --subme 7 -F1

The main difference to benwaggoner options is '--qg-size 64' -- it really helps (so I've encoded at veryslow preset).

0.5M www.msystem.waw.pl/x265/tos_x265vs_500.mkv PSNR: 39.471, SSIM: 12.784 dB
1.0M www.msystem.waw.pl/x265/tos_x265vs_1000.mkv PSNR: 41.901, SSIM: 14.585 dB
1.5M www.msystem.waw.pl/x265/tos_x265vs_1500.mkv PSNR: 43.206, SSIM: 15.515 dB

In my opinion 0.5M version wins with MPEG2 1.5M version and is comparable to MPEG2 2M version.

I've attached encoding details (encode.txt) and proof that '--qg-size 64 --rc-lookahead 120' are coll and not time consuming (tests.txt).

asarian

3rd January 2019, 18:07

My core x265 options are:
--aq-mode 3 --qg-size 64 --rc-lookahead 120 --cbqpoffs -1 --crqpoffs -1 --subme 7 -F1

Are these what you'd call 'best' x265 settings?

I realize my question may be slightly off-topic, but since the OP kinda posted his challenge, with apparently super-x265 settings, this might be a good time to ask what ppl deem x265 settings for super-quality? Most of the x265 options (especially those that all affect more or less similar areas), are still somewhat confusing to me.

3rd January 2019, 18:31

Are these what you'd call 'best' x265 settings?

For low and medium bitrates -- yes (+ placebo or veryslow preset). If the source is anime I reduce '--psy-rd' and optionally '--aq-strength'.

For high bitrates I prefer 10-bit output + '--aq-mode 0'.

asarian

3rd January 2019, 18:37

For low and medium bitrates -- yes (+ placebo or veryslow preset). If the source is anime I reduce '--psy-rd' and optionally '--aq-strength'.

For high bitrates I prefer 10-bit output + '--aq-mode 0'.

Thanks. Interesting choice on '--aq-mode 0', btw; I had expected ppl would use --aq-mode 3 for best quality (although I never fully understood whether '--aq-mode 3' takes away from regular scenes towards darker ones, or whether it plain favors darker scenes).

4th January 2019, 22:23

The main idea about aq-mode is to more compress (worse quality) CU that are hard to compress and move the bitrate to CU that are easy to compress -- it degrades quality (a little bit) in complicated CU and boosts quality in not complicated CU. The quality degradation is percentage smaller than the boost (if you move 5 from 100 to 20 you will have 95 and 25 -- 5% less bitrate in one CU and 25% more bitrate in second CU).

First scene: launch of the rocket
aq-mode moves bitrate from fire and smoke to sky and rocket -- the scene looks better with aq-mode.

Second scene: two people talking on the bridge at blurry background
aq-mode moves bitrate from people to background (blurred leaves) -- the scene looks worse with aq-mode.

Whole movie (aq-mode 3 vs. aq-mode 0):
2.0M '--aq-mode 3' www.msystem.waw.pl/x265/tos_x265vs_2000.mkv PSNR: 44.081, SSIM: 16.075 dB
2.0M '--aq-mode 0' www.msystem.waw.pl/x265/tos_x265vs_2000aq0.mkv PSNR: 43.528, SSIM: 15.624 dB

For me both versions are watchable, the main difference is the noise -- in '--aq-mode 0' version is more live and annoying (aq-mode moves bitrate from noisy parts to clean parts of the scene). The noise is in source movie so it is OK.

For noise/details lover '--aq-mode 0' should be interesting for high bitrate encoding.

asarian

4th January 2019, 23:09

^^ Thanks, @Ma, for the great explanation, and the samples! :)

TomV

14th May 2019, 20:36

Here are my Beamr 5 encodes (https://drive.google.com/open?id=12rOGjYJI2pmKUVZYgGiQD8E1awI7e75l) (the Google Drive includes copies of Ben's x265 UltraPlacebo encodes). I look forward to feedback.

Blue_MiSfit

15th May 2019, 04:59

TomV

15th May 2019, 08:55

The Beamr encodes look good - I spent some time this evening looking at the 1.5 Mbps encode. One area where I think x265 is still superior is in the scene with the robot legs around frame 1232 - the background has very distracting visual artifacts (mostly looking like mosquito noise) in the Beamr version that are not present in the x265 version.

I saw some similar issues in the scene around frame 4514, including a keyframe pop.

However, the tables turn in a dark scene around frame 3651 where x265 has similar artifacts in the background and on the sniper's face, but Beamr is quite good. Another example of this is in the (bright) scene around frame 7527 where Tom's face is more detailed and more stable in the Beamr version.

I need to spend more time reviewing these - but Beamr definitely makes a very good showing! :)

Thanks for doing this, Tom!
Thanks for the feedback Derek. These encodes were done with a pre-release (development) version of Beamr 5, v4.5. I'm in St. Petersburg Russia this week, working with our development team. We will take a look at your feedback and will produce a fresh set of encodes with the production release version, which is a few weeks away from being finished.

I can't find any robot legs or distracting artifacts around frame 1232... can you double-check the position of the issue you're talking about? I see the quality change in the wall behind the guy at frame 4519 (a keyframe), and some "live walls" behind the characters in the scene before that (frame 4136-4398).

By the way, the best way to compare video quality side by side is to use Beamr View, our frame-synchronized dual video player. I know Derek has a copy, but if any other video professionals need copies of Beamr View, ping me (tv at beamr dot com).

Blue_MiSfit

15th May 2019, 18:41

My bad - frame 11232

Emulgator

15th May 2019, 22:20

Beamr 4501: Impressive !
Until now I only looked at 4501 1Mbps, pixel peeping mode.
Remarkably kept/simulated texture, sometimes glued onto the underlying surface, but nicely done.
The expected artifacts at such low bitrate are unexpectedly small, and well shifted to domains where it doesn't hurt.
My favourite ToS warping artifact "robot arm moving before leaves" is very good suppressed,
as are all contour warping stuff that x265 still has, well, at these misery bitrates.
Nice research, never believed that would be possible !

IgorC

26th May 2019, 21:08

Here are my Beamr 5 encodes (https://drive.google.com/open?id=12rOGjYJI2pmKUVZYgGiQD8E1awI7e75l) (the Google Drive includes copies of Ben's x265 UltraPlacebo encodes). I look forward to feedback.

Beamr looks absolutely better than x265 ver 2.8. Not sure how x265 3.0 would perform.

Also, a relevant article here
https://www.streamingmedia.com/Articles/Post/Blog/HEVC-IP-Owners-Are-Killing-the-Golden-Goose-Over-Royalties-131923.aspx

mandarinka

6th August 2019, 18:29

I didn't do any content specific encoding in these. I just did the slowest, highest quality encode 2-pass I had the patience for. Basically

--preset placebo
--cu-lossless
--tskip
-F 1
--ref 6
--bframes 16
--aq-mode 3
--rd-refine

If I had infinite patience I'd add --me sea and --subme 7 for PlusUltraPlacebo.

Acording to x265 documentation, CU-lossless requires extra signaling so it adds some bitrate overhead whether it is useful or not. It is usually nigh impossible to check if it helps or not at higher bitrates, because due to ratecontrol variation, some frames will look worse, some better, and you will have no idea. But I tried to meassure SSIM at 10mbits and 18mbits with a bluray source (1440x1080p24) and despite this high bitrate, I got a SSIM drop from CU-lossless.

I observed SSIM dropping from 0.9872928 without cu-lossless to 0.9872879 with cu-lossless at 18mbits, and from 0.9820309 to 0.9820127 at 10mbits.

Are you sure using this tool on normal lossy encodes (as opposed on some extreme bitrate archival encodes or something, hybrid lossless?) really helps visually quality per unit of bitrate? Or perhaps it is different with clean uncompressed source but it harms on compressed sources?

benwaggoner

8th August 2019, 20:56

Are you sure using this tool on normal lossy encodes (as opposed on some extreme bitrate archival encodes or something, hybrid lossless?) really helps visually quality per unit of bitrate? Or perhaps it is different with clean uncompressed source but it harms on compressed sources?
I am not sure if it does, no. It's more likely to help with zero-noise synthetic images, like the credits, but didn't do a lot of testing. Like I said, it was just an experiment to see what stuck after throwing at a wall.

I definitely want to try again with the new aq-mode and some other x265 improvements.

mandarinka

8th August 2019, 21:48

I see, thanks.

Funky080900

31st August 2019, 13:37

Hi there

here is my VVC encode using VTM Encoder Version 6.0. The original files are 37MB@403kbps. Encoding time ~ 1 week on i7-4720HQ.
I split the movie to encode in parallel and couldn't figure out how to merge the .bin files, so I recommend downloading the lossless h.264 video (5GB).
I don't know how representative my results are for VVC but since it took so long to encode I thought I'd share it anyway.

Files: https://drive.google.com/open?id=1XsHs9tMEaHMKhasqjXfc_CZWXWtkLzJF

benwaggoner

3rd September 2019, 19:23

Greenhorn

26th November 2019, 08:23

So I'm not a VP9 expert by any stretch of the word, but I thought I'd take a stab at this as I'd been meaning to probe libvpx's options for a while anyway. Maybe someone'll find this useful.

https://mega.nz/#!RR9F0IYS!kAoSuKEHzdxQR-rl3qVDhKzVciAuaaO1eSa-0qgJ1rg

settings: --target-bitrate=2000 --buf-optimal-sz=2000 --kf-max-dist=120 --max-gf-interval=23 --tile-columns=0 --row-mt=1 --auto-alt-ref=6 --arnr-maxframes=15 --arnr-type=3 --frame-boost=1 --aq-mode=1. Overall encode speed was 1.56FPS (with ~20% utilization) on a Ryzen 7 3700X.
Average bitrate is 1998 kbps. I don't know how to measure the maximum local bitrate, sorry.

Notes/explanations/attempted justifications. Apologies in advance for the bad formatting and wordiness.
0) libvpx defaults to its highest-quality preset, and there doesn't seem to be a lot you can do to improve visuals sadly.
1) --threads appears to be the size of the worker pool, not the number of frame threads. I don't think there's any frame-level parallelism going on in the encoder, actually, as --frame-parallel enables/disables parallel decoding.
2) For a given --threads count, different --tile-columns counts will produce files that look more or less the same to my eyes and the basic ffmpeg metrics, but differ in slightly in filesize. I left --tile-rows at zero.
3) For a given --tile-columns count, altering --threads has the same effect.
4) Row-based multithreading (--row-mt) appears to be similar to WPP in HEVC; with tiles disabled, enabling it actually produced slightly smaller files with slightly higher visual metric scores, in addition to boosting encode speed from ~40FPM to ~1.5FPS.
5) Relative to the default settings (which appear to be --row-mt=0 --threads=8 --tile-rows=0 --tile-columns=6), --threads 1 --tile-columns 0 produced files that were on average 1% smaller for identical metric scores. (Caveat: this was done with several ~30second test clips extracted with FFMPEG.)
6) I really couldn't spot a visual difference between no-parallelism encodes and encodes with substantially more threads and tiles enabled than default, if I'm being honest.
7) There doesn't appear to be a strict analogue to --vbv-maxrate in libvpx, so I just set the "optimal buffer size" to 2000 milliseconds.
8) If I didn't set either a maximum or minimum quantizer value, bitrate would frequently rocket to absurdly high levels, then plummet down to equally absurd levels for an absurdly long amount of time. I believe this loose rate-control may be the cause of artifacting like you see in SmilingWolf's encodes from last year. There's still some in scenes like the sniper descending down his rope, but it does seem to be reigned in. Also: the overshoot-pct/undershoot-pct settings which you'd think might control or influence this appear to do precisely nothing.
9) Golden Frames and Alternate Reference Frames appear to be the same thing. By default they occur at an non-fixed interval of up to 16 frames (sort of a secondary GOP within the GOP . . .); I hope that increasing this to 23 (the maximum) was permissible, as it was one of the only tweaks I found that seemed to have a notable effect on the output files' visuals or metric scores.
10) I'm a bit fuzzy as to what it actually does in a technical sense, but setting auto-alt-ref to was the other really universally positive tweak I found.
11) AQ appears to be a little half-baked in libvpx (common theme . . .), but seemed to have an overall positive effect. Based on the code, aq-mode 1 is fairly similar to aq-mode 2 in the x26x encoders, while aq-mode 2 is similar to their aq-mode 1. AQ3 is silently disable if cpu-used is less than 5, and I really have no idea what AQ4 is trying to do but it didn't help anything for this clip.
12) None of the --tune-content settings had anything like a positive effect. "film" actually appears to be similar to "rc-grain" in x265, while "screen" just murdered quality.
13) The "--tune" option will always be set to "psnr"; setting it to "ssim" seemed like low-hanging fruit initially, but it appears that the actual code for the option was never ported from VP8 to VP9.
14) All of the "arnr-" settings had miniscule but actual effects on output. Setting arnr-type to three enables a bidirectional filter, and I assume that a larger sample size should be better.
15) --frame-boost seems like it might be silently ignored, but the intended effect (raise or lower QP of alt-ref frames based on 2-pass analysis) seemed good enough that I enabled it anyway.
16) "--sharpness" is actually an inverse to the strength of the loop filter (I think); reducing it increased filesize by about 10% and worsened artifacts.

I think the final encode is actually pretty OK, if not anything special.

Tadanobu

24th March 2020, 05:49

Could you please explain how you generated that film grain table please ? Because grain retention is one of the problem with aomenc. At least with default settings.

Funky080900

24th March 2020, 15:27

Blue_MiSfit

24th March 2020, 18:27

quietvoid

25th March 2020, 20:55

foxyshadis

27th March 2020, 00:06

WOW.

That is truly impressive. This reinforces my belief that film grain modeling is enormously important and will really make 1 Mbps 1080p totally viable. This is a game changing feature for AV1!

Do any of the encoders have / plan to integrate this in-loop during encoding? Working with YUV intermediates is pretty painful.

SVT-AV1 also has it, but it's mostly a clone of aomenc's. There have been a few minor changes that should show up in the next release, but FGM is one of those things that engineers are very loathe to touch, since it's all-but-untestable and intentionally introduces randomness.

nevcairiel

27th March 2020, 01:08

This is a game changing feature for AV1!

H264 has Film Grain Modelling, just noone ever used it because its hard to use correctly.

Maybe we get more lucky this time around and enough engineering time is put into it...

Blue_MiSfit

27th March 2020, 02:23

Right, I remember a few devices did but very few.

It's so incredibly useful when delivering streaming video though!

I wonder, everyone agreed that HE-AAC was better than AAC at lower bitrates. That was never controversial. Since FGM is fundamentally similar, why the resistance from engineers?

benwaggoner

30th March 2020, 06:30

H264 has Film Grain Modelling, just noone ever used it because its hard to use correctly.

Maybe we get more lucky this time around and enough engineering time is put into it...
AV1's implementation is quite a bit better, from people I've talked to who have looked at both. Also, grain removal itself is quite computationally expensive and algorithmically complex, and is a lot more feasible today than it was in 2006 when FGM was a required (but never used) feature of H.264 for HD-DVD.

It wasn't mandatory anywhere else, which also was a huge barrier to adoption. It likely could have become quite useful for 720p streaming circa 2010. Fewer pixels, more MIPS, bigger bitrate challenges.

It's easy to forget that we have >100x more compute available per pixel for 1080p than we did when the HD optical formats launched. I bet the typical AV1 pixel gets >>1000x more MIPS than a launch Blu-ray or HD-DVD.

Sagittaire

23rd April 2020, 11:37

libaom 1Mbps: https://drive.google.com/file/d/1gEwfqVcjZZcjDeQKMmvgk6shYQHxidU0/view?usp=sharing

aomenc --passes=2 --pass=2 --fpf=firstpass.log --target-bitrate=1220 --kf-max-dist=120 --cpu-used=0 -t 4 --deltaq-mode=2 --film-grain-table=film_grain.tbl -o AV1-0.ivf input.y4m

Clearly impressive result but by definition you make pre-process with this encoding technique. And with source with dither it's a considerable advantage. If I make denoising (dithering high frequency cut), no doubt that HEVC will be really better too.

@ benwaggoner

For this challenge at really low bitrate, use source with dithering is not really good idea, because local complexity frequency is really high. Never, I will make direct encoding without preprocess with this source like this.

Anyway I will try ... I have actually time to lose ... ;-)

Blue_MiSfit

23rd April 2020, 23:22

benwaggoner

24th April 2020, 00:03

For this challenge at really low bitrate, use source with dithering is not really good idea, because local complexity frequency is really high. Never, I will make direct encoding without preprocess with this source like this.
Banding is pretty hard to encode as well. Depending on the content and codec, dithering can allow for better quality at lower bitrates than not dithering.

I could probably knock out a non-dithered version if you'd like to try one.

Sagittaire

24th April 2020, 11:28

Banding is pretty hard to encode as well. Depending on the content and codec, dithering can allow for better quality at lower bitrates than not dithering.

I could probably knock out a non-dithered version if you'd like to try one.

No challenge is challenge ... ;-)

1) After first analyse, VBV (4 Mbps, 12 kbit) seem useless for 1000 kbps encoding. Defaut crf mode with x265 seem don't have VBV saturation in complexe scene.

2) Paradoxaly, certainely that the more complexe encoding will be 2000 kbps enconding with contrained VBV because you have high buffer saturation in complexe scene. But I have solution for that ... ;-)

Funky080900

24th April 2020, 20:24

Clearly impressive result but by definition you make pre-process with this encoding technique. And with source with dither it's a considerable advantage. If I make denoising (dithering high frequency cut), no doubt that HEVC will be really better too.

@ benwaggoner

For this challenge at really low bitrate, use source with dithering is not really good idea, because local complexity frequency is really high. Never, I will make direct encoding without preprocess with this source like this.

Anyway I will try ... I have actually time to lose ... ;-)

The denoised video was only used for generating the film grain table and not for encoding.
Libaom only ever saw the unaltered source file provided by Benwaggoner.

Sagittaire

25th April 2020, 13:11

@benwaggoner

use zone option is legal for this challenge?

After analyse, end credit is really high bitrate zone in constant quality mode (crf, cq or multipass encoding).

before credit zone (frame 14135), bitrate must be at 850 kbps and credit zone is inhabitually long with something like 15% of total frames

benwaggoner

27th April 2020, 23:15

@benwaggoner

use zone option is legal for this challenge?
It isn't legal in the base version, but I don't mind adding a version with content-specific temporal parameters. The basic test was really to exercise how well the encoder can do with static settings across variable content. But how well is possible no-holds-barred is also interesting.

After analyse, end credit is really high bitrate zone in constant quality mode (crf, cq or multipass encoding).

before credit zone (frame 14135), bitrate must be at 850 kbps and credit zone is inhabitually long with something like 15% of total frames
Yeah, that is a weirdness about this clip. Something with classic scrolling text would give an encoder opportunity to really squeeze and redistribute bits out of what can be really cranked down. All in all, though, ToS was the best broadly available and freely licensed source I found.

benwaggoner

28th April 2020, 02:31

benwaggoner

28th April 2020, 02:56

Oh, and I see I had a few old oddball things I didn't post before.

Best possible WMV encodes, via Expression Encoder and its built-in version of the VC-1 Professional Encoder SDK.

1000 Kbps (https://1drv.ms/v/s!AlvIQZWsyeO-kKps2VqtsCjMwPF2cg?e=I4jPFg)
1500 Kbps (https://1drv.ms/v/s!AlvIQZWsyeO-kKpuw9v9wyKH5rfDlA?e=AK6OCF)
2000 Kbps (https://1drv.ms/v/s!AlvIQZWsyeO-kKptiVfSb2xEL1Wwqg?e=E5hsfS)

Sagittaire

28th April 2020, 08:04

I finally got around to posting some encodes comparing x264 --hevc-aq with --aq-mode 4. I reran my old tests using the latest x265 and new parameters. These are 1 Mbps. Just 2-pass VBR at veryslow; the UltraPlacebo versions to follow.

HEVC-AQ (https://1drv.ms/v/s!AlvIQZWsyeO-k7tgvI1tlwmSgRwd4g?e=PzhpcX)
AQ-MODE 4 (https://1drv.ms/v/s!AlvIQZWsyeO-k7thJC1wvob8RmFFkQ?e=GNYKTi)

Curious on which the rest of you think is superior.

http://jfl1974.free.fr/Videos/ToS/ToS-2.mkv

Well here really better result with more temporal stability and really better edge reproduction. I have really better result in scene introduction on the bridge (between 26 sec and 40 sec for exemple). We can see (real) mosquitoes flying around the actress' head. Really better result too than your previous placebo encoding for my eyes.

- Better subjectif result
- Better objectif result (than Ma encoding for exemple).

encoded 17620 frames in 29373.04s (0.60 fps), 1000.00 kb/s, Avg QP:30.93, Global PSNR: 42.353, SSIM Mean Y: 0.9653839 (14.607 dB)

I make encapsulation in mkv file with HE-AAC 5.1 audio at 128 kbps. I think it's really good quality for only 1000 kbps encoding at 1080p with 5.1 audio.

Test in progress with better psy setting for better subjective result if I can ...

Sagittaire

28th April 2020, 08:44

Opmox

29th April 2020, 04:19

deleted

Boulder

30th April 2020, 10:53

rd 4 instead of 6 and psy-rdoq 0 because (in my experience) it makes too much onion gradient artifacts (https://slow.pics/c/mx2EEPX6), maybe there's another way to fix it but I don't know.

I happened to run into a frame with some of that onion gradient in my tests yesterday. It was fixed by using --rd-refine. In my opinion, --rd 4 loses too much detail at least at higher bitrates but I'm still testing.

benwaggoner

30th April 2020, 22:50

@ benwaggoner

Well it's really curious. I Check previous Ma's enconding or TomV's encoding. And Ma's enconding, TomV's encoding or my encoding seem have really better quality than your placebo encoding (particulary in low motion part). You don't have problem with your encoding profil? You are sure that onedrive don't make reencoding (at upload or at download?). Quality is really bad for me.

and Beamr 5 encoding are the best for my eyes: really good complexity conservation. Certainely high psy (and good) optimisation. I will try to produce better result.
Which iteration of the placebo settings? The only placebo I think I posted was several years ago with a much older version of x265. The ones I posted this last week were veryslow. I'm rendering out the UltraPlacebo ones still, on a older machine where it looks like it'll take a full week.

Sagittaire

1st May 2020, 12:30

Which iteration of the placebo settings? The only placebo I think I posted was several years ago with a much older version of x265. The ones I posted this last week were veryslow. I'm rendering out the UltraPlacebo ones still, on a older machine where it looks like it'll take a full week.

Well I don't think it's x265 version problem. Your recent 2 pass x265 encoding have these problem too:

https://onedrive.live.com/?authkey=%21ALyNbZcJkoEcHeI&cid=BEE3C9AC9541C85B&id=BEE3C9AC9541C85B%21318944&parId=BEE3C9AC9541C85B%21267619&o=OneUp

Really bad quality on scene introduction:

Frame 442 to 559 : rocket takeoff, really blocky rocket and temporal blocking, I don't check quantizer but it's certainely too high value here. Perhaps rate control problem.

Frame 600 to 965 : bridge scene, problem on the edge (around the actress’s head or from the actor's arm for example). Certainely too high quantizer here. Perhaps rate control problem too.

I don't have these problem and the other encoding from me, or Ma or Opmox with x265 don't have these problem. It's really curious.

benwaggoner

1st May 2020, 16:24

Frame 442 to 559 : rocket takeoff, really blocky rocket and temporal blocking, I don't check quantizer but it's certainely too high value here. Perhaps rate control problem.

Frame 600 to 965 : bridge scene, problem on the edge (around the actress’s head or from the actor's arm for example). Certainely too high quantizer here. Perhaps rate control problem too.

I don't have these problem and the other encoding from me, or Ma or Opmox with x265 don't have these problem. It's really curious.
Yeah, these were really encodes meant to test all the new recent features of x265 together. I am sure there are oddities.

Here's the full parameters blob I did, used in both passes. No implication these are appropriate settings for production use; I just stuck new parameters into an old ToS script from a couple of years ago as I was heading off to bed.

--level-idc 4.0 --profile main --preset veryslow -F 2 --selective-sao 2 --sar 1 --rd-refine --scenecut-aware-qp --hist-scenecut --hme --multi-pass-opt-analysis --multi-pass-opt-distortion --tskip --tskip-fast --keyint 120 --tu-intra 4 --tu-inter 4 --hevc-aq --hrd --aud --single-sei --bitrate 1000 --vbv-maxrate 4000 --vbv-bufsize 12000 --colorprim bt709 --transfer bt709 --colormatrix bt709

And below full blob for the "UltraPlacebo" version I tried just to see what insanity may be feasible. The first pass only has about 80 hours left to go on my older personal computer (i7-6800K, which was actually a decent encoding box when I first built it). I'll try it on my actual workstation once I've got a break in my day job renders.

There's reasons there are parameters not even used in --preset placebo. Some because they are newer than the last preset refactoring (like HME) and some because the vanishingly small quality gains can't be justified by the huge speed increases.

--level-idc 4.0 --profile main --preset placebo --sar 1 -F 1 --ref 6 --bframes 16 --subme 7 --rd-refine --scenecut-aware-qp --hist-scenecut --hme --hme 5, 5, 5 --multi-pass-opt-analysis --multi-pass-opt-distortion --tskip --cu-lossless --keyint 120 --tu-intra 4 --tu-inter 4 --hevc-aq --hrd --aud --single-sei --bitrate 1000 --vbv-maxrate 4000 --vbv-bufsize 12000 --colorprim bt709 --transfer bt709 --colormatrix bt709

quietvoid

1st May 2020, 18:28

I would blame the default --max-qp-delta (with --scenecut-aware-qp) and --hist-threshold (with --hist-scene-cut). It's pretty awful to increase QP by 5 for 500ms every (detected) scene cut.
Increasing the --hist-threshold just to 0.02 already cuts the I frames by 3x or something, someone had posted about it as well in the x265 thread.

Sagittaire

1st May 2020, 19:01

benwaggoner

2nd May 2020, 01:38

I will check that but it's certainely something like that.
I'm reencoding with --hist-threshold 0.02 to see if that helps.

benwaggoner

2nd May 2020, 01:57

Sagittaire

6th May 2020, 10:34

Hmmm, check this out: https://bitbucket.org/multicoreware/x265/commits/eca79c2880129eab0380d5f1220b4ea15f233abe

Kirithika Kalirathnam committed eca79c2
2019-10-18
Fix the RC Pass2 ABR

This commit does the following changes:
1. Fix the order of RC Pass 1 stats Analysis in Pass2
2. Fix the aggressive Qp tuning for I/P frames in Pass2

Well seem to be the problem. At actual committed version (3.3+26), x265 seem have too agressive rate control compression at the start of encoding with 2 pass. You have not the problem with 3 pass or crf mode.

and it's really curious, but crf mode and multipass encoding seem have really different strategy for rate control too:
- crf mode has really agressive quantizer for bframe: really high metric but lower quality for bframe.
- multipass is less agressive for bframe: lower metric but higher subjective quality with better temporal quality stability.

Imply that it's difficult to compare crf and multipass mode beacause RC strategy are different (quality can really change between N and N+1 frame and conclusion too).

Sagittaire

6th May 2020, 13:13

benwaggoner

6th May 2020, 20:25

Well for HEVC I will try to make:

- highest possible quality metric (crf mode)
- highest possible "temporal" quality metric (multipass mode)
- highest subjective quality (with my best psy mode actived)
- Ultra fast encoding demonstration in "VOD production mode"

These encoding will have really higher overall quality than old ultraplacebo benwaggoner encoding (for metric quality or subjective quality)
I expect they would be! Those were done using a 2018 x265 build and plenty of fixes and other improvements have come in since then. Plus that was really an attempt to figure out what maximum encoder complexity could do. Plenty of content-specific tweaks remain to be discovered and applied.

I look forward to seeing your results!

Sagittaire

9th May 2020, 11:04

I expect they would be! Those were done using a 2018 x265 build and plenty of fixes and other improvements have come in since then. Plus that was really an attempt to figure out what maximum encoder complexity could do. Plenty of content-specific tweaks remain to be discovered and applied.

I look forward to seeing your results!

Actually more than 100 encodings for find best profil. I had not encoded with the x265 for quite a long time and there was plenty of functionality to test. currently I finish the 1000 kbps encodings with the final profiles:

- crf mode with highest metric score: my profile will beat all previous HEVC encoding here with a large margin
- ABR with 3 passes : my best visual compromise
- Reuse ABR : encoding with ABR 3 passes analysis reuse statistique but at fastest speed (~50x speed improvement vs slower, ~100x vs veryslow, ~200x vs placebo ... with comparable quality)
- ABR 3 passes with default RC, AQ and PSY setting (but at same level research for ME, CU, TU ...) for make comparison.

Anyway some little conclusion:
- hevc-aq option produce better metric and by far
- Rate Control in multipass encoding don't work very well: 2 passes don't produce constant quality encoding. You must use 3 passes for better bitrate repartition and even sometimes 4 passes if you want same bitrate repartition than crf mode.
- crf mode has the best metrics but with really aggressive quantizer on bframes: the difference in quality between PFrames and bframes is really large. ABR multipasses encoding don't have this "problem".
- placebo preset encoding is not really usefull (less than 1% size gain at same "metric" quality versus veryslow preset). For exemple I obtain really better constant quality in "3 pass preset slower" versus "2 pass preset placebo" simply because Rate Control is not really good in 2 passes mode.

crf mode:

x265 [info]: frame I: 221, Avg QP:27.27 kb/s: 11216.30 PSNR Mean: Y:43.857 U:46.103 V:46.112 SSIM Mean: 0.973372 (15.747dB)
x265 [info]: frame P: 3910, Avg QP:29.09 kb/s: 2844.64 PSNR Mean: Y:43.033 U:46.037 V:45.997 SSIM Mean: 0.971443 (15.443dB)
x265 [info]: frame B: 13489, Avg QP:36.49 kb/s: 296.98 PSNR Mean: Y:41.376 U:45.256 V:45.240 SSIM Mean: 0.967579 (14.892dB)
x265 [info]: Weighted P-Frames: Y:6.0% UV:4.8%
x265 [info]: Weighted B-Frames: Y:4.1% UV:2.8%
x265 [info]: consecutive B-frames: 10.8% 7.6% 5.9% 24.9% 21.6% 29.2%

encoded 17620 frames in 30340.70s (0.58 fps), 999.28 kb/s, Avg QP:34.73, Global PSNR: 42.688, SSIM Mean Y: 0.9685090 (15.018 dB)

3 passes ABR mode with exactly same setting:

x265 [info]: frame I: 221, Avg QP:26.58 kb/s: 10729.30 PSNR Mean: Y:43.864 U:46.118 V:46.127 SSIM Mean: 0.972412 (15.593dB)
x265 [info]: frame P: 3910, Avg QP:29.26 kb/s: 2266.71 PSNR Mean: Y:42.187 U:45.456 V:45.336 SSIM Mean: 0.966785 (14.787dB)
x265 [info]: frame B: 13489, Avg QP:31.23 kb/s: 469.21 PSNR Mean: Y:41.386 U:44.917 V:44.851 SSIM Mean: 0.965572 (14.631dB)
x265 [info]: Weighted P-Frames: Y:6.0% UV:4.7%
x265 [info]: Weighted B-Frames: Y:4.1% UV:2.8%
x265 [info]: consecutive B-frames: 10.8% 7.6% 5.9% 24.9% 21.6% 29.2%

encoded 17620 frames in 34506.66s (0.51 fps), 996.78 kb/s, Avg QP:30.73, Global PSNR: 42.449, SSIM Mean Y: 0.9659273 (14.676 dB)

Sagittaire

9th May 2020, 17:38

and I check Beamr 5 encoding stream: I think that this encoder use "zone encoding" or really constrained Rate Control to have higher quality in less complexes parts. But quality in complexes parts like high motion is really low. Compromise are good for my eyes. Anyway you can't compare Bearm encoding and x265 encoding with that.

size for 14135 -> 15062 frame credit zone (really complexe part with high bitrate in constant quantizer mode):

- x265, Placebo "Benwaggoner" encoding: 19 514 Ko (1300 Kbps)
- x265, Veryslow "Ma" encoding: 18 465 Ko
- x265, My 3 pass ABR encoding: 19 357 Ko
- x265, My crf encoding: 23 523 Ko (1568 Kbps)
- Bearm encoding: 15 145 Ko (1009 Kbps)

Imply 980 Kbps for first 14135 frames (without credit) for Bearm and 930 Kbps for first 14135 frames (without credit) for x265. It's 6% of size. It's the difference between slow versus placebo quality preset for x265 encoder. And at really low bitrate (1000 Kbps for 1080p), it's particulary high difference.

benwaggoner

9th May 2020, 22:34

Sagittaire

9th May 2020, 22:56

Wow, some good and interesting results. Thank you! And an excellent demonstration of the weakness of considering --preset a primary determinator of quality. For nearly all encodes, there are other tweaks that can be made that will produce better quality, faster than just cranking up preset. More passes are a classic example of using MIPS smarter instead of just harder. Heck, a simple --nr-inter 150 can be a bigger improvement than slower to placebo.

The only scenario I've seen where placebo really delivers materially better efficiency than slower is in lossless encoding, where placebo can be nearly 10% better than every veryslow with some sorts of content.

Can you share your settings for your best result encodes?

Yes I will make complete post when all my tests are finished. And actually I obtain really better quality than your old placebo encoding (for metric and my eyes), and by large margin at 1000 kbps.

Here all my encoding for 1000 kbps:

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> ToS encoding, 3 pass ABR, veryslow profil, high metric profil
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 1 --slow-firstpass --stats ToS-1000-abr.log --preset veryslow --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --no-limit-modes --ref 5 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --tskip --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 3 --stats ToS-1000-abr.log --preset veryslow --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --no-limit-modes --ref 5 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --tskip --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 2 --stats ToS-1000-abr.log --preset veryslow --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --no-limit-modes --ref 5 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --tskip --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao --analysis-save ToS_1000_R10-abr_analysis.dat --analysis-save-reuse-level 10 --csv ToS-1000-abr.csv --csv-log-level 1

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> ToS encoding, 3 pass ABR, veryslow profil, high speed reuse from 1000 kbps ABR encoding
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-hs.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 3 --stats ToS-1000-abr.log --preset veryslow --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --no-limit-modes --ref 5 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --tskip --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao --analysis-load ToS_1000_R10-abr_analysis.dat --analysis-load-reuse-level 10

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-hs.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 3 --stats ToS-1000-abr.log --preset veryslow --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --no-limit-modes --ref 5 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --tskip --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao --analysis-load ToS_1000_R10-abr_analysis.dat --analysis-load-reuse-level 10

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-hs.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 3 --stats ToS-1000-abr.log --preset veryslow --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --no-limit-modes --ref 5 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --tskip --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao --analysis-load ToS_1000_R10-abr_analysis.dat --analysis-load-reuse-level 10 --csv ToS-1000-hs.csv --csv-log-level 1

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> ToS encoding, 3 pass ABR, veryslow profil, default RC and PSY setting
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-psy.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 1 --slow-firstpass --stats ToS-1000-psy.log --preset veryslow --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --no-limit-modes --ref 5 --rd-refine --tskip --qg-size 64 --merange 64

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-psy.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 3 --stats ToS-1000-psy.log --preset veryslow --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --no-limit-modes --ref 5 --rd-refine --tskip --qg-size 64 --merange 64

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-psy.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 2 --stats ToS-1000-psy.log --preset veryslow --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --no-limit-modes --ref 5 --rd-refine --tskip --qg-size 64 --merange 64 --analysis-save ToS_1000_R10-psy_analysis.dat --analysis-save-reuse-level 10 --csv ToS-1000-psy.csv --csv-log-level 1

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> ToS encoding, 1 pass CFR, veryslow profil, highest metric profil
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-crf.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --crf 23.1 --pass 1 --slow-firstpass --stats ToS-1000-crf.log --preset veryslow --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --no-limit-modes --ref 5 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --tskip --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao --analysis-save ToS_1000_R10-crf_analysis.dat --analysis-save-reuse-level 10 --csv ToS-1000-crf.csv --csv-log-level 1

Opmox

9th May 2020, 23:25

deleted

benwaggoner

10th May 2020, 00:01

Interesting. I'm curious about what drove cg-size of 32 versus 64 and b-frames of of 5.

FWIW, 6 reference frames are actually legal here, since it is 1920x800 instead of 1080. Just as long as you don't apply DRM and try to play on a Qualcomm SoC :).

Sagittaire

10th May 2020, 00:08

Sagittaire

10th May 2020, 00:10

Careful with analysis-load-reuse-level, in my tests I had like ~800 psnr less, you can prevent this loss with refine-intra and refine-inter

yes but refine is dramatical speed loss ... ;-)

https://forum.doom9.org/showthread.php?p=1911278#post1911278

Sagittaire

10th May 2020, 01:02

Interesting. I'm curious about what drove cg-size of 32 versus 64 and b-frames of of 5.

Well I try that too with ToS ... ;-)

--qg-size 64 save 2% size (from my memory)

I try --hme --hme-search 0,1,3 --hme-range 24,48,64 versus --me-range 64 and really good result too. But hme is not compatible with analyse reuse (bug?).

This slower profil seem really good comprise between speed and quality. I wil test that for 1500 and 2000 encoding.

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> ToS encoding, 3 pass ABR, slower profil, high metric profil
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1500 --pass 1 --slow-firstpass --stats ToS-1500-abr.log --preset slower --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --ref 5 --limit-refs 3 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --qg-size 64 --hme --hme-search 0,1,3 --hme-range 24,48,64 --deblock -1,-1 --limit-sao

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1500 --pass 3 --stats ToS-1500-abr.log --preset slower --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --ref 5 --limit-refs 3 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --qg-size 64 --hme --hme-search 0,1,3 --hme-range 24,48,64 --deblock -1,-1 --limit-sao

x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1500 --pass 2 --stats ToS-1500-abr.log --preset slower --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --ref 5 --limit-refs 3 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --qg-size 64 --hme --hme-search 0,1,3 --hme-range 24,48,64 --deblock -1,-1 --limit-sao --csv ToS-1500-abr.csv --csv-log-level 1

Joekiwi

10th May 2020, 08:13

How well does NVENC do .?

Deleted as used wrong source - was quite surprised how high my y ssim score was - I might try again some other time

these were my settings anyway

NVEncC64.exe --vbrhq 1000 --codec h265 --preset quality --profile main10 --tier high --level 4.1 --output-depth 10 --max-bitrate 4000 --vbv-bufsize 12000 --aq-strength 1 --aq --aq-temporal --bref-mode each --bframes 4 --ref 5 --gop-len 120 --lookahead 32 --slices 1 --multiref-l0 4 --multiref-l1 2 --nonrefp --weightp --ssim --mv-precision q-pel --cabac -i

Joekiwi

10th May 2020, 09:10

Ok maybe disregard my last post - I'm using the wrong source - so probably it's probably a much easier to encode .
I just watched Bens' placebo encode and there was much more detail .
I just watched my source for the encode and it also lacked the detail.

I did download the 14 gb file - But when I unzipped it I got nothing - wasn't sure why - so downloaded another file mentioned later on that I think was only 579mbs ( from memory-I'm on a different PC ) .

So NVENC will be worst than my scores - still I can untick copy audio and get another 90 odd kbps to use . Ben did I need all those 4 files in your link to get the Source?

Sagittaire

10th May 2020, 10:21

I did download the 14 gb file - But when I unzipped it I got nothing - wasn't sure why - so downloaded another file mentioned later on that I think was only 579mbs ( from memory-I'm on a different PC ) .

Work for me. Perhpabs downloading problem?

Be carefull, Placebo Benwagonner encoding is really old encoding. And I suspect Rate Control problem (really bad quality in start scene). Ma's encoding produce really better overall quality. Bearm 4.5 encoding is really good too (be carefull it's zone encoding like real compressionnist encoding).

I'm using the wrong source - so probably it's probably a much easier to encode

Yes, Benwagonner use Dithering for make YV12 lossless source

Sagittaire

10th May 2020, 15:59

Well after many and many tests to find best x265 setting for this ToS source, here my result for only 1000 kbps at this moment. I will use he-aac 5.1 audio at 128 kbps for 1000 kbps, he-aac 5.1 audio at 160 kbps for 1500 kbps and lc-aac 5.1 audio at 192 kbps for 2000 kbps encoding:

WARNING: google drive make AVC transcoding for streaming. if you want to see real HEVC encoding, download the file.

1) crf 1 passe mode:
highest possible metric score in all mode
Preset "veryslow" for 1000 kbps and "optimized slower" for 1500 and 2000 kbps

ToS-1000-crf.mkv (https://drive.google.com/open?id=116WhVYBKrm8bI_qL64HxvKLk6pzrE9bm)
ToS-1500-crf.mkv (https://drive.google.com/open?id=126cXZy5sqtZnoTDJEAbYC-74gr7eJbjl)
ToS-2000-crf.mkv (https://drive.google.com/open?id=1ul_wTfnWdNwESExWCFIWvi4RR2kRzhmn)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-cfr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --crf 23.1 --pass 1 --slow-firstpass --stats ToS-1000-crf.log --qcomp 0.50 --preset veryslow --tune ssim --no-limit-modes --rd-refine --hevc-aq --qp-adaptation-range 1.0 --bframes 5 --b-adapt 2 --ref 5 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tskip --qg-size 64 --merange 64 --analysis-save ToS_1000_R10-crf1_analysis.dat --analysis-save-reuse-level 10 --deblock -1,-1 --limit-sao
x265 [info]: frame I: 221, Avg QP:27.27 kb/s: 11216.30 PSNR Mean: Y:43.857 U:46.103 V:46.112 SSIM Mean: 0.973372 (15.747dB)
x265 [info]: frame P: 3910, Avg QP:29.09 kb/s: 2844.64 PSNR Mean: Y:43.033 U:46.037 V:45.997 SSIM Mean: 0.971443 (15.443dB)
x265 [info]: frame B: 13489, Avg QP:36.49 kb/s: 296.98 PSNR Mean: Y:41.376 U:45.256 V:45.240 SSIM Mean: 0.967579 (14.892dB)
x265 [info]: Weighted P-Frames: Y:6.0% UV:4.8%
x265 [info]: Weighted B-Frames: Y:4.1% UV:2.8%
x265 [info]: consecutive B-frames: 10.8% 7.6% 5.9% 24.9% 21.6% 29.2%

encoded 17620 frames in 30340.70s (0.58 fps), 999.28 kb/s, Avg QP:34.73, Global PSNR: 42.688, SSIM Mean Y: 0.9685090 (15.018 dB)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-crf.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --crf 20.0 --preset slower --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --ref 5 --limit-refs 3 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --qg-size 64 --hme --hme-search 0,1,3 --hme-range 24,48,64 --deblock -1,-1 --limit-sao --csv ToS-1500-crf.csv --csv-log-level 1

encoded 17620 frames in 16079.49s (1.10 fps), 1504.59 kb/s, Avg QP:31.57, Global PSNR: 43.905, SSIM Mean Y: 0.9743358 (15.907 dB)

encoded 17620 frames in 18895.70s (0.93 fps), 2002.67 kb/s, Avg QP:29.41, Global PSNR: 44.772, SSIM Mean Y: 0.9775448 (16.487 dB)

2) ABR with 3 passes:
highest possible metric in NPass mode
Preset "veryslow" for 1000 kbps and "optimized slower" for 1500 and 2000 kbps

ToS-1000-abr.mkv (https://drive.google.com/open?id=1R1ulx9icVkKZqhT4CimknFdHLQo3WCZp)
ToS-1500-abr.mkv (https://drive.google.com/open?id=1JEGWR6F8nrnH-QBdQg7DluvSt6OQ9sZj)
ToS-2000-abr.mkv (https://drive.google.com/open?id=14eWSJpgFfbmTj2kkGV1ayFkdMmI-Gf-M)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 2 --stats ToS-1000.log --qcomp 0.50 --preset veryslow --tune ssim --no-limit-modes --rd-refine --hevc-aq --qp-adaptation-range 1.0 --bframes 5 --b-adapt 2 --ref 5 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tskip --qg-size 64 --merange 64 --analysis-save ToS_1000_R10-abr3_analysis.dat --analysis-save-reuse-level 10 --deblock -1,-1 --limit-sao
x265 [info]: frame I: 221, Avg QP:26.58 kb/s: 10729.30 PSNR Mean: Y:43.864 U:46.118 V:46.127 SSIM Mean: 0.972412 (15.593dB)
x265 [info]: frame P: 3910, Avg QP:29.26 kb/s: 2266.71 PSNR Mean: Y:42.187 U:45.456 V:45.336 SSIM Mean: 0.966785 (14.787dB)
x265 [info]: frame B: 13489, Avg QP:31.23 kb/s: 469.21 PSNR Mean: Y:41.386 U:44.917 V:44.851 SSIM Mean: 0.965572 (14.631dB)
x265 [info]: Weighted P-Frames: Y:6.0% UV:4.7%
x265 [info]: Weighted B-Frames: Y:4.1% UV:2.8%
x265 [info]: consecutive B-frames: 10.8% 7.6% 5.9% 24.9% 21.6% 29.2%

encoded 17620 frames in 34506.66s (0.51 fps), 996.78 kb/s, Avg QP:30.73, Global PSNR: 42.449, SSIM Mean Y: 0.9659273 (14.676 dB)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-abr.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1500 --pass 3 --stats ToS-1500-abr.log --preset slower --qcomp 0.50 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --ref 5 --limit-refs 3 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --qg-size 64 --hme --hme-search 0,1,3 --hme-range 24,48,64 --deblock -1,-1 --limit-sao --csv ToS-1500-abr.csv --csv-log-level 1

encoded 17620 frames in 16556.89s (1.06 fps), 1495.10 kb/s, Avg QP:27.88, Global PSNR: 43.626, SSIM Mean Y: 0.9724194 (15.594 dB)

encoded 17620 frames in 19555.37s (0.90 fps), 2000.35 kb/s, Avg QP:26.00, Global PSNR: 44.483, SSIM Mean Y: 0.9761716 (16.229 dB)

3) ABR with 3 passes with default setting:
default setting for rate control, adaptative quantisation and psy-rdo setting at same level research for me, cu, tu ... than crf (1) and abr (2) encoding.
Preset "veryslow" for 1000 kbps and "optimized slower" for 1500 and 2000 kbps.

ToS-1000-psy.mkv (https://drive.google.com/open?id=1ZMvYaqyevoRHuSwqCjMwGqvkhBKKVJ0S)
ToS-1500-psy.mkv (https://drive.google.com/open?id=1tLr6RiSfKgov-tHxmEBEIW-Sg11B3_fr)
ToS-2000-psy.mkv (https://drive.google.com/open?id=15A591qQ0JgS4-7mjH3wItbmBrcHkbAgL)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-psy.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 2 --stats ToS-1000-psy.log --preset veryslow --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --no-limit-modes --ref 5 --rd-refine --tskip --qg-size 64 --merange 64 --analysis-save ToS_1000_R10-psy1_analysis.dat --analysis-save-reuse-level 10 --csv ToS-1000-psy.csv --csv-log-level 1
x265 [info]: frame I: 221, Avg QP:28.02 kb/s: 10100.18 PSNR Mean: Y:43.571 U:45.588 V:45.560 SSIM Mean: 0.974445 (15.925dB)
x265 [info]: frame P: 3910, Avg QP:31.83 kb/s: 2542.81 PSNR Mean: Y:41.707 U:44.944 V:44.790 SSIM Mean: 0.968909 (15.074dB)
x265 [info]: frame B: 13489, Avg QP:37.81 kb/s: 403.79 PSNR Mean: Y:40.508 U:44.297 V:44.197 SSIM Mean: 0.965387 (14.608dB)
x265 [info]: Weighted P-Frames: Y:5.8% UV:4.7%
x265 [info]: Weighted B-Frames: Y:3.8% UV:2.6%
x265 [info]: consecutive B-frames: 10.8% 7.6% 5.9% 24.9% 21.6% 29.2%

encoded 17620 frames in 32709.81s (0.54 fps), 1000.07 kb/s, Avg QP:36.36, Global PSNR: 41.710, SSIM Mean Y: 0.9662820 (14.721 dB)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-psy.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1500 --pass 3 --stats ToS-1500-psy.log --preset slower --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --ref 5 --limit-refs 3 --rd-refine --qg-size 64 --hme --hme-search 0,1,3 --hme-range 24,48,64 --csv ToS-1500-psy.csv --csv-log-level 1

encoded 17620 frames in 17323.16s (1.02 fps), 1497.51 kb/s, Avg QP:33.00, Global PSNR: 43.081, SSIM Mean Y: 0.9728444 (15.661 dB)

encoded 17620 frames in 20365.97s (0.87 fps), 1997.96 kb/s, Avg QP:30.48, Global PSNR: 44.045, SSIM Mean Y: 0.9763138 (16.255 dB)

4) Reuse ABR with 3 passes :
transcoding from ABR 3 passes encoding veryslow at 1000 kbps (2) with analysis reuse statistique at really high speed (by factor ~100x)

ToS-1000-hs.mkv (https://drive.google.com/open?id=1Ei4etiAtB1crywdmppKgWpsRKi-bXeQ-)
ToS-1500-hs.mkv (https://drive.google.com/open?id=15zesNqvK079X_46SGzogd9leVAW9mLfh)
ToS-2000-hs.mkv (https://drive.google.com/open?id=1JZ73pzqVZXXQ6gOI_0zeMuJ4iOBTiHmm)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-hs.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 3 --stats ToS-1000.log --qcomp 0.50 --preset veryslow --tune ssim --no-limit-modes --rd-refine --hevc-aq --qp-adaptation-range 1.0 --bframes 5 --b-adapt 2 --ref 5 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tskip --qg-size 64 --merange 64 --analysis-load ToS_1000_R10-abr3_analysis.dat --analysis-load-reuse-level 10 --deblock -1,-1 --limit-sao

x265 [info]: frame I: 221, Avg QP:26.75 kb/s: 10671.81 PSNR Mean: Y:43.556 U:46.032 V:46.032 SSIM Mean: 0.971743 (15.489dB)
x265 [info]: frame P: 3910, Avg QP:29.48 kb/s: 2284.96 PSNR Mean: Y:41.984 U:45.347 V:45.232 SSIM Mean: 0.965561 (14.629dB)
x265 [info]: frame B: 13489, Avg QP:31.44 kb/s: 469.18 PSNR Mean: Y:41.190 U:44.813 V:44.752 SSIM Mean: 0.964374 (14.482dB)
x265 [info]: Weighted P-Frames: Y:6.0% UV:4.7%
x265 [info]: Weighted B-Frames: Y:4.1% UV:2.8%
x265 [info]: consecutive B-frames: 10.8% 7.6% 5.9% 24.9% 21.6% 29.2%

encoded 17620 frames in 431.14s (40.87 fps), 1000.08 kb/s, Avg QP:30.95, Global PSNR: 42.275, SSIM Mean Y: 0.9647300 (14.526 dB)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-hs.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1500 --pass 3 --stats ToS-1000.log --qcomp 0.50 --preset veryslow --tune ssim --no-limit-modes --rd-refine --hevc-aq --qp-adaptation-range 1.0 --bframes 5 --b-adapt 2 --ref 5 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tskip --qg-size 64 --merange 64 --analysis-load ToS_1000_R10-abr3_analysis.dat --analysis-load-reuse-level 10 --deblock -1,-1 --limit-sao

encoded 17620 frames in 477.85s (36.87 fps), 1499.96 kb/s, Avg QP:27.91, Global PSNR: 43.405, SSIM Mean Y: 0.9709562 (15.369 dB)

encoded 17620 frames in 485.03s (36.33 fps), 2001.12 kb/s, Avg QP:26.12, Global PSNR: 44.120, SSIM Mean Y: 0.9742588 (15.894 dB)

5) Reuse ABR with 3 passes, refine and psy optimisation :
transcoding from ABR 3 passes encoding veryslow at 1000 kbps (2) with analysis reuse statistique, highest possible refine level (higher speed by factor ~3x) and my best psy optimisation. Best result for my eyes.

ToS-1000-jfl.mkv (https://drive.google.com/open?id=1Tm2h5q6tbs0f5oB1Z1iRrZ93viXlCX1C)
ToS-1500-jfl.mkv (https://drive.google.com/open?id=16tf9qyh9-fNKdrAQ0-pp5X4yGctkCL5j)
ToS-2000-jfl.mkv (https://drive.google.com/open?id=1fhWCRjqBHdgSLzXfUVAUxTaSvrW1kcWR)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1000-jfl.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1000 --pass 3 --stats ToS-1000.log --qcomp 0.60 --preset veryslow --no-limit-modes --hevc-aq --qp-adaptation-range 1.0 --bframes 5 --b-adapt 2 --ref 5 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tskip --qg-size 64 --merange 64 --analysis-load ToS_1000_R10-abr3_analysis.dat --analysis-load-reuse-level 10 --deblock -1,-1 --limit-sao --rdoq-level 2 --psy-rdoq 1.0 --psy-rd 0.5 --refine-intra 4 --refine-inter 3

x265 [info]: frame I: 221, Avg QP:27.55 kb/s: 10061.19 PSNR Mean: Y:43.427 U:45.710 V:45.694 SSIM Mean: 0.972341 (15.582dB)
x265 [info]: frame P: 3910, Avg QP:30.28 kb/s: 2294.97 PSNR Mean: Y:41.977 U:45.093 V:44.928 SSIM Mean: 0.966663 (14.771dB)
x265 [info]: frame B: 13489, Avg QP:32.31 kb/s: 476.09 PSNR Mean: Y:41.138 U:44.526 V:44.419 SSIM Mean: 0.965165 (14.580dB)
x265 [info]: Weighted P-Frames: Y:6.0% UV:4.7%
x265 [info]: Weighted B-Frames: Y:4.1% UV:2.8%
x265 [info]: consecutive B-frames: 10.8% 7.6% 5.9% 24.9% 21.6% 29.2%

encoded 17620 frames in 12127.64s (1.45 fps), 999.93 kb/s, Avg QP:31.80, Global PSNR: 42.167, SSIM Mean Y: 0.9655874 (14.633 dB)

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1500-jfl.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1500 --pass 3 --stats ToS-1000.log --qcomp 0.60 --preset veryslow --no-limit-modes --hevc-aq --qp-adaptation-range 1.0 --bframes 5 --b-adapt 2 --ref 5 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tskip --qg-size 64 --merange 64 --analysis-load ToS_1000_R10-abr3_analysis.dat --analysis-load-reuse-level 10 --deblock -1,-1 --limit-sao --rdoq-level 2 --psy-rdoq 1.0 --psy-rd 0.5 --refine-intra 4 --refine-inter 3

encoded 17620 frames in 16147.07s (1.09 fps), 1500.61 kb/s, Avg QP:28.97, Global PSNR: 43.469, SSIM Mean Y: 0.9724217 (15.594 dB)

encoded 17620 frames in 14034.95s (1.26 fps), 1998.10 kb/s, Avg QP:27.03, Global PSNR: 44.305, SSIM Mean Y: 0.9759682 (16.192 dB)

Conclusion at 1000 kbps:

- For my eyes, my best encoding (5) produce better quality than default psy x265 setting (4) or previous ultraplacebo Benwagonner encoding, and by far. It's really good quality for only 1000 kbps encoding at 1080p. For me it's a really reasonable quality for streaming on a small screen ... or for reduced internet bandwidth due to COVID19 crisis. For comparison it's by far better quality level than Netflix "premium" quality for same bitrate.
- crf encoding (1) produce best metric and by far but not best visual quality for my eyes. crf encoding has really agressive quantizer for bframe and that mean lower relative quality for low complexity part. Anyway it's higher relative quality for high complexity part too. But this compromise is not good for my eyes at 1000 kbps. At this really low bitrate level (1000 kbps for 1080p source), I prefer high compression for rate control curve (more "cbr like" and less "vbr like").
- Encoding with default x265 setting (3) don't produce good quality for my eyes. There are many problems, particulary on the edge. Perhaps that these defaults psy setting are not good for really low bitrate.
- The most interessing encoding is certainely reuse ABR transcoding (4). I make ABR at "veryslow quality preset" but at stratospheric speed (40.87 fps for 1080p source with little i5 3550 CPU), in 3 passes to have best possible constant quality rate control curve. And the result is impressive. Really better result for my eyes than crf (1) or default setting (4).

Conclusion at 2000 kbps:

- All encoding produce really good quality. Quality difference between profil encoding are not really high like for 1000 kbps encoding. I make these encoding with optimized "slower" x265 profil for (1), (2) and (3), and I obtain equivalent quality than old previous benwagonner encoding with "ultra placebo" x265 profil.
- Default setting for x265 at 2000 kbps (3) produce really better relative subjective quality than for 1000 kbps encoding. At this quality level, default setting are really good.
- You can produce really good quality at high speed with reuse encoding without refine (4).
- My prefered setting for my eyes are always reuse encoding with refine and my psy optimisation (5). For my eyes this profil have better temporal stability, noise retention, and overall quality but this time, by a really small margin.

Opmox

11th May 2020, 10:12

deleted

Boulder

11th May 2020, 10:50

Joekiwi

11th May 2020, 11:33

Work for me. Perhpabs downloading problem?

Be carefull, Placebo Benwagonner encoding is really old encoding. And I suspect Rate Control problem (really bad quality in start scene). Ma's encoding produce really better overall quality. Bearm 4.5 encoding is really good too (be carefull it's zone encoding like real compressionnist encoding).

Yes, Benwagonner use Dithering for make YV12 lossless source

Thanks Sagittaire,
Will try again maybe later in week . I know NVENC will get absolutely slaughtered by yours and other encodes . - However I am curious .
I use to use paid software that promised superfast encoding speed ( ie via GPU ) . There are probably a lot of people out there like me - that used or still uses such software . - Since installing staxrip as a front end I feel I'm get much better results and that I'm in control.
I should really get to learn the x265 on CPU as well - easy on handbrake as only a few options - easy just to set CRF & preset - but will try to learn it on staxrip with it's myriad of options - or maybe just easier to grab someones command line and use the encoder directly-my Ryzen 3700x can handle it & still do NVENC coding at same time for no cost .

Without Bens' constraints GOP , max bit rate, vbv -I imagine your metrics would be quite better.

Maybe someone else can see good they can achieve by setting minimum 3fps encoding which is a good metric for encoding a movie while you sleep

Sagittaire

11th May 2020, 13:06

Here's another encode, same as before, no-sao but I changed rd 4 to 6 and me from umh to star, psnr went from 41.612 to 41.658 :confused:
ToS_x265_1M_41.658.mkv (http://www.mediafire.com/file/1ou8lgme5gxworx/ToS_x265_1M_41.658.mkv/file)

0.05 dB is ridiculous delta for "metric quality". and you can have small Rate Control difference to explain this delta. Choose the best way for your eyes ... ;-)

So you like everything blurry :D

mosquito noise are not detail and ringing are not texture retention ... :D

You have major problem in your encoding:
- Mosquito noise (it's not detail or noise retention but only encoding artefact)
- Ringing arround all the edge
- temporal blocking instability on flat part like the sky (certainely sao off)
- detail retention in low motion scene

I can make captures that will be terrible for your encoding.
There is a simple test to do: see if the flies(?) flying above the actress' head between frame 877 and 907 (37s to 38s) are visible. In your encoding it's not visible (or only on Pframe) simply because you have terrible ringing around the actress' head. Certainely because you have really high difference quality between inter and intra block (or between Pframe and bframe).
You have major temporal blocking and bluring on the rocket (18s to 25s) ... in fact it's the same problem for all the edge everywhere.

http://jfl1974.free.fr/Videos/ToS/Frame-892.jpg

I think that if you use really higher bitrate (with your setting), all your "detail" or "texture" will no longer be there ... :D

Sagittaire

11th May 2020, 13:38

Regarding comparisons of CRF vs. multipass: what's the verdict on doing the first pass with CRF and then running a second pass using the average bitrate that resulted from the CRF run? It won't work with this fixed bitrate level challenge, I was thinking more on the lines of squeezing some extra quality out of x265 if the 2-pass rate control seems to be better. Maybe there are also some options that could be left out of the CRF pass and activated only in the second pass to speed things up a bit (or use those reuse options)?

1) I just looked for the right crf value to reach the right bitrate (step 0.1 by step 0.1 for crf value). I try to use stat files from crf mode for make classic multipass mode but the result in not good (multipass encoding seem conserve the crf mode decision for I-P-B quantiser with the same ratio).

2) the right way would be to control the quantizer ratio between differents frames types but these command (--ip-ratio and -ib-ratio) seem doesen't work in the crf mode. (work in multipass mode)

Boulder

11th May 2020, 14:44

1) I just looked for the right crf value to reach the right bitrate (step 0.1 by step 0.1 for crf value).

2) the right way would be to control the quantizer ratio between differents frames types but these command (--ip-ratio and -ib-ratio) seem doesen't work in the crf mode. (work in multipass mode)

My thought was to run a CRF 18 encode with my usual script and settings and then run a second pass to utilize the rate control if it indeed is better. That way I would get the filesizes I'm used to without having to do any compressibility tests and get the best quality out of it. I was just thinking out loud if I can loosen any settings or reuse the analysis without affecting the whole idea too much.

The ratios should definitely work, they are for example a part of --tune grain so in case they don't, it should be reported as an issue in the tracker.

Sagittaire

11th May 2020, 15:25

My thought was to run a CRF 18 encode with my usual script and settings and then run a second pass to utilize the rate control if it indeed is better. That way I would get the filesizes I'm used to without having to do any compressibility tests and get the best quality out of it. I was just thinking out loud if I can loosen any settings or reuse the analysis without affecting the whole idea too much.

I make tests like that and with reuse encoding too. But like Rate Control work good with NPass, I don't investigate more. But it work. Work good, I don't know, but it's possible.

The ratios should definitely work, they are for example a part of --tune grain so in case they don't, it should be reported as an issue in the tracker.

In fact --ip-ratio and --ib-ratio doesn't work with --crf and --cu-tree on (RDO for AQ decision if my memory is good, but perhaps confusion with x264 here?). If you desactive cu-tree, ip-ratio and ib-ratio work with crf. And --tune grain desactive --cu-tree. In my memory --cu-tree off desactive all Adaptative Quantisation (psy way too).

Like I say, I make many and many test ... ;-)

benwaggoner

11th May 2020, 16:43

Here's another encode, same as before, no-sao but I changed rd 4 to 6 and me from umh to star, psnr went from 41.612 to 41.658 :confused:

The higher RD modes allow for more psychovisual optimizations, and those often reduce PSNR while they improve psychovisual quality. <0.5 PSNR shift isn't something that can be assumed to be better/worse without visual inspection.

Opmox

11th May 2020, 18:36

The higher RD modes allow for more psychovisual optimizations, and those often reduce PSNR while they improve psychovisual quality.
That make sense thanks!

mosquito noise are not detail and ringing are not texture retention ... :D
...
I think that if you use really higher bitrate (with your setting), all your "magical" detail will no longer be there ... :D

Wait, you can't see the difference here (https://slow.pics/c/JpCTppkx), here (https://slow.pics/c/F5N9jFI3) or here? (https://slow.pics/c/Q7TpM3Bv) :scared: I'm out

Sagittaire

11th May 2020, 19:37

That make sense thanks!

Wait, you can't see the difference here (https://slow.pics/c/JpCTppkx), here (https://slow.pics/c/F5N9jFI3) or here? (https://slow.pics/c/Q7TpM3Bv) :scared: I'm out

Will be better if you make capture for your encoding too ... ;-).

Anyway I confirm that I use highest possible curve rate compression (qcomp at 0.50) to have better quality in low motion and less in high motion. For this reason I prefer my ABR encoding to equivalent crf encoding.

Eyes are generaly more sensitive at detail and texture preservation in low motion part and less in high motion. It's for this reason that I prefer the Bearm encoding (HEVC encoder). But your eyes are perhaps more sensible at high motion scene (really short scene in this source). In this case, you can try encoding with higher qcomp default value (0.6 by default, 1.0 will be real VBR).

However I maintain that the quality for your encoding in the low motion scene is terrible. Temporal stability is catastrophic too in low motion. The rendering of moving objects in static scenes (like head movements for exemple) has really visible and have annoying temporal artifacts too. I prefer, and by far, my compromise for overall quality.

Anyway HVS is like taste and colors. Some prefer chocolate and others vanilla. Some users prefer x265 with sao and other not. But for my eyes your encoding is really bad, and particulary in scene introduction.

If Boulder or Benwagoner have an opinion ... ;-)

Boulder

13th May 2020, 15:32

In fact --ip-ratio and --ib-ratio doesn't work with --crf and --cu-tree on (RDO for AQ decision if my memory is good, but perhaps confusion with x264 here?). If you desactive cu-tree, ip-ratio and ib-ratio work with crf. And --tune grain desactive --cu-tree. In my memory --cu-tree off desactive all Adaptative Quantisation (psy way too).
They do work in CRF mode with cu-tree and AQ enabled.

P/B ratio 1.3
in:0 out:0 type:I q:21.94 q-aq:19.57 q-noVbv:21.94 q-Rceq:0.99 tex:582913 mv:9220 misc:2973 icu:3600.00 pcu:0.00 scu:0.00 ;
in:4 out:1 type:P q:21.94 q-aq:19.24 q-noVbv:21.94 q-Rceq:0.99 tex:614212 mv:13405 misc:3414 icu:3297.50 pcu:301.25 scu:1.25 ;
in:2 out:2 type:B q:23.08 q-aq:21.04 q-noVbv:23.08 q-Rceq:0.99 tex:386297 mv:23848 misc:6130 icu:959.50 pcu:2405.25 scu:235.25 ;
in:1 out:3 type:b q:24.21 q-aq:22.84 q-noVbv:24.21 q-Rceq:0.99 tex:221768 mv:22069 misc:7085 icu:288.50 pcu:2764.00 scu:547.50 ;
in:3 out:4 type:b q:24.21 q-aq:22.85 q-noVbv:24.21 q-Rceq:0.99 tex:234317 mv:23280 misc:6718 icu:393.75 pcu:2778.00 scu:428.25 ;
in:9 out:5 type:P q:21.94 q-aq:19.38 q-noVbv:21.94 q-Rceq:0.99 tex:589089 mv:11898 misc:3306 icu:3406.25 pcu:191.75 scu:2.00 ;
in:7 out:6 type:B q:23.08 q-aq:21.66 q-noVbv:23.08 q-Rceq:0.99 tex:346593 mv:21229 misc:5560 icu:1007.25 pcu:2402.25 scu:190.50 ;
in:5 out:7 type:b q:24.21 q-aq:22.80 q-noVbv:24.21 q-Rceq:0.99 tex:227102 mv:26712 misc:7243 icu:451.00 pcu:2715.25 scu:433.75 ;
in:6 out:8 type:b q:24.21 q-aq:22.80 q-noVbv:24.21 q-Rceq:0.99 tex:258433 mv:22466 misc:6381 icu:337.75 pcu:2954.25 scu:308.00 ;
in:8 out:9 type:b q:24.21 q-aq:22.78 q-noVbv:24.21 q-Rceq:0.99 tex:212971 mv:24199 misc:6965 icu:322.75 pcu:2758.50 scu:518.75 ;

P/B ratio 1.2
in:0 out:0 type:I q:21.94 q-aq:19.57 q-noVbv:21.94 q-Rceq:0.99 tex:582913 mv:9220 misc:2973 icu:3600.00 pcu:0.00 scu:0.00 ;
in:4 out:1 type:P q:21.94 q-aq:19.24 q-noVbv:21.94 q-Rceq:0.99 tex:614212 mv:13405 misc:3414 icu:3297.50 pcu:301.25 scu:1.25 ;
in:2 out:2 type:B q:22.73 q-aq:20.71 q-noVbv:22.73 q-Rceq:0.99 tex:414031 mv:24937 misc:6025 icu:972.75 pcu:2444.75 scu:182.50 ;
in:1 out:3 type:b q:23.52 q-aq:22.14 q-noVbv:23.52 q-Rceq:0.99 tex:271359 mv:22093 misc:6977 icu:381.75 pcu:2752.25 scu:466.00 ;
in:3 out:4 type:b q:23.52 q-aq:22.18 q-noVbv:23.52 q-Rceq:0.99 tex:284787 mv:22011 misc:6353 icu:424.25 pcu:2814.50 scu:361.25 ;
in:9 out:5 type:P q:21.94 q-aq:19.37 q-noVbv:21.94 q-Rceq:0.99 tex:589521 mv:12838 misc:3399 icu:3394.25 pcu:204.00 scu:1.75 ;
in:7 out:6 type:B q:22.73 q-aq:21.31 q-noVbv:22.73 q-Rceq:0.99 tex:376395 mv:20908 misc:5391 icu:1138.75 pcu:2305.75 scu:155.50 ;
in:5 out:7 type:b q:23.52 q-aq:22.15 q-noVbv:23.52 q-Rceq:0.99 tex:267303 mv:26748 misc:7184 icu:527.00 pcu:2682.50 scu:390.50 ;
in:6 out:8 type:b q:23.52 q-aq:22.11 q-noVbv:23.52 q-Rceq:0.99 tex:305806 mv:22149 misc:6090 icu:502.00 pcu:2792.75 scu:305.25 ;
in:8 out:9 type:b q:23.52 q-aq:22.21 q-noVbv:23.52 q-Rceq:0.99 tex:244590 mv:26586 misc:7529 icu:324.00 pcu:2809.75 scu:466.25 ;

benwaggoner

14th May 2020, 02:41

Well I try that too with ToS ... ;-)

--qg-size 64 save 2% size (from my memory)

But it also impairs the flexibility of AQ modes. Adaptive QP can only be done at a 64x64 block instead of 32x32. So if content changes within a 64x64 block, the encoder still has to use a single QP. Smaller qg-size allows for finer tuning for smaller details, but increases signalling overhead. Since metrics (even VMAF) kinda suck at measuring AQ gains, this is something that really need to be subjectively evaluated to see if the 2% gain is a worthwhile tradeoff.

This slower profil seem really good comprise between speed and quality. I wil test that for 1500 and 2000 encoding.
Yeah, slower is the preset where most of the advanced features of x265 and HEVC get enabled, with a lot of early exits and such so the perf hit isn't too bad. I use that as my starting point for pretty much anything.

Sagittaire

15th May 2020, 16:20

They do work in CRF mode with cu-tree and AQ enabled.

P/B ratio 1.3
in:0 out:0 type:I q:21.94 q-aq:19.57 q-noVbv:21.94 q-Rceq:0.99 tex:582913 mv:9220 misc:2973 icu:3600.00 pcu:0.00 scu:0.00 ;
in:4 out:1 type:P q:21.94 q-aq:19.24 q-noVbv:21.94 q-Rceq:0.99 tex:614212 mv:13405 misc:3414 icu:3297.50 pcu:301.25 scu:1.25 ;
in:2 out:2 type:B q:23.08 q-aq:21.04 q-noVbv:23.08 q-Rceq:0.99 tex:386297 mv:23848 misc:6130 icu:959.50 pcu:2405.25 scu:235.25 ;
in:1 out:3 type:b q:24.21 q-aq:22.84 q-noVbv:24.21 q-Rceq:0.99 tex:221768 mv:22069 misc:7085 icu:288.50 pcu:2764.00 scu:547.50 ;
in:3 out:4 type:b q:24.21 q-aq:22.85 q-noVbv:24.21 q-Rceq:0.99 tex:234317 mv:23280 misc:6718 icu:393.75 pcu:2778.00 scu:428.25 ;
in:9 out:5 type:P q:21.94 q-aq:19.38 q-noVbv:21.94 q-Rceq:0.99 tex:589089 mv:11898 misc:3306 icu:3406.25 pcu:191.75 scu:2.00 ;
in:7 out:6 type:B q:23.08 q-aq:21.66 q-noVbv:23.08 q-Rceq:0.99 tex:346593 mv:21229 misc:5560 icu:1007.25 pcu:2402.25 scu:190.50 ;
in:5 out:7 type:b q:24.21 q-aq:22.80 q-noVbv:24.21 q-Rceq:0.99 tex:227102 mv:26712 misc:7243 icu:451.00 pcu:2715.25 scu:433.75 ;
in:6 out:8 type:b q:24.21 q-aq:22.80 q-noVbv:24.21 q-Rceq:0.99 tex:258433 mv:22466 misc:6381 icu:337.75 pcu:2954.25 scu:308.00 ;
in:8 out:9 type:b q:24.21 q-aq:22.78 q-noVbv:24.21 q-Rceq:0.99 tex:212971 mv:24199 misc:6965 icu:322.75 pcu:2758.50 scu:518.75 ;

P/B ratio 1.2
in:0 out:0 type:I q:21.94 q-aq:19.57 q-noVbv:21.94 q-Rceq:0.99 tex:582913 mv:9220 misc:2973 icu:3600.00 pcu:0.00 scu:0.00 ;
in:4 out:1 type:P q:21.94 q-aq:19.24 q-noVbv:21.94 q-Rceq:0.99 tex:614212 mv:13405 misc:3414 icu:3297.50 pcu:301.25 scu:1.25 ;
in:2 out:2 type:B q:22.73 q-aq:20.71 q-noVbv:22.73 q-Rceq:0.99 tex:414031 mv:24937 misc:6025 icu:972.75 pcu:2444.75 scu:182.50 ;
in:1 out:3 type:b q:23.52 q-aq:22.14 q-noVbv:23.52 q-Rceq:0.99 tex:271359 mv:22093 misc:6977 icu:381.75 pcu:2752.25 scu:466.00 ;
in:3 out:4 type:b q:23.52 q-aq:22.18 q-noVbv:23.52 q-Rceq:0.99 tex:284787 mv:22011 misc:6353 icu:424.25 pcu:2814.50 scu:361.25 ;
in:9 out:5 type:P q:21.94 q-aq:19.37 q-noVbv:21.94 q-Rceq:0.99 tex:589521 mv:12838 misc:3399 icu:3394.25 pcu:204.00 scu:1.75 ;
in:7 out:6 type:B q:22.73 q-aq:21.31 q-noVbv:22.73 q-Rceq:0.99 tex:376395 mv:20908 misc:5391 icu:1138.75 pcu:2305.75 scu:155.50 ;
in:5 out:7 type:b q:23.52 q-aq:22.15 q-noVbv:23.52 q-Rceq:0.99 tex:267303 mv:26748 misc:7184 icu:527.00 pcu:2682.50 scu:390.50 ;
in:6 out:8 type:b q:23.52 q-aq:22.11 q-noVbv:23.52 q-Rceq:0.99 tex:305806 mv:22149 misc:6090 icu:502.00 pcu:2792.75 scu:305.25 ;
in:8 out:9 type:b q:23.52 q-aq:22.21 q-noVbv:23.52 q-Rceq:0.99 tex:244590 mv:26586 misc:7529 icu:324.00 pcu:2809.75 scu:466.25 ;

yes, my bad. I recheck my test and you are right. However I understood my error. For me, --pbratio 1.00 mean the same average quantizer for pframes and bframes. And it's the case for Npass mode but not for crf mode:

- In crf mode

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --crf 25.0 --preset fast --qcomp 0.60 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --ref 5 --limit-refs 3 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao --frames 1332 --seek 214 --ipratio 1.40 --pbratio 1.00
x265 [info]: frame I: 16, Avg QP:24.65 kb/s: 17300.27 PSNR Mean: Y:43.462 U:45.390 V:45.166 SSIM Mean: 0.978414 (16.658dB)
x265 [info]: frame P: 275, Avg QP:28.94 kb/s: 2716.00 PSNR Mean: Y:40.881 U:43.748 V:43.285 SSIM Mean: 0.967960 (14.943dB)
x265 [info]: frame B: 1041, Avg QP:33.59 kb/s: 542.67 PSNR Mean: Y:40.540 U:44.024 V:43.546 SSIM Mean: 0.966582 (14.760dB)
x265 [info]: Weighted P-Frames: Y:2.2% UV:1.8%
x265 [info]: consecutive B-frames: 9.3% 1.4% 2.4% 25.4% 32.3% 29.2%

encoded 1332 frames in 128.92s (10.33 fps), 1192.66 kb/s, Avg QP:32.52, Global PSNR: 41.421, SSIM Mean Y: 0.9670086 (14.816 dB)

- In NPass mode

D:\Mes Logiciels\Codec\x265>x265.exe --input C:\ToS_1920x800_xdither.y4m --output ToS-1.265 --input-res 1920x800 --output-depth 10 --fps 24000/1000 --bitrate 1192 --pass 3 --preset fast --qcomp 0.60 --bframes 5 --b-adapt 2 --min-keyint 1 --keyint 120 --rc-lookahead 60 --vbv-maxrate 4000 --vbv-bufsize 12000 --psnr --ssim --tune ssim --ref 5 --limit-refs 3 --rd-refine --hevc-aq --qp-adaptation-range 1.0 --qg-size 64 --merange 64 --deblock -1,-1 --limit-sao --frames 1332 --seek 214 --ipratio 1.40 --pbratio 1.00
x265 [info]: frame I: 16, Avg QP:28.06 kb/s: 10449.46 PSNR Mean: Y:41.454 U:43.768 V:43.453 SSIM Mean: 0.966755 (14.783dB)
x265 [info]: frame P: 275, Avg QP:30.44 kb/s: 2208.40 PSNR Mean: Y:39.873 U:42.736 V:42.292 SSIM Mean: 0.960179 (13.999dB)
x265 [info]: frame B: 1041, Avg QP:30.23 kb/s: 776.34 PSNR Mean: Y:40.138 U:43.218 V:42.801 SSIM Mean: 0.961323 (14.125dB)
x265 [info]: Weighted P-Frames: Y:2.5% UV:2.2%
x265 [info]: consecutive B-frames: 9.3% 1.4% 2.4% 25.4% 32.3% 29.2%

encoded 1332 frames in 145.19s (9.17 fps), 1188.19 kb/s, Avg QP:30.24, Global PSNR: 40.803, SSIM Mean Y: 0.9611523 (14.106 dB)

mandarinka

17th May 2020, 16:42

WOW.

That is truly impressive. This reinforces my belief that film grain modeling is enormously important and will really make 1 Mbps 1080p totally viable. This is a game changing feature for AV1!

Do any of the encoders have / plan to integrate this in-loop during encoding? Working with YUV intermediates is pretty painful.

If you leave the denoising part to the encoder, it will probably use something bad that will remove legitimate non-noise detail from the base picture under it. Most standalone denoisers actually do, so using some of the rare exceptions tuned for better quality should be done.

I guess the huge problem here is now that even the good denoisers can't be made to not remove any details if you use the strengths that are required to remove all the noise content.

Sagittaire

17th May 2020, 20:33

I guess the huge problem here is now that even the good denoisers can't be made to not remove any details if you use the strengths that are required to remove all the noise content.

Well retain grain/noise is bitrate problem. All the codec can retain noise if you use suffisant bitrate for that. Retain grain is problem at low bitrate and at low bitrate, the codec itself remove detail/grain/noise. And soft denoising is not problem in this case simply because codec will make strong denoising by itself. For me FGM is really usefull in "low bitrate" situation exactly like for this "1000 kbps / 1080p" challenge encoding.

benwaggoner

21st May 2020, 22:42

Well retain grain/noise is bitrate problem. All the codec can retain noise if you use suffisant bitrate for that. Retain grain is problem at low bitrate and at low bitrate, the codec itself remove detail/grain/noise. And soft denoising is not problem in this case simply because codec will make strong denoising by itself. For me FGM is really usefull in "low bitrate" situation exactly like for this "1000 kbps / 1080p" challenge encoding.
Yeah. FGM alone can probably save 20% off this particular challenge.

Sagittaire

23rd May 2020, 17:15

First denoise the video
ffmpeg -i ToS.y4m -vf nlmeans=s=1.5 denoised.yuv
Then use the noise_model application located under ./examples/noise_model: https://aomedia.googlesource.com/aom/+/master/examples/noise_model.c
noise_model --fps=24/1 --width=1920 --height=800 --i420 --input-denoised=denoised.yuv --input=ToS.yuv --output-grain-table=film_grain.tbl
I only kept sY sCb and sCr because the generated .tbl didn't look good.

well I read this paper:
https://norkin.org/pdf/DCC_2018_AV1_film_grain.pdf

In fact I think that you must encode denoised.yuv and FGM will add grain after stream decoding.

It's logical because if you use FGM at medium/high bitrate with noisy source, codec will able to retain noise and FGM will add more noise at this same encoding natively noised.

The good way seem to be:

ffmpeg -i ToS.y4m -vf nlmeans=s=1.5 denoised.yuv

noise_model --fps=24/1 --width=1920 --height=800 --i420 --input-denoised=denoised.yuv --input=ToS.yuv --output-grain-table=film_grain.tbl

aomenc --passes=2 --pass=2 --fpf=firstpass.log --target-bitrate=1220 --kf-max-dist=120 --cpu-used=0 -t 4 --deltaq-mode=2 --film-grain-table=film_grain.tbl -o AV1-0.ivf denoised.yuv

I will try that. Where I can find compiled noise_model.exe ?

Tadanobu

23rd May 2020, 17:40

Here is one https://drive.google.com/open?id=1T3POhbwvmRsRgNJhv_Lwkx9tmnqaTCyj

Built for Windows 2 months ago.

benwaggoner

24th May 2020, 19:44

well I read this paper:
https://norkin.org/pdf/DCC_2018_AV1_film_grain.pdf

In fact I think that you must encode denoised.yuv and FGM will add grain after stream decoding.

It's logical because if you use FGM at medium/high bitrate with noisy source, codec will able to retain noise and FGM will add more noise at this same encoding natively noised.
The task of denoising with parameterization so the noise can be reconstructed is a tricky one. And doesn't need to be normative in an encoder, so they punted that part?

Blue_MiSfit

29th May 2020, 22:49

benwaggoner

29th May 2020, 23:16

Is it reasonable to generate the grain table with a heavily denoised reference, yet do the actual encoding with a more gently denoised clip?

I've found that getting full grain elimination using tools like SMDegrain or KNLMeansCL requires some pretty heavy handed settings, which can result in the plastic face effect. The grain synthesis is really nice, but I'd like to dial back the denoising strength when actually encoding a bit.
Sounds like a worthy experiment. I can imagine that the grain at playback could wind up being more intense than in the source if the grain table is based assuming more grain was removed than actually was.

quietvoid

30th May 2020, 03:34

Is it reasonable to generate the grain table with a heavily denoised reference, yet do the actual encoding with a more gently denoised clip?Yes, that is a good way of doing it. That way it's helping the encoder, but it's probably doing a filter pass either way so more detail might get wiped in the actual encode (maybe).
It's at least better than leaving aomenc do the denoise and the grain modeling at the same time, because it's using very basic denoise methods.

H2sixty

12th October 2020, 01:29

how was the source file created?

excellentswordfight

12th October 2020, 09:05

how was the source file created?
https://mango.blender.org/about/

https://media.xiph.org/tearsofsteel/

H2sixty

12th October 2020, 12:40

https://mango.blender.org/about/

https://media.xiph.org/tearsofsteel/

benwaggoner's file is not listed there, and it says dithered in his download file name. i assume its a dithered copy made from the website file...

benwaggoner

12th October 2020, 17:01

benwaggoner's file is not listed there, and it says dithered in his download file name. i assume its a dithered copy made from the website file...
Yes, I rendered it out from the 4K 16-bit PNG files.

IIRC, I went from those to uncompressed v210 in After Effects, and then used FFMPEG for the final conversion to yuv420p .y4m, using xdither.

benwaggoner

7th December 2020, 18:06

Thanks for the 2 Mbps AV1. Could you also try a 1 Mbps and a 500 Kbps? We've got samples at those rates in other codecs.

easyfab

25th April 2021, 20:01

First try with VVC codec and vvencapp codec (Fraunhofer Versatile Video Encoder )

tos.266 -> https://www.sendspace.com/file/qk2ko0

vvencapp -i ToS_1920x800_xdither.yuv -s 1920x800 -r 24 --preset fast -q 29 -o tos.266

Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR
17620 a 912.8453 52.1495 59.0134 58.8494 40.7851

Total Time: 5167.89 sec. Fps(avg): 3.40952 encoded Frames 17620

I don't know a player that decode vvc, I'm using vvdecapp + mpv to play it for the moment :

vvdecapp -b tos.266 -o - | mpv.com --demuxer=rawvideo --demuxer-rawvideo-w=1920 --demuxer-rawvideo-h=800 --demuxer-rawvideo-mp-format=yuv420p10le --demuxer-rawvideo-fps=24 -

or to use with ffmpeg to do what you want :

vvdecapp -b tos.266 -o - | ffmpeg -f rawvideo -s 1920x800 -r 24 -pix_fmt yuv420p10le -i - ....

Here a build of vvcdecapp for those who don't want to build the source : https://www.sendspace.com/file/uhc8j6

dipje

28th May 2021, 22:48

Here is one https://drive.google.com/open?id=1T3POhbwvmRsRgNJhv_Lwkx9tmnqaTCyj

Built for Windows 2 months ago.

Any new link? MSVC 2019 build-tools are installing, but finding a compiled version to play around with will make life easier :s.

benwaggoner

3rd June 2021, 22:29

I've finally added a new source for the challenge, an interesting hybrid anime/CGI title. Links and details in the updated first post (https://forum.doom9.org/showthread.php?p=1853595#post1853595).

It's got some very different properties from Tears of Steel that should stress different encoder features. I look forward to seeing what we all can do with it!

benwaggoner

7th June 2021, 20:19

Here's my first test encode, at 1 Mbps ABR.

https://1drv.ms/v/s!AlvIQZWsyeO-k9ly-nzoNI3Uqa-TPQ?e=baJVUi

Even though a ton of its runtime is just white text/graphics on black, it's still a MUCH harder clip to encode than Tears of Steel. Perhaps something could be done with --zones to further save bits from the credits sections to help the hard bits.

I've not done any actual tuning with the parameters. I just did a 2-pass placebo with --tune animation and throwing in a bunch of other features that would hopefully help with this kind of content. So --cu-lossless and --tskip for all the very sharp lines in the text

I did a simple --tune animation --preset slower without the fancy stuff and quality and bit distribution came out pretty much the same; just a hair lower . Which confirms the extra stuff didn't cause some qualitative regression. As expected, 20x faster with -1.5 dB PSNR and -0.22 dB SSIM.

Looking at the .csv log file, it seems that --frame-dup didn't actually set any frames to dup. so raising the threshold there might be helpful. Maybe the dithering added just that extra bit of noise?

I'm not sure if --tune animation is appropriately tuned either. I fear that preset is exactly copied from an email I sent a x265 dev extrapolating a starting point for tuning a --tune animation, and I know I didn't do adequate testing of it :sly:.

I doubt this is a clip that particularly benefits from --hme either.

I should also try --hevc-aq for comparison.

x265.exe --input SolLevante_SDRv2_1080p24_8bit.y4m --level-idc 4.0 --preset placebo --pass 1 --ref 5 --bframes 16 -F 1 --hme --hme-search 2,3,4 --fades --frame-dup --tune animation --tskip --cu-lossless --rd-refine --multi-pass-opt-analysis --multi-pass-opt-distortion --keyint 120 --rc-lookahead 120 --bitrate 1000 --vbv-maxrate 12000 --hrd --aud --vbv-bufsize 12000 --colorprim bt709 --transfer bt709 --colormatrix bt709 -o SolLevante_SDR-1080p_1000_placebo_p1.hevc --psnr --ssim --csv-log-level 1 --analysis-reuse-file SolLevante_SDR-1080p_1000_placebo.dat --stats SolLevante_SDR-1080p_1000_placebo.stats --csv SolLevante_SDR-1080p_1000_placebo_p1.csv

x265.exe --input SolLevante_SDRv2_1080p24_8bit.y4m --level-idc 4.0 --preset placebo --pass 2 --ref 5 --bframes 16 -F 1 --hme --hme-search 2,3,4 --fades --frame-dup --tune animation --tskip --cu-lossless --rd-refine --multi-pass-opt-analysis --multi-pass-opt-distortion --keyint 120 --rc-lookahead 120 --bitrate 1000 --vbv-maxrate 12000 --vbv-bufsize 12000 --hrd --aud --colorprim bt709 --transfer bt709 --colormatrix bt709 -o SolLevante_SDR-1080p_1000_placebo_p2.hevc --psnr --ssim --csv-log-level 1 --analysis-reuse-file SolLevante_SDR-1080p_1000_placebo.dat --stats SolLevante_SDR-1080p_1000_placebo.stats --csv SolLevante_SDR-1080p_1000_placebo_p2.csv

rwill

7th June 2021, 22:05

Your rules state:
4 Mbps peak bitrate

You specified:
--vbv-maxrate 12000

benwaggoner

8th June 2021, 17:59

Your rules state:
4 Mbps peak bitrate

You specified:
--vbv-maxrate 12000
Crap! Good catch. Will fix ;).

videoh

9th June 2021, 01:23

Why is this thread a sticky? Is it to spam your obsolete book? Just wondering.

rwill

9th June 2021, 06:32

Why is this thread a sticky? Is it to spam your obsolete book? Just wondering.

What is this forum for anyway ?

To advertise x265 binary builds no one runs ?
A place for foreign students to get their university multimedia assignments solved without the need to do any work ?
Another place for trolls to unleash their time wasting and irritating nonsense posts ?

Now regarding this encoding challenge I could post some Sol Levante encode like this which is quite different from Bens:
https://drive.google.com/file/d/16yag48bOLoAUjmiOEeB_9WPa7DZEkYsL/view?usp=sharing

And then people would take a look and compare and discuss and whatnot.

But no, people nowadays are more interested to post pictures on Insta and toxic one liners on Twitter. Makes no sense to do an encoding challenge with most people on this BBS anyway as everyone only has access to x265 which is a broken encoder. Encoding the sequence in high quality AV1 will take a year and other OSS encoders are still in their infancy. And I get an aneurysm every time I see someone doing encodes at a medium like preset and then still complains about encoding speed because in their opinion it runs too slow on their 15 year old 4 core SSE2 CPU.

benwaggoner

9th June 2021, 18:56

If y'all don't like Doom9, you're welcome to not participate, or suggest a better place for these kinds of discussions.

We've had a variety of tests in this challenge provided in a variety of codecs and encoders.

Gravitator

11th June 2021, 12:05

Here's my first test encode, at 1 Mbps ABR.

https://1drv.ms/v/s!AlvIQZWsyeO-k9ly-nzoNI3Uqa-TPQ?e=baJVUi

3m:35s-3m:40s dirt hangs from under the picture on the left.

Gravitator

14th August 2021, 07:46

Here a build of vvcdecapp for those who don't want to build the source : https://www.sendspace.com/file/uhc8j6
Can you update the link to the decoder?

Forteen88

16th August 2021, 06:58

x265 which is a broken encoderYou mean that not just SAO is broken in x265?

benwaggoner

17th August 2021, 00:21

You mean that not just SAO is broken in x265?
--hist-scenecut has been broadly found to be defective
--frame-dup doesn't appear to do anything in my tests

Forteen88

17th August 2021, 08:01

--hist-scenecut has been broadly found to be defective
--frame-dup doesn't appear to do anything in my testsThanks. Good that I haven't used those options in my encodes, and I've set --no-sao.

rwill

17th August 2021, 15:37

The rate control is also producing questionable results, especially with VBV constraints. The problem is that currently it is not guaranteed that x265 produces a consistently better picture when increasing the bitrate. There are also problems with ABR and hitting a target rate when the sequence is complex. For 99.9% of scenes in a movie the results are good but the 0.1% where it breaks is a real problem. People will remember the 0.1% where the immersion is ruined badly due to artifacts. A movie consists of around 170000 pictures, good luck not hitting that 0.1%. See the x265 encoder thread page 406 in this forum about Stacey Spears’ trial of encoding a HEVC BluRay at 90Mbit. The Deer picture has a VMAF of above 90.

So when you run bitrate ladders you are forced to QC each rung, not only the lowest bitrate of each resolution to check if the quality is ok. You cannot trust objective metrics like VMAF or PSNR to detect the errors x265 produces. When you have a 2 hour movie and generate 12 resolution/bitrate combinations thats 24 hours someone has to watch. Archiving that BluRay collection ? You better watch the stream thoroughly before you put it away as a backup.

And when there are encode problems, what are you gonna do ? Frame threads to 1 ? Wavefronts off ? Google it ? Asking for Help on Doom9 ? Couple days of trial and error and you might be able to work around the problem. Hand crafted streams….

Waste of time and resources.

Sure x265 is free but there are recurring problems no one is fixing. Heck, I’d rather try to use Linux on the Desktop again before fixing an x265 encode problem again by twiddling with parameters. You know, a Linux with printing, scanning and doing regular component updates which break half of what I have already set up. I know there are people which value their time at or below minimum wage but I am not one of them.

benwaggoner

17th August 2021, 18:24

Sure x265 is free but there are recurring problems no one is fixing. Heck, I’d rather try to use Linux on the Desktop again before fixing an x265 encode problem again by twiddling with parameters. You know, a Linux with printing, scanning and doing regular component updates which break half of what I have already set up. I know there are people which value their time at or below minimum wage but I am not one of them.
What do you use instead of x265?

rwill

17th August 2021, 19:45

What do you use instead of x265?

Oh, has my PM not reached you ?

Fishman0919

25th August 2021, 16:45

I did a test with Tears of Steel (ToS_1920x800_xdither.y4m) downloaded from the first post.

Used x265 3.5+1 with Vidcoder to make it easy for the test.

I started with Medium preset and went up to Placebo.
I did a few encodings with preset medium and HME.

CRF-23 keyint=250:min-keyint=23:aq-mode=3 was my base settings.

17860

Seems x265's presets need a little tuning.

the Medium-test encoding was with these settings

keyint=250:min-keyint=23:aq-mode=3:subme=7:rd=5:hme=1:hme-range=24,48,72:hme-search=star,star,star:rc-lookahead=90:bframes=8:early-skip=0:rskip=2:selective-sao=4:b-intra=1:max-merge=5:ref=5:lookahead-slices=1:rect=1:amp=1:limit-refs=0:b-intra=1:weightb=1:rd-refine=1

takla

26th August 2021, 13:41

https://www.mediafire.com/file/gj66iaq0uqg1x58/Sol_Levante.webm/file

ffmpeg -benchmark -i INPUT.mkv -c:v libvpx-vp9 -b:v 2M -pass 1 -cpu-used 1 -row-mt 1 -g 120 PASS-1.webm
time=51.304s

ffmpeg -benchmark -i INPUT.mkv -c:v libvpx-vp9 -b:v 2M -pass 2 -cpu-used 1 -row-mt 1 -g 120 PASS-2.webm
time=1164.221s

CPU used was AMD Ryzen 9 3900X.
Personally, I wouldn't bother watching that clip with anything under 10Mbps (Except maybe AV1 with -cpu-used 1 at ~8Mbps). 2Mbps is far from "realistic" in this scenario.

I also wouldn't bother with x265 since it would perform worse, as it always does in my comparisons.

Gravitator

30th August 2021, 13:30

Tears of Steel VVenC 1mbps: https://drive.google.com/file/d/1shmEm5cRMAUgw5THII5bn2vJ0haO0hci/view?usp=sharing

Thanks! On dark scenes, the quality is just disgusting (8-bit).

benwaggoner

2nd September 2021, 18:43

Thanks! On dark scenes, the quality is just disgusting (8-bit).
Low luma in 8-bit SDR requires a fair amount of psychovisual optimization due to the nonlinearity of Rec. 709's EOTF compared to human perception. --aq-mode 3's bias for lower QP in dark regions is the right idea, albeit too aggressive.

PSNR and VMAF don't capture that nonlinearity, so encoders tuned for those metrics tend to have issues in dark regions.

Gravitator

5th September 2021, 06:01

--aq-mode 3's bias for lower QP in dark regions is the right idea, albeit too aggressive.
I propose to prohibit the use of 8-bit! This castrated regime stifles the potential of modern encoders.

Asmodian

7th September 2021, 01:02

I propose to prohibit the use of 8-bit! This castrated regime stifles the potential of modern encoders.

If we are proposing unrealistic prohibitions, can I add chroma subsampling to the list? :mad:

Gravitator

7th September 2021, 13:18

If we are proposing unrealistic prohibitions, can I add chroma subsampling to the list? :mad:
Why not realistic? After all, it is reasonable.
Ordinary users do not know about chrome. According to an old habit, they will put 8bit - get the worst result (horror movies at low bitrates).

benwaggoner

7th September 2021, 23:00

I propose to prohibit the use of 8-bit! This castrated regime stifles the potential of modern encoders.
This specific test is 8-bit specific, mainly because comparing 8-bit encodes is less fraught.

But a 10-bit HDR test would be an obvious next step. Perhaps with Sol Levante.

Mr.Rippley

12th October 2021, 19:27

benwaggoner

12th October 2021, 23:41

###Hi! I decided to learn how to efficiently encode video using HEVC. What is needed for this? Some special software or coding settings should be set "very slowly". Now I use StaxRip 2.8. I would like to achieve the quality and size of the video as on the PSA website, there are just magicians(IMHO). Unfortunately, I can't learn from them because they erase the attributes of their video files, so the encoding parameters are not visible in the media. ### At first I decided to write this, but after reading this forum I fell into antagonism. For many years I studied MPEG2 and DV coding, since I worked in television. Then I studied DivX and AVC for myself. For the last couple of years I have been trying to master HEVC (only 10 bits) to the maximum... Now it turns out that this codec is defective, sorry, not perfect. And yet, can anyone answer me the ### question ### at the beginning of the post? The best coding program(GUI) for Windows? What are the most important settings, parameters? Or just set a placebo preset?
You can use whatever you want to submit something. It's not like there's a prize or anything :sly:! The goal is to produce the best looking file that's playable in an available video player within the specified technical parameters (of which there aren't many).

No codec is effective, and pretty much everything shared so far started with a placebo preset and was tuned from there.

But you can post whatever you like; it's not like you'll be kicked out or anything if you can't beat the previous best efforts.

jcj

30th December 2021, 00:50

Here's my submissions for ToS and Sol. All of these encodes are done with --preset veryslow --no-cutree --keyint 120 --rc-lookahead 120 --vbv-maxrate 4000 --vbv-bufsize 12000, and 5 passes. I made some small modifications to improve the 2pass rate control - https://pastebin.com/0vYpLmf3 https://pastebin.com/S8x2VEa4

ToS 1M: https://www.mediafire.com/file/bqac9a7ws14b1e5/tos-1000-vsl-nocutree-psy1_50-p5.mkv/file
The ToS encode additionally has --psy-rd 1 --psy-rdoq 50

Sol 1M: https://www.mediafire.com/file/9zndceg12wedjkp/sol-1000-vsl-nocutree-psy1_0-db3-aq3-p5.mkv/file
Sol 2M: https://www.mediafire.com/file/l60gtmsaba3ihfg/sol-2000-vsl-nocutree-psy1_0-db3-aq3-p5.mkv/file
The Sol encodes additionally have --psy-rd 1 --psy-rdoq 0 --deblock 3:3 --fades

Using --no-cutree is the key to good quality for ToS. The slow scenes are vastly improved, with better facial texture and less artifacts in moving areas. I think this is the best 1M ToS x265 encode to date.

For Sol, --no-cutree doesn't seem to make a difference. The 2M is better than the 2M VP9. The 1M is comparable to rwill's H265. It's better in the fast scenes and worse in the slow scenes.

rwill

1st March 2022, 20:10

Although it is Work In Progress here are EVC Baseline Profile Encodes of ToS and Sol Levante:
https://drive.google.com/drive/folders/1plFE_-kqDrWs_rqYaHMkVWqxgQyCvQvo

I used my encoder.

You need a somewhat working decoder to decode the streams, you can get one here (in source form):
https://github.com/rwillenbacher/xevd

I am not happy with how all pictures look etc. but I think it turned out ok, given its early in encoder development.

benwaggoner

7th March 2022, 17:46

rwill

8th March 2022, 08:09

Would folks be interested in my providing a 10-bit SDR of Tears of Steel for testing? 10-bit support is mandatory for AV1 and nigh universal for HEVC now.

For your encoding challenge ?

I don't think that for ToS 8 or 10 bit makes a real difference as an encoder can only produce, I take a very rough estimate here, 6.5 bits precision on average at these low bitrates.

Might be interesting academically though.

Forteen88

4th May 2022, 08:10

--psy-rdoq 50
Doesn't that create LOTS of noise?!

benwaggoner

4th May 2022, 19:13

For your encoding challenge ?

I don't think that for ToS 8 or 10 bit makes a real difference as an encoder can only produce, I take a very rough estimate here, 6.5 bits precision on average at these low bitrates.
I'm not sure if you're measuring "bits of precision" in a relevant way. Certainly the encode will have output with smooth histograms over the 8- and 10-bit ranges. Frequency domain and raster precision have quite different visual impact.

Extra input precision means less dithering is required, and thus less extra noise.

rwill

4th May 2022, 20:22

I'm not sure if you're measuring "bits of precision" in a relevant way. Certainly the encode will have output with smooth histograms over the 8- and 10-bit ranges. Frequency domain and raster precision have quite different visual impact.

Extra input precision means less dithering is required, and thus less extra noise.

I mean something like SNR. Thats why I wrote 'very rough estimate'.

The higher the quantization the less important the bit depth and associated dithering becomes. I mean if dithering is quantized away anyway its only purpose is to generate some sort of local higher precision for low frequency components to avoid banding, blocking and sorts. So my guess is that it does not matter if the input is 8 or 10 bit if a H.265 encoder is in QP >= 30 regions most of the time anyway.

I know some people are adding dithering/noise to encodes but am just unable to see any reason to use it with encodes where quantization is so high that it will not have a meaningful impact on the end result because the precision of the input is vastly higher than what can be reconstructed after a high quantization. We do have Deblocking Filters now...

@Forteen88

It will not create noise but one will most likely lose the coding efficiency benefits of RDOQ.

HD MOVIE SOURCE

13th September 2022, 04:46

Would folks be interested in my providing a 10-bit SDR of Tears of Steel for testing? 10-bit support is mandatory for AV1 and nigh universal for HEVC now.

And for HDR testing, is there a preference between 1080p or 2160p? 1080p is faster to encode and easier to compare, but most HDR is also UHD so that's the primary use case?

I was thinking of using Sol Levante for HDR, but it has some uniquely challenging to encode sequences I've not been able to make look good at 15 Mbps 1080p with the encoders I've tried. Good as a stress test, but not good as a representative example.

I'd love to see Tears of Steel at 4K with HDR, that would be cool. I've been trying to find one with 4K and 5.1 audio, but I can't find that. What's the best encode done so far?
Sol Levante is a good encoding test, are there any more lossless videos like that? Thats the first lossless file I've encoded and it looks excellent.

HD MOVIE SOURCE

21st September 2022, 17:01

benwaggoner

22nd September 2022, 00:50

I'd love to see Tears of Steel at 4K with HDR, that would be cool. I've been trying to find one with 4K and 5.1 audio, but I can't find that. What's the best encode done so far?
Sol Levante is a good encoding test, are there any more lossless videos like that? Thats the first lossless file I've encoded and it looks excellent.
Tears of Steel was only made as 4K SDR, alas. I looked into remastering it for HDR a few years back. It was theoretically possible, but would require regrading all the camera footage and a lot of tweaking and rerendering of the CGI stuff to incorporate HDR elements.

benwaggoner

22nd September 2022, 00:52

When you're only dealing with 1 Mbps, is there any way to get scene cuts to look cleaner without turning into artifacts? That's my biggest issue with a restricted bit-rate. Does anyone have any advice?
Can you share your command line?

There's a lot of tweaks in x265 that can be done.

Bigger gap between --keyint and --min-keyint
Reduce --ipratio
Increase --rc-lookahead (max is --keyint)
Use --open-gop
Play around with the 3.x scenecut features.

HD MOVIE SOURCE

24th September 2022, 05:24

Can you share your command line?

There's a lot of tweaks in x265 that can be done.

Bigger gap between --keyint and --min-keyint
Reduce --ipratio
Increase --rc-lookahead (max is --keyint)
Use --open-gop
Play around with the 3.x scenecut features.

Im using uhd-bd=1 and keyint of 24. The reason for that is I always want to see the restrictions of encoding with 4K discs. I completely understand it's not optimal for this challenge.

This is what I use for my normal encodes using a constant rate factor of 0 with maxrate and buffsize control. Using these settings when lowering the maxrate and buffsize to 1 is pretty tough. I don't mind that it looks bad, I just want to see if there's anything that would make scene cuts look better.

Slow speed.

uhd-bd=1:no-open-gop:total-frames=0:min-keyint=1:keyint=24:rc-lookahead=24:lookahead-slices=0:vbv-maxrate=98000:vbv-bufsize=99000:ref=5:subme=7:aq-mode=3:aq-strength=1.6:bframes=3:b-adapt=0:ipratio=1.00:pbratio=1.00:no-deblock:no-sao:no-strong-intra-smoothing:psy-rd=0.00:psy-rdoq=0.00:rdoq-level=0:no-cutree

I set vbv-maxrate=98000:vbv-bufsize=99000 to vbv-maxrate=1000:vbv-bufsize=1000

I really just did it to see what it would look like under 4K BD restrictions and the restricted bit-rates. I did notice though you use a buff size of around 4000, are we aloud to do that?

rwill

24th September 2022, 12:22

This is what I use for my normal encodes using a constant rate factor of 0 with maxrate and buffsize control. Using these settings when lowering the maxrate and buffsize to 1 is pretty tough. I don't mind that it looks bad, I just want to see if there's anything that would make scene cuts look better.
...
I did notice though you use a buff size of around 4000, are we aloud to do that?

Tears of Steel
1.0, 1.5, and 2.0 Mbps ABR
4 Mbps peak bitrate
12 Mbps VBV
Max 5 sec (120 frame) GOP
No preprocessing

What you are doing is more or less running constant rate (CBR) with 1 second buffer and 1 second keyint. No wonder everything looks like crap.

HD MOVIE SOURCE

25th September 2022, 18:07

What you are doing is more or less running constant rate (CBR) with 1 second buffer and 1 second keyint. No wonder everything looks like crap.

Ah, I see now, thanks for pointing that out. I will take a 2nd attempt and see. With that said, apart from keyint settings, are there any settings that can help with a scenecut even if I continue to use 1-second keyint?

rwill

25th September 2022, 18:32

Ah, I see now, thanks for pointing that out. I will take a 2nd attempt and see. With that said, apart from keyint settings, are there any settings that can help with a scenecut even if I continue to use 1-second keyint?

Well, the keyframes have to fit into the VBV buffer which is re-filled at maxrate. Their bits are taken from the global bit-budget. I don't know really. Higher VBV maxrate would help maybe to make space in the buffer but everything is gonna be bit-starved anyway.

HD MOVIE SOURCE

25th September 2022, 20:29

Well, the keyframes have to fit into the VBV buffer which is re-filled at maxrate. Their bits are taken from the global bit-budget. I don't know really. Higher VBV maxrate would help maybe to make space in the buffer but everything is gonna be bit-starved anyway.

Okay, interesting, I realized I don't really know how the maxrate and buffer really work. So basically if though you're targeting 1 Mbps, you can allow for higher maxrates so that when scene cutting, you have more bits right?

Just wondering though, let's say I set my maxrate to 4Mbps, and set the buffer to 100Mbps, what does that actually do? I'm just trying to picture the interaction.

rwill

25th September 2022, 20:45

https://forum.doom9.org/showthread.php?p=1953919#post1953919

Your "buckets" will be 100Mbit and will empty/fill with 4Mbit.

HD MOVIE SOURCE

26th September 2022, 04:16

https://forum.doom9.org/showthread.php?p=1953919#post1953919

Your "buckets" will be 100Mbit and will empty/fill with 4Mbit.

So the buffer would just be ahead of the maxrate by 100 Mbps? and the max rate will continuously take 4Mbps out of the buffer?

In that post you linked, some talked about underflow, what, and how I test for it? Somebody responded and said to check how it decodes or something. So, is there something I can do to test whether my maxrate and buffer settings work correctly?

I noticed that the buffer rate is 12 Mbps, and the maxrate is 4 Mbps, is this 3x difference typical? Would this help with scenecuts, but having more stored buffer?

Thanks.

rwill

26th September 2022, 05:50

https://en.wikipedia.org/wiki/Video_buffering_verifier

Have you read this and the respective links to CBR and VBR yet? It explains most basic bit allocation and the pros and cons.

excellentswordfight

26th September 2022, 12:18

I noticed that the buffer rate is 12 Mbps, and the maxrate is 4 Mbps, is this 3x difference typical? Would this help with scenecuts, but having more stored buffer?

Thanks.
I think its set to 12 in the original post cause that is max bitrate for level 4 main tier (i.e. most devices capable of decoding the stream should have a big enough buffer to handle the stream). The most common values i've seen is either set it based on the level or 1-2x maxrate.

Think about it this way, you use maxrate to specifiy the maximum read speed of your target decoder; so if you use 4Mbps a 5Mbps client connection will be able to stream that without issue (audio and headroom needs to be taken in account as well). This is one of reason why physical media (e.g. bluray) uses lower VBV limits than what the video standard allows for, cause the the relative slow read speeds of the optical discs. And by setting a higher buffsize than your maxrate you allow for sections with higher bitrate cause data has accumulated in the buffer, and the vbv modell ensures that as long as you can feed data to the decoder of the speed of the maxrate you wont underflow (i.e. the decoder runs out of data). This can be very beneficial for streaming were you need to set rather constrained maxrate vaules.

And btw, why are you using no-strong-intra-smoothing? It will only result in more blocking and banding, and especially at this bitrate it will not improve image quality at all. Even at high bitrates I havnt seen any positive effects of disabling this feature.

And also, I'm not sure why you are so fixated on the UHD-Bluray specifications, if you are not authoring for a physical disc, those requirements becomes rather irrelevant. Why even go to the lengths were you try to mix that with low-bandwith-streaming? There are no magic in those requirements, and most of the specifics are actually restrictions that will hurt quality.

benwaggoner

26th September 2022, 20:59

I think its set to 12 in the original post cause that is max bitrate for level 4 main tier (i.e. most devices capable of decoding the stream should have a big enough buffer to handle the stream). The most common values i've seen is either set it based on the level or 1-2x maxrate.
Yep, that's exactly where I got 12 Mbps. It was the most restrictive for the minimum compatible Profile @ Level (generally 4.0) for codecs relevant to the test.

And also, I'm not sure why you are so fixated on the UHD-Bluray specifications, if you are not authoring for a physical disc, those requirements becomes rather irrelevant. Why even go to the lengths were you try to mix that with low-bandwith-streaming? There are no magic in those requirements, and most of the specifics are actually restrictions that will hurt quality.
Yeah, I didn't have any optical disc scenario in mind when I came up with the test in the first place. That said, comparing best-effort to best-effort with optical disc constraints is an interesting way to demo the hit on compression efficiency due to Blu-ray requirements. I see a lot of AVSForum folks assuming that streaming has to be bad because Blu-ray bitrates go so much higher. But Bl8-ray NEEDS higher bitrates to get the same quality than streaming does. An IDR every 24 frames minimum is some serious overhead!

HD MOVIE SOURCE

12th October 2022, 05:48

Yeah, I'm honestly just seeing how certain restrictions like bit-rate, and even a uhd-bd=1 effect quality. I just like to test things and see if there's neat workarounds to improve quality even under certain restrictions.

Its my first time encoding at a lower-than-normal bit-rate, so I'm seeing what I can get away with and what I cannot. Changing the bufsize and maxrate has really helped, as I am trying this with CRF instead on 2-pass average bit-rate. Again, I'm seeing how the bit-rate constraints impact the CRF.

I see that intra-smoothing and deblock absolutely play a huge impact with bit-rates this low.

I gues the biggest thing here is keeping the bit-rate low, but having enough buffer than upon a scenecut, there's enough buffer to give that scenecut enough bits so artifacts are kept at bay. This is definitely something that Physical Media has issues with and can be improved with streaming because of the one second buffer on discs.
When it comes to encoding like this as though its for ststreaming, you mayas well use 250 or is it 260 keyint right to reduce the impact even on iframes right? I downloaded Ben's encodes and they look very good for having a 1 Mbps target bit-rate. I actually didn't think it was possible to get video this acceptable with bit-rates that low.

excellentswordfight

12th October 2022, 13:45

When it comes to encoding like this as though its for ststreaming, you mayas well use 250 or is it 260 keyint right to reduce the impact even on iframes right? I downloaded Ben's encodes and they look very good for having a 1 Mbps target bit-rate. I actually didn't think it was possible to get video this acceptable with bit-rates that low.
No, cause that will impact seeking and abr-switching. 2-4s interval is usually whats recommended for dash and hls streaming. The restrictions/scenario is very streaming-centered, as it imo should, as that is the biggest real life scenario for low-bitrate encoding. 5s (120=24*5) is already stretching this a bit, i've not seen a lot of GOP encodes going above 4s (or 120f). Broadcasters is usually in the 1-2s range (I also think thats what recommended by DVB partly cause its affect on channel switching). So in the real world it basically only for private use were large GOPs are used (like the common 10s GOP limit). Not sure though how its in the realm of extreme low bitrate cases like video-conference etc.

From what i've seen is that the compression gain starts to flat out after about 4s, but were going from 1s to 2s can make a rather noticeable impact.

benwaggoner

14th October 2022, 17:17

I gues the biggest thing here is keeping the bit-rate low, but having enough buffer than upon a scenecut, there's enough buffer to give that scenecut enough bits so artifacts are kept at bay. This is definitely something that Physical Media has issues with and can be improved with streaming because of the one second buffer on discs.
When it comes to encoding like this as though its for ststreaming, you mayas well use 250 or is it 260 keyint right to reduce the impact even on iframes right? I downloaded Ben's encodes and they look very good for having a 1 Mbps target bit-rate. I actually didn't think it was possible to get video this acceptable with bit-rates that low.
Yeah, my encodes are also a few years old. I could do them even better today. We get year-on-year improvements with existing codecs based on better code and better understanding of tuning. Then big step-change improvements with new codecs.

Today we can do a decent 1440p HDR with 2 Mbps ABR. When I started encoding, 2 Mbps got me a lousy looking 240x180 12 fps with 8-bit 11 KHz mono audio in QuickTime 1.0. Which wouldn't even play well off a (forthcoming) 1x CD-ROM. Like many Moore's Law dependent technologies, it's pretty amazing how what seemed like science fiction five years earlier is best practices today.

Higher keyint values are a tradeoff between random access speed (worse) and compression efficiency (potentially improved). I picked 96 for this test as a pretty common value, and less than some longer shots so we could see how the encoder handles a new GOP mid-shot, where visual discontinuities can happen.

To make sure there's enough VBV for IDRs, using 2-pass encoding or a lot of lookahead are key. For x265, setting --rc-lookahead = --keyint can reduce quality fluctuations significantly. Uses a lot of RAM, though! I was doing some 8K encoding a few days ago where a single x265 process was using about 40 GB.

benwaggoner

14th October 2022, 17:26

No, cause that will impact seeking and abr-switching. 2-4s interval is usually whats recommended for dash and hls streaming. The restrictions/scenario is very streaming-centered, as it imo should, as that is the biggest real life scenario for low-bitrate encoding. 5s (120=24*5) is already stretching this a bit, i've not seen a lot of GOP encodes going above 4s (or 120f). Broadcasters is usually in the 1-2s range (I also think thats what recommended by DVB partly cause its affect on channel switching). So in the real world it basically only for private use were large GOPs are used (like the common 10s GOP limit). Not sure though how its in the realm of extreme low bitrate cases like video-conference etc.
I've certainly seen 5 sec segments in DASH, and HLS originally recommended 10 sec per segment. It's a tradeoff between efficiency and ABR switching latency. Longer segments are easier to get away with in VOD since the client can download them faster than realtime. Live needs shorter segments as one can't download fragments (or sub-fragments) that haven't been encoded yet.

From what i've seen is that the compression gain starts to flat out after about 4s, but were going from 1s to 2s can make a rather noticeable impact.
Yeah, 3-5 has been a pretty safe bet for a couple of decades now. I've used up to 20 sec before for special cases, like simple animations that don't require random access. Some years back I was able to get some of the Kindle Fire preloaded intro videos down to 100 Kbps 1080p24 HEVC with that and other content-specific tuning.

excellentswordfight

15th October 2022, 19:16

I've certainly seen 5 sec segments in DASH, and HLS originally recommended 10 sec per segment. It's a tradeoff between efficiency and ABR switching latency. Longer segments are easier to get away with in VOD since the client can download them faster than realtime. Live needs shorter segments as one can't download fragments (or sub-fragments) that haven't been encoded yet..
Oh, I dont doubt that its used! And as someone that comes from a broadcast-background and are mostly involved with live encoders 4s is already rather high for me :) And most VOD content i've come across has used 2 or 4s, but vod-streaming as an interest is relatively new to me.

But gop length and segment size are different things, no? Gop size doesnt have to be the same as the segment length as long as the IDR-placements fits the segments or have i missed something? Current Apple HLS recommendation is 2s for the gop size and 6s for the segment afaik.

benwaggoner

16th October 2022, 21:58

Oh, I dont doubt that its used! And as someone that comes from a broadcast-background and are mostly involved with live encoders 4s is already rather high for me :) And most VOD content i've come across has used 2 or 4s, but vod-streaming as an interest is relatively new to me.

But gop length and segment size are different things, no? Gop size doesnt have to be the same as the segment length as long as the IDR-placements fits the segments or have i missed something? Current Apple HLS recommendation is 2s for the gop size and 6s for the segment afaik.
Correct, one can have multiple GOPs in a single segment. HLS famously recommended 3 second GOPs in 10 sec segments, for example. But, but 3*3<>10 I said! Never really found out the "why" of that

That said, most adaptive streaming targets H.264 or HEVC, which support non-IDR I-frames. Those are fully intra coded frames, but don't preclude a frame after it referencing a frame before it. There's no practical downside to using those inside a GOP, and some minor upsides, so generally things are encoded with an IDR at the start of every fragment, and a non-IDR I-frame for any natural keyframes inside that segment.

An advantage of this approach is that a packager doesn't have to figure out which IDRs are at segment boundaries and which ones aren't. A non-IDR I doesn't have to carry the once-per-GOP metadata. And if the I-frame is just a single flash frame like a strobe light, the frames after can reference the frames before, which can save a whole lot of bits (it's the same reason that VC-1 had intra-only B-frames (BI frames) to substitute a flash frame that would otherwise be coded as a P-frame).

HD MOVIE SOURCE

21st October 2022, 10:56

Yeah, my encodes are also a few years old. I could do them even better today. We get year-on-year improvements with existing codecs based on better code and better understanding of tuning. Then big step-change improvements with new codecs.

Today we can do a decent 1440p HDR with 2 Mbps ABR. When I started encoding, 2 Mbps got me a lousy looking 240x180 12 fps with 8-bit 11 KHz mono audio in QuickTime 1.0. Which wouldn't even play well off a (forthcoming) 1x CD-ROM. Like many Moore's Law dependent technologies, it's pretty amazing how what seemed like science fiction five years earlier is best practices today.

Higher keyint values are a tradeoff between random access speed (worse) and compression efficiency (potentially improved). I picked 96 for this test as a pretty common value, and less than some longer shots so we could see how the encoder handles a new GOP mid-shot, where visual discontinuities can happen.

To make sure there's enough VBV for IDRs, using 2-pass encoding or a lot of lookahead are key. For x265, setting --rc-lookahead = --keyint can reduce quality fluctuations significantly. Uses a lot of RAM, though! I was doing some 8K encoding a few days ago where a single x265 process was using about 40 GB.

Yeah, I encoded Big Buck Bunny at 60 frames per second and it used a lot more RAM. I've had a few encodes just stop because of it so I upgraded my RAM and I've never had any issues with that anymore.

So, I encoded Tears of Steel with your advice, on buffer and maxrate and it came out to a hair over your bit-rate on your file so I was happy. It looked much better. But, I kept the restrictions as though it was a 4K Blu-ray, just for science. I might upload it into my Google drive if you want to take a look.

Just wondering, do Blender even post fully uncompressed open movies, that haven't already been encoded? I'm currently encoding all of their open movies, but most are MP4s, and tears of steel got a DCP which was really nice. I re-scale mine, because 4K Blu-ray doesn't use the max 4K it uses 3840x2160p, so it downscales, and then you add borders get the pixels back to 2160p. I notice that a lot, even on their other open movies, they use strange resolutions most of the time. If they're not originally 4K I upscale them, which I've found doesn't look as poor as I originally thought upscaling would look. I've seen some poor upscales on 4K Blu-ray and just always assumed it must be because they upscaled from 2K, but I've found it to be quite good.

I noticed on the spears on munsil Blu-ray, it had Big Buck Bunny at 30 frames per second and the version was different it had the opening logo when looking at the tree at the start. The 4K version I use doesn't show the title at the tree scene of Big Buck Bunny. And, the 4K version, the original file has banding in a few scenes, whereas the spears and munsil Blu-ray version did not have that. So I looked around and could not find that version. So, I wonder if they got a special version? I contacted Blender and asked if they had listings for all their movies un-encoded, completely uncompressed, but weren't really that helpful. I subbed to their website to get access to a few more open movies, and support their work. I watched my encoded version and against the original file, and both had the banding in the same spot. It's hard to see if you're not like me (I'm crazy lol), but it's there.

I like what Netflix has done with SolLevante, its completely uncompressed, that turned out absolutely perfect with HDR too. I wanted to put dolby atmos audio on the encode too, but they provided a completely uncompressed atmos track that needed to be encoded. I couldn't believe how big just the audio file was. Its like 110Mbps LOL, just for audio. So, I had to use the 5.1 track, which I converted to AC3 at 640kbps. I think I'd need a special Dolby encoder to encode the audio, which is way out of my league.

I encoded sprite fright and that came out really well. As long as the source is clean even though they've encoded it, it will come out good, but I wish they did a prores or MOV files just so I could sleep better at night LOL.

So, your encodes used the DCP for tears of steel right? Thats the one I used, then I muxed the 5.1 audio to it, turned out really nice in the end. I don't like the grain structure they used though. It's blurry, and inconsistent. I checked the source file and it's imperfect on the source too. You can see this on the credits, the grain that they're using isn't a fine grain, its almost noisy.

Just realized Ive been talking a bit too long now, LOL Thanks for listening.

benwaggoner

22nd October 2022, 23:54

excellentswordfight

24th October 2022, 19:20

Blender seems to be paywalling the sources for their newer titles for subscribers. Even for the older ones, there have been a variety of different versions, some added years after the original.

IIRC, my ToS came from a 4K high bit TIFF image sequence. Also, the 60 fps Big Buck Bunny came out some time after the original 24p render. BBB is a fun clip, but it is also pretty absurdly easy to encode, so I don't like to use it for encoding tests.

Now that StEM2 is out with free source downloads, I imagine that's going to be the most popular encoder test clips for years to come. They did a great job of including all sorts of elements that can stress all sorts of compression, image processing, and display processes. It's available in full 2020 PQ HDR, 709, up to 8K, etc. https://theasc.com/asc/stem2.

It's absolutely what I'd use for an updated version of this test today.
Wow, that looks amazing! Thanks for sharing the link. Very nice to have both HDR & SDR masters as well.

Before I start downloading do you know the specs of the IMF packages? "lossy HDR App 2E" is twice the size of "lossy SDR App 2E", is the SDR 1080p and hdr 2160p? I think I´m going to create a 1080p h264 bluray compatible SDR-version and one 2160p h265 uhd-bluray compatible HDR10-version if I need something leaner and to use as bluray-reencode simulations and tuning, and Im thinking what versions would be best to use as sources.

benwaggoner

24th October 2022, 21:09

Wow, that looks amazing! Thanks for sharing the link. Very nice to have both HDR & SDR masters as well.

Before I start downloading do you know the specs of the IMF packages? "lossy HDR App 2E" is twice the size of "lossy SDR App 2E", is the SDR 1080p and hdr 2160p? I think I´m going to create a 1080p h264 bluray compatible SDR-version and one 2160p h265 uhd-bluray compatible HDR10-version if I need something leaner and to use as bluray-reencode simulations and tuning, and Im thinking what versions would be best to use as sources.
I've not looked at the DCP packages yet. I've just started playing with the DNxHD QuickTime.

Note that SDR is available in two different aspect ratios.

HD MOVIE SOURCE

9th November 2022, 07:52

Blender seems to be paywalling the sources for their newer titles for subscribers. Even for the older ones, there have been a variety of different versions, some added years after the original.

IIRC, my ToS came from a 4K high bit TIFF image sequence. Also, the 60 fps Big Buck Bunny came out some time after the original 24p render. BBB is a fun clip, but it is also pretty absurdly easy to encode, so I don't like to use it for encoding tests.

Now that StEM2 is out with free source downloads, I imagine that's going to be the most popular encoder test clips for years to come. They did a great job of including all sorts of elements that can stress all sorts of compression, image processing, and display processes. It's available in full 2020 PQ HDR, 709, up to 8K, etc. https://theasc.com/asc/stem2.

It's absolutely what I'd use for an updated version of this test today.

I'll check that out thank you. Are there any 4K UHD prores The Rings of Power trailers? I'd like to see how close to the stream quality I can get. Trailers are generally quite busy so more bit-rates are needed for high scene-cut segments. I think it would be a good test also.

HD MOVIE SOURCE

15th November 2022, 05:37

Blender seems to be paywalling the sources for their newer titles for subscribers. Even for the older ones, there have been a variety of different versions, some added years after the original.

IIRC, my ToS came from a 4K high bit TIFF image sequence. Also, the 60 fps Big Buck Bunny came out some time after the original 24p render. BBB is a fun clip, but it is also pretty absurdly easy to encode, so I don't like to use it for encoding tests.

Now that StEM2 is out with free source downloads, I imagine that's going to be the most popular encoder test clips for years to come. They did a great job of including all sorts of elements that can stress all sorts of compression, image processing, and display processes. It's available in full 2020 PQ HDR, 709, up to 8K, etc. https://theasc.com/asc/stem2.

It's absolutely what I'd use for an updated version of this test today.

I've encoded the 4K version of StEM2 twice now and at 5 mins and 08 seconds, there seems to be some digital artifact. It is a line that goes across the top portion of the screen for half a second and disappears. I've encoded it twice and its in the same place. I think it could be an artifact with the file itself. I think what I'll do is download the 4K DCP file and see if that file has corrected the error.

I downloaded the 126GB file.

Do they have a contact? Ill see if I can shoot them an email about it.

excellentswordfight

15th November 2022, 09:14

I've encoded the 4K version of StEM2 twice now and at 5 mins and 08 seconds, there seems to be some digital artifact. It is a line that goes across the top portion of the screen for half a second and disappears. I've encoded it twice and its in the same place. I think it could be an artifact with the file itself. I think what I'll do is download the 4K DCP file and see if that file has corrected the error.

I downloaded the 126GB file.

Do they have a contact? Ill see if I can shoot them an email about it.
I noticed it as well, its present in all versions, It doesnt look like an re-encoding issue tbh, more like a glitch during capture. But its strange that it wasnt noticed and fixed in post...

benwaggoner

16th November 2022, 01:05

I'll check that out thank you. Are there any 4K UHD prores The Rings of Power trailers? I'd like to see how close to the stream quality I can get.
Certainly none that are available to the public!

Trailers are generally quite busy so more bit-rates are needed for high scene-cut segments. I think it would be a good test also.
Also for the newly updated --hist-scenecut algorithm.

HD MOVIE SOURCE

21st November 2022, 06:33

Certainly none that are available to the public!

Also for the newly updated --hist-scenecut algorithm.

Interesting, so what has changed for --hist-scenecut algorithm? Scenecuts are something I honestly haven't played around with, is there anything that could help with keyint=24 BD content? Making scenecuts hold higher bit-rates or anything like that?

HD MOVIE SOURCE

21st November 2022, 06:36

I noticed it as well, its present in all versions, It doesnt look like an re-encoding issue tbh, more like a glitch during capture. But its strange that it wasnt noticed and fixed in post...

Very strange, we noticed it on first viewing, was really easy to spot. If it was a capture issue, couldn't they have blurred or managed it somehow is post?

I've checked multiple versions and they all contain the glitch.

Forteen88

20th December 2022, 18:44

Today I did a new encode with SolLevante_SDRv2_1080p24_8bit.y4m as video-source.
My encode filename is SolLevante_SDRv2_1080p24_8bit_out(MC-HEVC10,24fps,Aspect16-9,ColorRange-Full,2pass,PQ30,target1000,max4000,AdaptiveBFramePlacement).mp4
Using MainConcept TotalCode Studio 5.30 (which uses MainConcept H.265/HEVC video encoder Version: 12.2.0.3600)
MC-HEVC10 Main 10(Main 10)@4.1 (standard settings except I enabled "Adaptive B-Frame Placement"). 24fps, Aspect16:9, ColorRange-Full, 2pass, PQ30 (which is maximum quality but longest encode-time). Only the default 7 B-Frames.
Target Bitrate: 1000kbps
Max bitrate: 4000kbps
Size: 31.45 MB
https://www.sendspace.com/file/na8jbn

I see lots of blockings, like in BenWaggoner's x265-encode.
EDIT: Oh, I also see now that I should've used 8bit, not 10bit in this challenge, but I think that more people here are interested in 10bit-encodes.
BenWaggoner wrote: "This specific test is 8-bit specific, mainly because comparing 8-bit encodes is less fraught.
But a 10-bit HDR test would be an obvious next step. Perhaps with Sol Levante."
Also, shouldn't have set color range to FULL (which was the default in TotalCode Studio), I should have set it to "Clamped" (aka "Limited"). MSU Video Quality Measurement Tool doesn't allow different color range videos to be compared.

Forteen88

22nd December 2022, 19:57

Sol Levante's 4K HDR source is available under Creative Commons, from which I derived an 8-bit SDR 1080p .y4m (https://1drv.ms/u/s!AlvIQZWsyeO-k9llZI15s0x3uwd_nQ?e=PlqcNz), as 8-bit SDR playback and testing is still a lot more available.

I've kicked off a 1000 Kbps test encode with x265 for reference that I should post tomorrow.How come the Sol Levante's 4K HDR source is 4:23 minutes long but that x265-encode of it is only 4:01 minutes long?

DTL

9th February 2023, 12:04

With all the talk about VP9 and AV1 and VVC and different encoder implementations for all of them, I thought it might be fun to set up an open challenge for folks to deliver the best possible quality for each.

To that end, in a semi-inebriated late-night conversation at IBC, we defined a scenario relevant to some important real-world scenarios that reasonably stress current encoders.

No preprocessing

As for the 'real-world' moving pictures content physically damaged by 'real physics' photon shot noise it is no good to limit 'preprocessing'. And it significantly limit 'compressability' of moving pictures content.

As we see with AV1 encoder it may internally apply 'very slight' denoise of about 3..5 averaging frames and 'massive beat' HEVC in compression tests to xx% .

But if allow to make preprocessing - the total challenge is turned in comparison of quality of denoiser+MPEG pair.

As I see modern video cameras to get 'real world' images have good progress of 'internal denoisers' so the world of broadcasting really moves to this direction. When you buy new set of video cameras with lower noise to your studio with less noise you also got great benefit to the quality of the compressed by MPEG encoders content for broadcasting. But it may be also simulated by (much cheaper) denoise hardware unit before your master MPEG coder. Or even software of zero price if you make software file-based processing and use software MPEG encoder.

Also internally both temporal denoiser and MPEG encoder based on the same ideas of motion tracking (block or object based) so may use same hardware to make motion estimation (and may be MPEG encoder may reuse motion estimation from denoiser). May be it is already implemented in modern codecs after HEVC - like in AV1.

So the 'preprocessing' between real world and MPEG coder is really essential part of total moving pictures compression process. To remove 'real world' random data and to clean really required visual information about scene from random noise of intermediate scene-view transfer media of photons flux.
The inter-frame 'denoiser' simply simulate video camera with more accumulating time per each scene object in compare with 'primary scene frame-based' camera. Primary camera (if not using internal interframe digital denoise) is limited to inter-frame time interval to accumulate photons. Also can not perform individual scene objects trackng.

The 'motion compensated denoiser' can extend accumilating time to about total visibility time of the object in the cut-scene and perform individual tracking if each scene object is not static relative to the primary video camera. So it simulates massive array (equal to the blocks number in blocks-based denoiser) of 'secondary video cameras' with individual tracking and much more extending data accumulating time without motion blur.

And after this 2-stages physical + simulated secondary video cameras scene data transform you got more clean scene data to MPEG encoder and pass it to simple enough MPEG encoder and got better output quality because MPEG can now spent more bits to the real scene objects encoding and not to residual noise encoding after non-complete motion compensation of nosied blocks.

benwaggoner

10th February 2023, 22:59

Interesting, so what has changed for --hist-scenecut algorithm? Scenecuts are something I honestly haven't played around with, is there anything that could help with keyint=24 BD content? Making scenecuts hold higher bit-rates or anything like that?
--hist-scenecut is supposed to do better scene cut decisions, so it would help in that regard. I've not heard much positive feedback that it does so, particularly in pre-3.5 implementations.

--scenecut-aware-qp would be of more specific interest, as it will save some bits around natural scene cuts where the big temporal discontinuity will mask small ones for a few frames. I've not experimented with it much myself, but the idea is certainly sound.

Boulder

11th February 2023, 10:15

--hist-scenecut definitely works better than the classic mode in 8-bit encodes and 10-bit HDR encodes which are not black and white.

benwaggoner

12th February 2023, 04:25

As I see modern video cameras to get 'real world' images have good progress of 'internal denoisers' so the world of broadcasting really moves to this direction. When you buy new set of video cameras with lower noise to your studio with less noise you also got great benefit to the quality of the compressed by MPEG encoders content for broadcasting. But it may be also simulated by (much cheaper) denoise hardware unit before your master MPEG coder. Or even software of zero price if you make software file-based processing and use software MPEG encoder.

Also internally both temporal denoiser and MPEG encoder based on the same ideas of motion tracking (block or object based) so may use same hardware to make motion estimation (and may be MPEG encoder may reuse motion estimation from denoiser). May be it is already implemented in modern codecs after HEVC - like in AV1.

So the 'preprocessing' between real world and MPEG coder is really essential part of total moving pictures compression process. To remove 'real world' random data and to clean really required visual information about scene from random noise of intermediate scene-view transfer media of photons flux.
The inter-frame 'denoiser' simply simulate video camera with more accumulating time per each scene object in compare with 'primary scene frame-based' camera. Primary camera (if not using internal interframe digital denoise) is limited to inter-frame time interval to accumulate photons. Also can not perform individual scene objects trackng.

The 'motion compensated denoiser' can extend accumilating time to about total visibility time of the object in the cut-scene and perform individual tracking if each scene object is not static relative to the primary video camera. So it simulates massive array (equal to the blocks number in blocks-based denoiser) of 'secondary video cameras' with individual tracking and much more extending data accumulating time without motion blur.

And after this 2-stages physical + simulated secondary video cameras scene data transform you got more clean scene data to MPEG encoder and pass it to simple enough MPEG encoder and got better output quality because MPEG can now spent more bits to the real scene objects encoding and not to residual noise encoding after non-complete motion compensation of nosied blocks.
Yeah, the line between encoding and preprocessing was never all that clear, and certainly has been becoming less so as codecs and encoders advance.

Still allowing unfettered preprocessing seems risky, as techniques like adding contrast like encoders were using to goose VMAF scores is a risk.

The spirit of the test is "what can deliver output most like the source" - which has unavoidable subjective elements.

I'm open to suggestions on how best to address this in an updated version of the challenge.

I'm thinking using StEM2 10-bit, with separate 1080p SDR and 2160p HDR targets. Thoughts?

DTL

23rd February 2023, 11:51

I'm open to suggestions on how best to address this in an updated version of the challenge.

The idea is to take noise-free source and to test encoder after adding some 'natural' noise and compare with 'clean' source.

As natural photon-shot noise is Poisson distribution at very low photons count and close to Gauss at medium and high we can more or less acceptably simulate it with AddGrain AVS plugin (promised to have gauss-noise).

For noise-free source we can take either 100% syntetic render (not very realistic natural source) or try to take as clean as possible natural camera shots.
As additional noise-cleaning steps the downsize may be used. 8x downsize adds about +18 dB to SNR (from photon-shot noise) and for 8bit and may be 10bit is it close to quantization noise only with good enough daylight camera shots with 0dB gain or even some -dB gain.

And to arrange some not very small frame for testing the tiling of downsized parts of total clip may be used. It also create 'average' complexity framestream of the total clip (that typically contain different complexity cutscenes) of short enough length to encode.

So with current 3.7.3 test 6 AVS+ release from https://forum.doom9.org/showthread.php?p=1983250#post1983250
was created source cleaning and conditioning script:

LoadPlugin("ffms2.dll")
LoadPlugin("avsresize.dll")
LoadPlugin("AddGrainC.dll")

FFmpegSource2("04.ts")

ConvertBits(16)

LetterBox(8, 8, 8, 8)

fc=last.FrameCount
fco=fc/16

drw=last.width / 8
drh=last.height / 8

c00=Trim(0 * fco, fco)
c01=Trim(1 * fco, 1 * fco + fco)
c02=Trim(2 * fco, 2 * fco + fco)
c03=Trim(3 * fco, 3 * fco + fco)

c10=Trim(4 * fco, 4 * fco + fco)
c11=Trim(5 * fco, 5 * fco + fco)
c12=Trim(6 * fco, 6 * fco + fco)
c13=Trim(7 * fco, 7 * fco + fco)

c20=Trim(8 * fco, 8 * fco + fco)
c21=Trim(9 * fco, 9 * fco + fco)
c22=Trim(10 * fco, 10 * fco + fco)
c23=Trim(11 * fco, 11 * fco + fco)

c30=Trim(12 * fco, 12 * fco + fco)
c31=Trim(13 * fco, 13 * fco + fco)
c32=Trim(14 * fco, 14 * fco + fco)
c33=Trim(15 * fco, 15 * fco + fco)

bp=105 // average sharpness
cp=0

c00=UserDefined2Resize(c00, drw, drh, b=bp, c=cp)
c01=UserDefined2Resize(c01, drw, drh, b=bp, c=cp)
c02=UserDefined2Resize(c02, drw, drh, b=bp, c=cp)
c03=UserDefined2Resize(c03, drw, drh, b=bp, c=cp)

c10=UserDefined2Resize(c10, drw, drh, b=bp, c=cp)
c11=UserDefined2Resize(c11, drw, drh, b=bp, c=cp)
c12=UserDefined2Resize(c12, drw, drh, b=bp, c=cp)
c13=UserDefined2Resize(c13, drw, drh, b=bp, c=cp)

c20=UserDefined2Resize(c20, drw, drh, b=bp, c=cp)
c21=UserDefined2Resize(c21, drw, drh, b=bp, c=cp)
c22=UserDefined2Resize(c22, drw, drh, b=bp, c=cp)
c23=UserDefined2Resize(c23, drw, drh, b=bp, c=cp)

c30=UserDefined2Resize(c30, drw, drh, b=bp, c=cp)
c31=UserDefined2Resize(c31, drw, drh, b=bp, c=cp)
c32=UserDefined2Resize(c32, drw, drh, b=bp, c=cp)
c33=UserDefined2Resize(c33, drw, drh, b=bp, c=cp)

r0=StackHorizontal(c00, c01, c02, c03)
r1=StackHorizontal(c10, c11, c12, c13)
r2=StackHorizontal(c20, c21, c22, c23)
r3=StackHorizontal(c30, c31, c32, c33)

StackVertical(r0, r1, r2, r3)

ConvertBits(8) // use target bitdepth conversion

#AddGrain(10)

Trim(0, 5000)

Prefetch(2)

For creating low-noise testclip from 4K footage with 1920x1080 output frame size. The b/c params for downsampler were taken for not very best 'video-makeup' sharpness to not make transients to black between 'picture in picture' elements too overshooting. The LetterBox in AVS still have issues with transients creation (https://github.com/AviSynth/AviSynthPlus/issues/339). Execution of script is slow enough so it is better save to lossless compressed 16bit per sample file (like FFV1 ver 3 from ffmpeg, yuv420p16le) and use it for testing MPEG encoders (after dithering or not to target bitdepth 8/10 or more).

The test footage was 4K UHD SDR 'A Wild Year on Earth', UK, Northern Pictures, 2020 https://www.imdb.com/title/tt13715870/, episode 04 https://www.imdb.com/title/tt13716068/?ref_=ttep_ep4 .

For faster speed (and x265 10bit again not started via avspipemod at me) MPEG encoder was 8bit x264 with settings:

--profile high --crf 18 --ref 4 -b 12 --direct auto --me esa --subme 11 --no-fast-pskip --trellis 2
--merange 24 --deblock -2:-2 --b-adapt 2 --transfer "bt709" --colorprim "bt709" --colormatrix "bt709" --psnr

Results for different AddGrain(N) settings are:
No grain: 10640K, PSNR Y Mean 43.4 dB, encoding performance about 5 fps
AddGrain(2): 12347K, PSNR Y Mean 40.7 dB, encoding performance 4.34 fps
AddGrain(5): 17807K, PSNR Y Mean 38.7 dB, encoding performance 3.43 fps
AddGrain(10): 33969K, PSNR Y Mean 36.7 dB, encoding performance 2.85 fps
AddGrain(20): 69177K, PSNR Y Mean 35.4 dB, encoding performance 2.42 fps

So the residual noise in the content to MPEG encode significantly change MPEG output bitrate with fixed CRF-type encoding (and even with higher bitrate the PSNR still lower).

In a 'perfect world' MPEG encoder with perfect noise reduction internal should output stable lowest possible bitrate at highest PSNR because the real clean content is not changed and only additive random nosie is added with zero mean (I hope). Also the quality metric (PSNR/SSIM/VIF/VMAF/..) of the MPEG encoding result must be compared with 'clean source' before noise addition.

damian101

28th February 2023, 12:58

What does peak bitrate refer to exactly, and what is VBV in regards to VP9/AV1?

damian101

3rd March 2023, 11:49

SolLevante in under 2 Mbit/s: https://mega.nz/file/9LYXgY4b#xF1PHse3hW4uQxecGwu4rTZ6dkmU4398ShdgwtLqS2o
I did not limit peak bitrate in any way, but followed the other constraints of the challenge.

damian101

3rd March 2023, 12:06

Tears of Steel in under 1 Mbit/s (slightly above with container overhead): https://mega.nz/file/RLhSmZzb#QU0wLBz-gUqjr0JpnB4dLy0Tu4BC75zU1B2pp5QusFs
I again did not concern myself with peak bitrate here.

damian101

3rd March 2023, 15:05

And here's 2 Mbit/s Tears of Steel: https://mega.nz/file/RTwknTrZ#7AamrIj0Vn9nsMb0yHv1yY4fTuQyJfKQ_2B0WwJbWOk

benwaggoner

6th March 2023, 01:51

What does peak bitrate refer to exactly, and what is VBV in regards to VP9/AV1?
I don't know the libvpx/libav1 syntax for peak bitrate control, but it should use whatever yield the same results as the specified --vbv-bufsize and --vbv-maxrate values

damian101

16th March 2023, 19:42

After further optimization, I encoded again, and this time with bitrate constrained to 4000 kbit/s (it sometimes overshoots, but so does x265, should be quite comparable).

2 Mbit/s Tears of Steel:
https://mega.nz/file/1WJkVB4B#QpNxZsEAlXfKzYHOxdkmYKvAGIfGSecFA_Pbn0M3dyw

1 Mbit/s Tears of Steel:
https://mega.nz/file/8fYlFIIL#V7EmKPpK9VfXBRN0M5BLjq33itUzR466CYbLNohyk0I

2 Mbit/s SolLevante:
https://mega.nz/file/0GhAVJZR#5BQ9YU1aarBilmALkwH7NkDKW1tQaXbVIeS1HvwLq7E

1 Mbit/s SolLevante:
https://mega.nz/file/UWwDCBAZ#3edv_dteag28_nwnsJR-L-IVsnLL7J6I2vZrDEzXgFo

At least the 1Mbit/s SolLevante could have been better if I had adapted my parameters, but I wanted to keep parameters identical for all the samples, quality control aside of course, and I generally don't care much about extremely low quality targets. As a result, all the samples don't use some features like Wiener filter and CDEF, because I don't like how they tend to remove too much detail because they're guided by crappy MSE.

benwaggoner

17th March 2023, 01:54

Sol Levante is a pretty uniquely weird and challenging source. It does great in demonstrating how well an encoder gracefully degrades when it's not possible to do a good job. And is a severe test of 2-pass VBR as it is half really easy to encode credits.

rwill

10th March 2024, 10:11

benwaggoner

12th March 2024, 01:39

Oh well how time flies...

I did 1Mbit HEVC and VVC encodes of Tears of Steel and Sol Levante using my stuff..

https://drive.google.com/drive/folders/1_y9yduWjj89VkPfIxC9FmggDIV78HJc3?usp=sharing

Where I tried to make VVC look like HEVC.

I noticed that adding more of the advanced tools to VVC gives the picture some sort of 'plastic', 'female instagram model' or 'make up' look which I did not like at all.

So anyway, after years of ToS and Sol in SDR maybe some new sequence is in order... Ben?
StEM2 is some great footage that's pretty typical for modern 24p stuff without much grain:

https://theasc.com/society/stem2

Great licensing terms and available in a bunch of formats. And recent enough that encoders haven't been overturned to death over it. Not great if you want to show off film grain synthesis, but great to show off how the encoding underneath that hood would work.

Thoughts?

rwill

12th March 2024, 18:21

So I got myself ASC_StEM2_178_UHD_ST2084_1000nits_Rec2020_Stereo_ProRes4444XQ.mov and converted it to yuv420p10le with ffmpeg like so:

../ffmpeg.exe -i <file> -pix_fmt yuv420p10le -acodec none -vcodec rawvideo -f rawvideo - | encoder...

and decided to do a HEVC Main10 HDR10 encode.

I tried to figure out a bitrate. Given the 1Mbit average target from ToS I figured going from 1920x800 to 3840x2160 .. that 4Mbit average would be somewhat reasonable and did an encode with a 120 pictures GOP, 12.5Mbit maxrate and 25Mbit buffer which more or less targets Level 5. I did not see any severe quality problems in the encode.

So I dropped the average rate to 2Mbit and started to see slight decreases in quality in flat areas.

If someone is interested, the encodes are at the following link:
https://drive.google.com/drive/folders/1G_dP4YOLvUjKVNM3TnHuHqeCifbAWKM9?usp=sharing

So while from a content perspective it may be challenging with the saturated colors and contrast, for a modern encoder it is not so much and it might be needed to decrease rate further to show encoder differences.

One thing I noticed is that filmgrain content can still trip off less tuned encoders with disastrous effects but such content may be hard to get to the public for testing...

benwaggoner

13th March 2024, 17:31

Yeah, that's the thing about test content - you've got to pick what you want to test.

So, what kind of content are people interested in testing? We could potentially assemble a sequence of different kinds of content.

KarthikTdk

23rd May 2024, 10:36

Hi all, any have c language code for h265(HEVC)

rwill

12th August 2024, 19:16

Regarding Content ..

By lurking Reddit I stumbled upon the Google Search term "archive.org prores trailer". It appears some people have been ripping Digital Cinema Trailers to Prores and uploaded them to Archive.org.

Now I have no clue about the movies the trailers are about and there is no license attached so its kind of problematic .. but from the samples I pulled it looked like OK'ish recent movie content.

Sagittaire

31st October 2024, 02:00

Someone test H266 for this challenge?

benwaggoner

7th November 2024, 01:06

Someone test H266 for this challenge?
I'd welcome a contribution! VVCEnc seems to be the closest to a x26? sort of tool, but it's still not as refined as x265 was in 2015.

Sagittaire

7th November 2024, 21:26

I'd welcome a contribution! VVCEnc seems to be the closest to a x26? sort of tool, but it's still not as refined as x265 was in 2015.

Bad multithreading optimisation for VVCEnc but I have solution for that ... ;-)

Z2697

7th November 2024, 21:53

IIRC VVde/enC are optimized version of VTM? Or one of them is.

rwill

29th January 2025, 05:55

Someone test H266 for this challenge?

Is this size easier to read? (https://forum.doom9.org/showthread.php?p=1998891#post1998891)

benwaggoner

29th January 2025, 21:14

Is this size easier to read? (https://forum.doom9.org/showthread.php?p=1998891#post1998891)
Yeah. I've hoped someone else would, but I may get curious enough to do it myself one of these days.

x265 and Beamr have also gotten better since the most recent HEVC submissions, so fresh ones of those would make sense.

Z2697

30th January 2025, 18:38

Yeah. I've hoped someone else would, but I may get curious enough to do it myself one of these days.

x265 and Beamr have also gotten better since the most recent HEVC submissions, so fresh ones of those would make sense.

I think the "core functions" of x265 hasn't been updated for years, there will be no difference if the parameters are identical.

benwaggoner

3rd February 2025, 18:38

I think the "core functions" of x265 hasn't been updated for years, there will be no difference if the parameters are identical.
There have been a decent number of minor bug fixes that can slightly improve quality since, say, five years ago. The bigger differences will be from us having learned more about how to tune x265, and having new parameters to use. That said, a lot of newer stuff is about improving quality @ perf, not improving quality at ultra placebo settings.

This test is, sheesh 6.5 years old now. 8-bit HD SDR really isn't the cutting edge anymore!

We should do a new challenge using StEM 2 as source (https://dpel.aswf.io/asc-stem2/).

For the modern era, what? Just throwing the below as a starting point for discussion:

StEM v2 "Quicktime with stereo, 1.78 @ UHD, 1000 nits ProRes4444XQ, Rec2020"
(should we make a shorter edited version for faster encoding and easier testing? The full thing is 23 minutes long)
5 Mbps ABR, 10 Mbps peak (challenging enough)
24.00 fps
384x2160p
Frame resizing techniques allowed
Film grain synthesis allowed? A with-FGS and without-FGS version?
10-bit HDR PQ Rec. 2020 primaries limited range
2-5 second variable GOP duration (fixed 2 seconds is more challenging, but increasingly less mainstream)
Closed GOP for adaptive streaming (techniques like RADL allowed as long as each fragment is independently decodable)
Objective metrics don't matter, subjective evaluation only.

How's that look? Any questions or suggested modifications? This represents all of 5 minutes of my consideration, so I hope there are!

tormento

3rd February 2025, 19:32

Film grain synthesis allowed? A with-FGS and without-FGS version?
I haven't yet understood if FGS is really a thing or not in x265 and, actually, I don't know of players that can recreate it when reproducing HEVC video.

Does it work as in AV1, where is removed and when played reconstructed or in some other way?

Can you give us some examples of how to create a proper FGS video with x265?

Z2697

5th February 2025, 08:03

126 GiB, that's a challenge by itself :p

Z2697

5th February 2025, 10:02

Eh, I downloaded it and it's 17:26 long, did I downloaded the wrong one?

The pixel format is YUV444P12, shall we specify the method of subsampling and dithering? Or even encode as is?

excellentswordfight

5th February 2025, 10:35

126 GiB, that's a challenge by itself :p
Eh, I downloaded it and it's 17:26 long, did I downloaded the wrong one?

The pixel format is YUV444P12, shall we specify the method of subsampling and dithering? Or even encode as is?
Sounds like you downloaded the IMF-version (J2K compression). And yes that is the length of it.

I think StEM2 is a pretty neat source, its very representive of "modern content", i.e. HDR UHD shot digitally with a rather clean image, I also like that there are both SDR and HDR version available which can make for some nice comparisons. My only complaint would be that the credits are a fairly big portion of the title.

I have been using the IMF versions with this commandline:

"ffmpeg.exe" -probesize 1000MB -ss 00:00:08 -i "hdr\StEM2_HDR_Rec2020PQ_444F_IMF_2160p24_178.mxf" -vf scale=out_color_matrix=bt2020ncut_h_chr_pos=0ut_v_chr_pos=0 -pix_fmt yuv420p10le -an -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m ...

And using the SDR version for 1080p tests:

"ffmpeg.exe" -probesize 1000MB -ss 00:00:08 -i "sdr\StEM2_SDR_Rec709_444F_IMF_2160p24_178.mxf" -s 1920x1080 -sws_flags spline -pix_fmt yuv420p10le -an -f yuv4mpegpipe -strict -1 - | "x264.exe" --demuxer y4m ...

rwill

5th February 2025, 10:51

We should do a new challenge using StEM 2 as source (https://dpel.aswf.io/asc-stem2/).

I don't know about the 5Mbit.. have you seen my StEM 2 HEVC encodes on the previous page? Either I just cannot see the problems at 4Mbit or 4Mbit was too much already.

We need a Video Buffer Size too.. I suggest 2sec of peak rate.

Z2697 already raised a valid concern about 444 -> 420 and bitdepth reduction being an undefined preprocessing step. So someone has to make a 10bit 420 of the source or alternatively just let everyone do their own thing. Or just define some recent ffmpeg version + cmdline to get to yuv420p10le.

@Z2697: 17:26 min duration sounds about right.

Z2697

5th February 2025, 11:23

I downloaded the ProRes4444XQ 4K HDR version, the IMF version is much larger.

A fairly big portion of the file is credits, that's "time speaking", the bitrate of the credits portion is much lower compared to the main portion.
Probably also why the seemlingly low bitrate look ok, it's averaged out by the credits part, the main part get a somewhat higher average bitrate.

If the encoding time is a concern, perhaps we can cut the credits part off... however I'm not sure if it will violate the license, it does say "Redistributions of these digital assets or any part of them must include the above copyright notice" though.

excellentswordfight

5th February 2025, 11:47

I downloaded the ProRes4444XQ 4K HDR version, the IMF version is much larger.

Is it? StEM2_HDR_Rec2020PQ_444F_IMF_2160p24_178.mxf is 124GiB over here. Maybe they have updated the packages? Or maybe the IMF download includes both 4K and UHD versions, it was a few years ago I downloaded it.

I havnt encoded the UHD HDR version at bitrates bellow 10Mbps, but I agree with the points above, as the source is rather easy to compress we need to choice a bitrate were modern codecs struggle, or at least will display differences that is relevant under normal viewing conditions. Has someone done a sanity check at 5Mbps?

edit.
I also now remembered this post i made: https://forum.doom9.org/showthread.php?p=1977513#post1977513 and especially this:

"Its still a bit interesting that even now when when I convert it in rather controlled fassion, there is both a luminance shift and colorshift (mostly reds as usual) compared to the Prores & AVC version that they offer. But I also saw encoding errors on the prores version, so Im not sure how carefully they have treated those versions... "

That was for the SDR-version mind you, but you might wanna doublecheck the prores HDR source as well (this is how the SDR prores looked https://ibb.co/MCFvGF7, and this is how it should look https://ibb.co/dkNhgqB)

So please be wary of that, if I also remember correctly, there are at least one bad frame in all soruces, that looks like an in-camera/capture issue.

rwill

5th February 2025, 12:37

Is it? StEM2_HDR_Rec2020PQ_444F_IMF_2160p24_178.mxf is 124GiB over here.

I havnt encoded the UHD HDR version at bitrates bellow 10Mbps, but I agree with the points above, as the source is rather easy to compress we need to choice a bitrate were modern codecs struggle, or at least will display differences that is relevant under normal viewing conditions. Has someone done a sanity check at 5Mbps?

You can always click on the link Ben has in his post to see the more or less official releases. There the ProRes is 126 GB and the IMF is 118, 243 or 554 GB.

Regarding a 5Mbit encode you can, as I stated above, always go one page back in this thread and check out my 4 and 2 Mbit encode.

excellentswordfight

5th February 2025, 14:05

You can always click on the link Ben has in his post to see the more or less official releases. There the ProRes is 126 GB and the IMF is 118, 243 or 554 GB.

The 118 IMF is the SDR-version (that I also have downloaded), I was more confused about that there was no one matching the size of the 124GiB version that I have. But I did an edit on my post, I think the 243GB one might have both a (DCI)4K and a UHD version included.

Edit. Yes thats the case, I still had the xml-files, they reference a 4K files as well: StEM2_HDR_Rec2020PQ_444F_IMF_1716p24_239.mxf, as well as StEM2_HDR_Rec2020PQ_444F_IMF_2160p24_178 (the one that I kept).

excellentswordfight

7th February 2025, 13:42

I did "baseline" encode using your critieras @benwaggoner (selected a 4s fixed IDR I-frames GOP, with adaptive non IDR i-frames placement), with just straight up preset slower and no tweaking.

"x265.exe" --y4m --preset slower --profile main10 --level-idc 50 --bitrate 5000 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 96 --min-keyint 96 --rc-lookahead 96 --no-open-gop --pass 1 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,50)" - -o NUL
x265.exe" --y4m --preset slower --profile main10 --level-idc 50 --bitrate 5000 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 96 --min-keyint 96 --rc-lookahead 96 --no-open-gop --pass 2 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,50)" - -o out

https://limewire.com/d/3010926b-e7fa-47d0-b13d-3d09a80569cc#oIw07--JjhlUvwhIxHu7gxvvemAQjThVOwMp-JGr6qk

And yes, we are going to need a harder sample that stresses the encoder more, even at what is a relative low bitrate for UHD at 5Mbps, its gonna be hard to see any meaningful differences, at least for good encoders.

benwaggoner

7th February 2025, 19:33

I haven't yet understood if FGS is really a thing or not in x265 and, actually, I don't know of players that can recreate it when reproducing HEVC video.

Does it work as in AV1, where is removed and when played reconstructed or in some other way?

Can you give us some examples of how to create a proper FGS video with x265?
Yeah, it would work the same as AV1, using a similar workflow.

x265 can mux FGS metadata from a sidecar file, so it is a thing to that degree. You'll need a tool to create the FGS metadata and players that can correctly parse that and generate the FGS overlay, which is the harder part. AV1 is really the only codec where most player software implements the FGS rendering.

There's been discussion of using either the old MPEG AVC FGS technology or using the AV1 one with HEVC, VVC, and other codecs. The AV1 is "funky" in that a lot of random seeds produce weird patterning. Tools are getting much improved year-on-year, but I'm not aware of any mainstream streaming service using AV1 FGS yet; some early devices shipped with defective implementations, not all of which have been patched since.

I've not spent enough time with practical implementations of the MPEG approach to know how well it compares, or how good the available tools are. The hardest part is the grain-parametrization-and-removal analysis preprocessing in the end. Grain removal hasn't historically been something you'd batch process whole titles through. AI is proving to be a good tool to use in this, and I think it's on the cusp of being production ready.

benwaggoner

7th February 2025, 19:40

I don't know about the 5Mbit.. have you seen my StEM 2 HEVC encodes on the previous page? Either I just cannot see the problems at 4Mbit or 4Mbit was too much already.

We need a Video Buffer Size too.. I suggest 2sec of peak rate.
I was thinking the lower of 25 Mb (max VBV for HEVC Level 5.0) or the max GOP length at peak rate. Larger allows for better rate control and multipass/lookahead encoding to improve quality. Of course, lower also stresses how well the codec handles QP spikes. Open to discussion here.

Z2697 already raised a valid concern about 444 -> 420 and bitdepth reduction being an undefined preprocessing step. So someone has to make a 10bit 420 of the source or alternatively just let everyone do their own thing. Or just define some recent ffmpeg version + cmdline to get to yuv420p10le.
For the first test I made a canonical .y4m to download, which could make sense to eliminate any risk of divergent processing. And probably edit it down some from the full length (speed up the credits?). That length wouldn't be a serious issue with HEVC or AV1 these days, but could be for VVC and AV2 due to lack of encoder maturity.

We need to be cognizant of the specifics of the Creative Commons license being used.

benwaggoner

7th February 2025, 19:42

I havnt encoded the UHD HDR version at bitrates bellow 10Mbps, but I agree with the points above, as the source is rather easy to compress we need to choice a bitrate were modern codecs struggle, or at least will display differences that is relevant under normal viewing conditions. Has someone done a sanity check at 5Mbps?

Good point. Should we identify some content with film grain? Alternatively, we could argue that in the future everything would use FGS, so how we encode no-low grain content is really the important question.

Thoughts? Any alternatives to suggest?

tormento

8th February 2025, 15:24

Yeah, it would work the same as AV1, using a similar workflow.
Given your last paragraph conclusion, do you have any idea about how to do it in real terms? Having working grain generation in hevc would be really a gamechanger.

benwaggoner

10th February 2025, 20:33

Given your last paragraph conclusion, do you have any idea about how to do it in real terms? Having working grain generation in hevc would be really a gamechanger.
I haven't messed with tools for the MPEG FGS since the HD-DVD era.

tormento

10th May 2025, 13:09

Still trying to understand how to properly use grain removal and synthesis with x265.

Any help will be really appreciated.

benwaggoner

12th May 2025, 16:46

Still trying to understand how to properly use grain removal and synthesis with x265.

Any help will be really appreciated.
Given effectively no real-world decoders support HEVC grain synthesis, the most help I could offer is avoiding that path ;).

Note that you can use AV1 FGS tools with HEVC using the AFGS1 standard. It's actually better than the original AV1 FGS as it allows the grain rendering resolution to be at display resolution while keeping grain size consistent between different resolutions. It's a relatively easy feature for hardware that has a HEVC and a AV1 decode to implement, as AV1 FGS is entirely out-of-band pre processing and post processing.

tormento

12th May 2025, 19:18

Note that you can use AV1 FGS tools with HEVC using the AFGS1 standard.
Can you please explicit this sentence? Explain me like the noob that I am :)

Boulder

12th May 2025, 19:21

With x265, the same grain table file that can be used with SVT-AV1 or aomenc, does not work.

benwaggoner

13th May 2025, 20:02

With x265, the same grain table file that can be used with SVT-AV1 or aomenc, does not work.
That would need specific AFGS1 support in x265, and more importantly players that use that metadata. Neither are hard, but are still work that needs to be done. I don't see any commits for it in x265 yet.

benwaggoner

13th May 2025, 20:15

Can you please explicit this sentence? Explain me like the noob that I am :)
This can probably help: https://aomedia.org/blog%20posts/new-film-grain-synthesis-specification-now-available/

Big picture, AV1 has an out of loop film grain synthesis feature. The workflow that a grainy source has grain removed and parameters that describe the removed grain are generated. The the de-grained video frames are encoded as normal. The grain metadata is inserted into the final bitstream like any other time-based metadata.

On playback, the decoder decodes the AV1 stream as normal. If there is grain metadata, then it synthesizes new grain hopefully matching the removed grain, which is then composited on top of the decoded video.

Note in the above, the actual codec itself has nothing to do with grain removal or synthesis. It's preprocessing, metadata, and postprocessing, entirely out of the codec's compression/decompression loop.

Because of that the AV1 grain removal can be used with any input video, and the synthesis applied to the decoded frames of any codec.

AFGS1 is AOM's specification for doing that. It also includes another grain synthesis mode where the synthesis is done at the display resolution, not the decoded frame resolution.

This fixes a big oversight in the original design. When the grain is rendered at output resolution, the grain loses detail at lower resolutions, and also needs to be generated for each input resolution.

That meant that fine source grain would become course at low bitrates/and resolutions. Grain detail would change a lot in adaptive streaming, and the goal of persevering the original grain would be lost encoding at anything but the source resolution. With the new, AFGS1-only mode, grain can always be rendered in the same way at the display resolution, so grain detail doesn't change when the bitrate does, making for a much more consistent and accurate image.

This can be especially great for content that is mostly noise, little signal, like 80's Super35 movies. At UHD, something like Ghostbusters is pretty much 720p content with a 2160p layer of grain on top of it. So Ghostbusters can be encoded at the resolution the de-grained content needs and the grain can be reconstructed in full detail.

This is all awesome, but still somewhat theoretical as AFGS1 implementations aren't really in the wild yet, and a number of early AV1 implementations shipped with defective film grain synthesis. So no one is really delivering content that uses FGS at scale yet. But the promise in terms of improved experience and bitrate reduction for the hardest to encode content is huge, so I expect it to be used a lot as the ecosystem matures.