Benwaggoner HEVC encoding challenge

[benwaggoner]

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.

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


Here's the source I used (.y4m.7z): https://1drv.ms/u/s!AlvIQZWsyeO-kKpoG5f3PHAFhWcGig

And my current best HEVC x265 encodes:
1.0: https://1drv.ms/v/s!AlvIQZWsyeO-kKpmDQlxoY-00rk3AQ
1.5: https://1drv.ms/v/s!AlvIQZWsyeO-kKplp2EQ8-Q4bCNVZw
2.0: https://1drv.ms/v/s!AlvIQZWsyeO-kKpZkpw-WQKF1dSF_g

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.

Update 6/3/2021
To evaluate anime/line art encoding I'm adding Netflix's Sol Levante as a second source for testing. It's an interesting compression challenge with a lot of titles/credits that can be shrunk down enormously, and some very complex hybrid line art/CGI sequences that x265 can't make look great at even 12 Mbps. It should be very interesting for rate control!

Sol Levante's 4K HDR source is available (http://download.opencontent.netflix.com/?prefix=SolLevante/) 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. The challenge follows the same constraints for bitrate, VBV, etcetera.

[Forteen88]

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]

Older devices with early HEVC decoders?

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

[smok3]

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

[benwaggoner]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

WOW.

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

[jonatans]

WOW.

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

Thanks! :)

[ShortKatz]

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]

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]

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]

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]

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]

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]

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]

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]

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]

THAT would be an amazing degree of parallelization!

Easy if you divide movie in chunks...

[benwaggoner]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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?

[Ma]

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]

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.

[Ma]

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]

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).

[Ma]

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]

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

[TomV]

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]

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!