x265 HEVC Encoder

[qidin]

Hello all!

I am a newbie coder. I need the opinion that these settings are optimal in terms of quality. I want to transcode my collection of anime. My PC is not a deamon. Its only i5 4210h (2/4).

Need optimal setings to have ~~3-4 fps. Thx for your all comments and best regards.

I think that there is still room to improve this settings but for now im lack of knolage.

--bframes 6 --ref 3 --rc-lookahead 40 --merange 24 --aq-mode 2 --aq-strength 1.1 --psy-rd 0.80 --psy-rdoq 4.00 --rd 6 --deblock -2:-2 --keyint 720 --qcomp 0.60 --me hex --output-depth 10 --limit-refs 3

PSNR: ON
Preset: Medium

[LigH]

For the joy of nitpicking: There is no optimum for every movie – just one per movie.

Reducing the in-loop deblocking for cartoons is suspicious. Usually a softer deblocking helps reducing possible artefacts in low detail color ramps. I'd recommend you to read about "--tune *" details.

PSNR is unimportant, nobody should care about this simple technical metric a lot.

[vivan]

You could start with a base value of a 1.00 = a flawless copy of the source. At 0.95 = you could estimate there is a 0.05% degradation between the original frame and the encoded ones, At 0.90 = there's a 0.10% degradation from the original and so forth.That's how objective quality metrics work (and how most comparisons are made, except all of this is done in 1-2 steps. In fact you've done this already with your csvs). The main problem is defining that "degradation". If you choose to use simple difference, that will be PSNR (simple but has low correlation with Human Vision System aka what we think good/bad quality is). SSIM is better, but still far from perfect.

As for marking difference - it's easy to do this with avisynth, for pixels that would be Subtract (http://avisynth.nl/index.php/Subtract) with some tweaking, for blocks that will be a bit harder.

[Motenai Yoda]

As you will encode frames from different scenes 98% you'll get all keyframes, so the comparison will be invalid.

but you can get some short clip with selectrangeevery() in avisynth
all others points can be done with an avs script (maybe the "cell" thing can be a bit slow), but on an lossy encode easely most of the pixel somehow differ from the source.
Also surely ssim, avgQP and maybe psnr too will do a better job to estimate the "loss".

[vivan]

As you will encode frames from different scenes 98% you'll get all keyframes, so the comparison will be invalid.He never said that he's going to use frames for different scenes, he just said "Cut out a 60 seconds sample"...

@vivan: do you have a guide on how to do that with existing open-source tools?You can start here (http://avisynth.nl/index.php/Main_Page) to learn about avisynth - tool that most of us use to process/inspect video.

Okay, let's say you want to measure PSNR (get PSNR value per frame) using avisynth Compare (http://avisynth.nl/index.php/Compare). Install:
1) avisynth (http://avisynth.nl/index.php/Main_Page) (v.2.6.0 ST, 32-bit)
2) AvsPmod (http://forum.doom9.org/showthread.php?t=153248) (to view script output)
3) ffmpegsource (http://avisynth.nl/index.php/FFmpegSource) (plugin to open your video in avisynth, put it into "plugin" folder in the avisynth's install directory)

Write s = ffvideosource ("source.mkv")
e = ffvideosource ("encode.mkv")
Compare (s, e) into text file, change it's extension to .avs, open it with AvspMod. It will show PSNR value.

Change last line to Interleave (s, e, Subtract(s, e).levels(122,1,132,0,255))to see per-pixel differences.
(If you will have questions about avisynth, please ask them in the avisynth subforum)

When I was thinking of cells earlier, I had something like this in mind; http://www.streameye.elecard.com/images/trash/screen_other2.jpg

Not exactly that, but it's getting close enough, I would just have added a color filter on top of each grid cell based on the "distortion" compared from original and encoded bits.I don't remember seeing anything like this, so I guess asking here (http://forum.doom9.org/forumdisplay.php?f=33) for a script that will do what you want (compare 2 videos and tint all blocks depending on psnr value of that block) is what you need.

[LigH]

I remember a comparison tool "Fritz Framalyzer", but never used it, so don't know if it matches your expectations.

Always remember, metrics only calculate a value related to a difference between two videos, but there is no metric which can calculate how pleasant or annoying a specific loss of quality looks to you, specifically.

[benwaggoner]

I note a probable typo in the x265.readthedocs for --lookahead-slices (http://x265.readthedocs.org/en/default/cli.html?highlight=lookahead#cmdoption--lookahead-slices)

Default: 8 for ultrafast, superfast, faster, fast, medium 4 for slow, slower disabled for veryslow, slower

That presumably should end in "veryslow, placebo"

...which I was looking up as I'm wondering what sort of degradation that using lookahead-slices might cause. Using frame-threads could cause bad problems with high-noise content, but didn't seem to have much impact on "normal" content. Would lookahead-slices impact the same scenarios? Or does it only impact I/P/B/b decisions?

[x265_Project]

I note a probable typo in the x265.readthedocs for --lookahead-slices (http://x265.readthedocs.org/en/default/cli.html?highlight=lookahead#cmdoption--lookahead-slices)



That presumably should end in "veryslow, placebo"
Yes. We'll fix this. Note that anyone can submit "patches" to our online documentation, as they are in Restructured Text format (.rst) files which are part of the source code.

...which I was looking up as I'm wondering what sort of degradation that using lookahead-slices might cause. Using frame-threads could cause bad problems with high-noise content, but didn't seem to have much impact on "normal" content. Would lookahead-slices impact the same scenarios? Or does it only impact I/P/B/b decisions?
As you know, the lookahead function does a quick pseudo-encode based on 1/4 resolution frames. The function of the lookahead is to estimate the cost (# of bits) of encoding each frame, and to make slice type (I/P/B/b) decisions. Parallelizing the lookahead by using multiple slices per frame has an extremely minimal negative effect on encoding efficiency, but in certain cases (especially 4K encoding on many-core servers) a big positive effect on performance. This is easy to experiment with, just by doing a couple of test encodes with various --lookahead-slices values, including 0.

[littlepox]

As you know, the lookahead function does a quick pseudo-encode based on 1/4 resolution frames. The function of the lookahead is to estimate the cost (# of bits) of encoding each frame, and to make slice type (I/P/B/b) decisions.

That's probably the issue here. Down-scaling to 1/4 resolution is likely to wipe out the noise, which later makes the estimation biased towards inadequate bit-rates. Normal scenes are less affected by the down-scaling.

If that is the case, possible solutions may be a manual bias favored for the noisy scenes, adding a 1/4 cropped clip as a second predictor, or enabling full resolution look-ahead in some presets and turnings.

[x265_Project]

That's probably the issue here. Down-scaling to 1/4 resolution is likely to wipe out the noise, which later makes the estimation biased towards inadequate bit-rates. Normal scenes are less affected by the down-scaling.

If that is the case, possible solutions may be a manual bias favored for the noisy scenes, adding a 1/4 cropped clip as a second predictor, or enabling full resolution look-ahead in some presets and turnings.
We've made various improvements to the lookahead function over the life of the project and we are currently investigating a number of possible ways to improve the accuracy of lookahead predictions. Full resolution lookahead is one possibility, but the idea behind the lookahead function is to perform some pre-analysis with low computational cost (for example, lookahead might be 2% of the total compute cost). If you try to do too much, the costs could outweigh the benefits. Essentially you could just end up with 2 pass encoding, where the lookahead is like a fast first pass (a fairly accurate predictor of the actual per-frame cost that a 2nd pass can use to allocate bits). Of course we already support 2 pass encoding, which is great for high quality variable bit rate encoding. So, the challenge is to improve the lookahead so that can continue to be used as it is today - as a fast pre-analysis function running ahead of the actual encoder.

[littlepox]

If you try to do too much, the costs could outweigh the benefits.

Understandable, and that's why I'm only suggesting it to be applied for certain preset and tunings, for example adding a center-cropped clip as a second predictor in --veryslow and use full resolution in --placebo.

Furthermore, 2 suggestions for the --presets:

1. --ctu 32 --max-tu-size 16 for presets slower and below. Our tests suggest a ~5% speed increase and a BETTER visual quality @ the same bit-rate.

2. auto-adjusted me-range for different resolutions. Probably 25 for 720p and 41 for 1080p; as from our tests. When --umh/--star/--esa are deployed, me-range affects the speed dramatically, so it make sense to seek some affordable discount, especially if combined with the 1st suggestion which affects the derivation of the current merange=57.

[Vesdaris]

Increase --psy-rd strength to a value higher than the current default (0.3).

http://i.imgur.com/b6MWSnY.jpg

Just psych-visual rdo? Should I leave RDO Quantization level disabled?

[LigH]

Turn up the signal
wipe out the noise
:sly:
_

Some interesting patches still on hold; releasing another "weekly" anyway, since I postponed the last.

x265 1.8+129-e2e507ffe752 (GCC 4.9.2) (https://www.mediafire.com/download/yb4zxb4340l6mbv/x265_1.8+129-e2e507ffe752.GCC492.7z)
x265 1.8+129-e2e507ffe752 (GCC 5.2.0) (https://www.mediafire.com/download/skyf5d7s9tck2zc/x265_1.8+129-e2e507ffe752.GCC520.7z)

[x265_Project]

http://i.imgur.com/b6MWSnY.jpg

Just psych-visual rdo? Should I leave RDO Quantization level disabled?
Adjust psy-rd (Psycho-Visual RDO) only to start. When you have determined the best psy-rd strength, you could experiment with different psy-rdoq strengths.

[Aurelio]

Has anybody tried to play x.265 encoded video file via ffmpeg on a mobile device? I have some strange issues on my Samsung Galaxy S5 (SM-G900F)

If I use a 2-pass encode, the video does not show a preview picture in the gallery / own files. It shows only the icon of the player.

If I use single pass ABR or CRF mode, a preview picture is shown.

I'm using a self compiled ffmpeg version:
ffmpeg version N-76970-ge1057ba Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.2.0 (GCC)
x265 [info]: HEVC encoder version 1.8+2-1f0d4dee7e3b
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit

These are the command lines I use on a windows system:

2-pass

ffmpeg.exe -y -i "title.mov" -c:v libx265 -preset medium -s 1280x720 -aspect 16:9 -x265-params "bitrate=2000:keyint=60:scenecut=0:pass=1:stats="'mylog.log'"" -c:a libfdk_aac -b:a 384k -f mp4 NUL
ffmpeg.exe -i "title.mov" -c:v libx265 -preset medium -s 1280x720 -aspect 16:9 -x265-params "bitrate=2000:keyint=60:scenecut=0:pass=2:stats="'mylog.log'"" -c:a libfdk_aac -b:a 384k -f mp4 "title.mp4"

-------------

1-pass

ffmpeg.exe -i "title.mov" -c:v libx265 -preset medium -s 1280x720 -aspect 16:9 -x265-params "bitrate=2000:keyint=60:scenecut=0:log-level=4" -c:a libfdk_aac -b:a 384k -f mp4 "title.mp4"


Videos source does not matter. Can reproduce this with any file. e.g. Big Buck Bunny.

However the MX Player does shows the preview picture in the overview.


The other issue I have:

I have some files which play fine with these settings on the device and others which start to play but then suddenly the video picture freezes and the player skips some frames.

If I changing scenecut setting (e.g. use default) the video freezes at other scenes. Lowering bitrate and/or resolution fixes this.

I'm not sure if this is a hardware limitation or video player issue (tested 2 different ones with same results) or a ffmpeg / x.265 issue. Not sure on what the players choke on.

[Blowis]

Hi, sorry for my English

After encode several films x265 I stay x264. The last movie I can see that encoded on the X265 lacks detail compared to x264.
I tried Whelk test for X265 detail but no it does not x264. I tried with Psy-rd: 0.30 to 2.0, RDOQ Level: 1-2, Psy RDOQ: 0.30 to 2.0, Deblock: -1 to -5, AQ Strength: 0.30 to 1.20. Usually I use the preset Medium but I also tested slow and very slow.

Here x264 encoding with this setting:
cabac=1 / ref=10 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=3031 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Here the encoding image: http://hpics.li/779de15

Here the X265 encoding with this parameter:
wpp / ctu=32 / min-cu-size=8 / max-tu-size=16 / tu-intra-depth=2 / tu-inter-depth=2 / me=2 / subme=3 / merange=48 / no-rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=25 / lookahead-slices=4 / bframes=6 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=3 / limit-modes / weightp / weightb / aq-mode=3 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=0.80 / rdoq-level=1 / psy-rdoq=1.00 / signhide / deblock=-2:-2 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Here the encoding image: http://hpics.li/057ed69

We can see that there's less detail on all over the face on the side the beard, on the neck.
After he remains the encoding time is very long compared to x264 example encodings I gave 6 hours for the x265 against 5 Hours to x264. If I make the 2pass x265 takes 9 hours.
I won with the X265 500MB for a film but for now I'll stick with the x264. But continue testing with the new updated the X265.

[x265_Project]

Chennai India is experiencing record-breaking rainfall and flooding. Offices are closed, power and Internet service outages are widespread. Although some of us are in the US, most of the MulticoreWare x265 development team is in Chennai.

Of course the safety and well-being of our employees and their families comes first. While it's been difficult reaching everyone, so far our team members are reporting that they are safe, but dealing with flooding in their homes and neighborhoods. They are doing their best to cope with the situation, working from home when they have power, and communicating when they have Internet or phone service. A number of employees are temporarily relocating to other parts of India.

The weather forecast is for more rain through the next week, so it may be another week before the floods recede and we're able to re-open our office. So, please understand that response times to issues and questions may be a bit longer in the coming days.

Thanks,
Tom

[LigH]

Sounds like a little desaster. I can partially understand, witnessed some flood in eastern Germany years ago, but will probably have to imagine a whole magnitude larger. So, best wishes for little loss and soon subsiding.

[ndkamal]

@x265_Project : I hope they are all safe and good health.

[x265_Project]

Thanks everyone. We've heard from our managers, and although our team is dealing with various difficulties, including homes and cars being flooded, power, phone and Internet outages, and difficulty obtaining food, water and gasoline, they are getting through it.

I found this video on YouTube, showing the basement in the office complex (DLF IT Park) filling up with water. https://www.youtube.com/watch?v=CF2NXVmZvjg (https://www.youtube.com/watch?v=CF2NXVmZvjg) Two levels of the basement are filled with water, but our offices on the first floor were not flooded.

[undfeatable]

Sorry to hear about the flooding, hope the team comes out okay.

I figured this was the right place to post this, really bad timing, but figured I should point it out. Im new to all this... coding in general...this forum... and am having an issue when running h265.

It took forever for me to learn enough to set the program up, but I have it running now and encoding correctly on my Macbook Pro. Im running the linux build and doing test encodes for HDR.

Here is my issue, for some reason, the program will only run 50% of the time. I set it all up, hit enter, and it gives me a Segmentation Fault 11. I just keep trying to rerun it until it eventually goes through. Any ideas on why this would be? Which files would you need to debug this / how to get those if you need them. Completely understand any delay with the flooding.

[x265_Project]

Sorry to hear about the flooding, hope the team comes out okay.

I figured this was the right place to post this, really bad timing, but figured I should point it out. Im new to all this... coding in general...this forum... and am having an issue when running h265.

It took forever for me to learn enough to set the program up, but I have it running now and encoding correctly on my Macbook Pro. Im running the linux build and doing test encodes for HDR.

Here is my issue, for some reason, the program will only run 50% of the time. I set it all up, hit enter, and it gives me a Segmentation Fault 11. I just keep trying to rerun it until it eventually goes through. Any ideas on why this would be? Which files would you need to debug this / how to get those if you need them. Completely understand any delay with the flooding.
You can build x265 for MacOS. This will probably work better. than a Linux build. Try the nightly build of Handbrake... https://handbrake.fr/nightly.php

[smok3]

The one with in static ffmpeg seems to work fine as well (No idea on how to switch to 10 bit thought)
http://evermeet.cx/ffmpeg/

[nima2010]

i have a little problem with x265, when i encode with x265 i cant see media info of encoded file!!

i update my k-lite codec even used different ver. of mkvmerge but still cant see media info :(
any suggestion how i can fix it?

[LigH]

Another K-Lite victim ... Nobody should need codec packs. LAV Filters handle most common formats without burdening the system with too much ballast. And furthermore, a codec pack is absolutely irrelevant for both the x265 encoder and the MediaInfo analysis; it doesn't matter if it is installed, so it doesn't matter if it is updated.

What do you mean by "cant see media info of encoded file"? Do you miss the auxiliary information about the x265 internal encoding parameters, this huge string? Well, that may depend on the MediaInfo DLL used by the player (looks like you are using an MPC variant to look at the file info). Is the player (with its MediaInfo component) up to date? And how did you encode with x265, did you use a tool which may disable the storage of this auxiliary parameter string?

[nima2010]

Another K-Lite victim ... Nobody should need codec packs. LAV Filters handle most common formats without burdening the system with too much ballast. And furthermore, a codec pack is absolutely irrelevant for both the x265 encoder and the MediaInfo analysis; it doesn't matter if it is installed, so it doesn't matter if it is updated.

What do you mean by "cant see media info of encoded file"? Do you miss the auxiliary information about the x265 internal encoding parameters, this huge string? Well, that may depend on the MediaInfo DLL used by the player (looks like you are using an MPC variant to look at the file info). Is the player (with its MediaInfo component) up to date? And how did you encode with x265, did you use a tool which may disable the storage of this auxiliary parameter string?

i use last ver of mpc hc and mpc be both cant show media info of my encode but i can others encode too!!
too odd
the fun part is before i update my x265 i could saw media info
see

[nima2010]

i use last ver of mpc hc and mpc be both cant show media info of my encode but i can others encode too!!
too odd
the fun part is before i update my x265 i could saw media info
see

this screen shot is from other encoder with x265 ,i can see their setting

[LigH]

Well, interesting. So please tell us all the details about your new x265 you can gather. It is always possible that a "regression" happened (a bug was introduced while fixing another) which makes x265 in the newest versions believe it should omit the auxiliary strings.

Please try to post an output of "x265 --ver", and the whole command line used for your encode (except the filenames).

[Selur]

as a small side note: x265 has an option to omit the SE info (--no-info)
+ may be updating mkvtoolnix might also help

[benwaggoner]

Furthermore, 2 suggestions for the --presets:

1. --ctu 32 --max-tu-size 16 for presets slower and below. Our tests suggest a ~5% speed increase and a BETTER visual quality @ the same bit-rate.
At what frame size and ABR? I anticipate you'd lose a lot of efficiency for UHD with those limitations.

2. auto-adjusted me-range for different resolutions. Probably 25 for 720p and 41 for 1080p; as from our tests. When --umh/--star/--esa are deployed, me-range affects the speed dramatically, so it make sense to seek some affordable discount, especially if combined with the 1st suggestion which affects the derivation of the current merange=57.
I'm not sure that the me-range actually scales linearly to frame size. At least in x264, it was the refinement range from the initial predicted matches from the lookahead. So Even in UHD, the 57 pixel search range could start a thousand pixels away from the block being matched to.

It might be helpful to plot the PSNR/SSIM/RF and speed impact of different me-range values at a few different frame sizes.

They probably could be smaller for very low frame sizes

[undfeatable]

You can build x265 for MacOS. This will probably work better. than a Linux build. Try the nightly build of Handbrake... https://handbrake.fr/nightly.php

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.

I'm pretty sure I have it built for MacOS, at least inside my CMake application I go CMake.app -> Contents -> MacOS -> x265 -> build -> linux
I have the processors set up properly too. Here is an example of what it does:

yuv [info]: 3840x2160 fps 24000/1000 i420p10 frames 0 - 199 of 200
raw [info]: output file: TestC1.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-6.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 1 / 25 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-40000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 120000 / 120000 / 0.900
x265 [info]: tools: rect rd=4 psy-rd=0.30 rdoq=2 psy-rdoq=1.00 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Segmentation fault: 11


Like I said though, it looks exactly the same whether it fails or goes through.

[x265_Project]

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.
Why would it matter whether a command-line interpreter or a graphical user interface called x265? x265 doesn't care.

I run x265 from the command line very frequently, but won't hesitate to use a GUI application.

We can have our team look at this segmentation fault error if it persists. In the meantime, make sure you follow the instructions on BitBucket for compiling x265 for MacOS. https://bitbucket.org/multicoreware/x265/wiki/Home

[nima2010]

as a small side note: x265 has an option to omit the SE info (--no-info)
+ may be updating mkvtoolnix might also help

yeah , i update mkvtoolnix to ver 8.6.1 now i can see media info of my x265 encode
there is something i want to ask , how i can decrease encoding time without losing quality? i dont care file size become the as x642 or bigger, i use x264 alot and encoding speed is good but for x265 is 1 fps ,it takes too much time to encode even for 720p file i decide to change setting but didnt use x265 alot and some setting are different with x264 or i didnt care to change them but for x265 i think situation is different ,by the way i just re-encode anime ,and i'm looking for good setting for big display ,like 40 inch TV ,plz guide me
is it necessary to update x265 when ver released? i barely update x264 but dont know about x265

[LigH]

The speed preset has less influence than the bitrate or quality (rate factor) target. For faster presets with a lower complexity, the encoder may not spend as much time searching for ways to spare bitrate, so the result may be a bit bigger, but the CRF mode will try to ensure that the loss of quality stays below a certain threshold.

The development of x265 is still very active, in contrast to x264 which is already rather "mature". You may not have to update often, but once in a while there are still quite important improvements in x265.

To improve results for real cartoons, x265 will probably implement a tuning like "--tune animation" in x264, but I am not sure if this already happened or is still scheduled.

[smok3]

@undfeatable: how is this one?
https://dl.dropboxusercontent.com/u/79532365/x265_10bit_bronto.zip

x265 --version
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Only did a very fast test like
x265 in.y4m --crf 21 out.mp4
and it didn't seqfault.

[nima2010]

The speed preset has less influence than the bitrate or quality (rate factor) target. For faster presets with a lower complexity, the encoder may not spend as much time searching for ways to spare bitrate, so the result may be a bit bigger, but the CRF mode will try to ensure that the loss of quality stays below a certain threshold.

The development of x265 is still very active, in contrast to x264 which is already rather "mature". You may not have to update often, but once in a while there are still quite important improvements in x265.

To improve results for real cartoons, x265 will probably implement a tuning like "--tune animation" in x264, but I am not sure if this already happened or is still scheduled.

how i can findout tune animation added or not?
also about encode setting i always use crf mode it's really good for re-encoding anime, i use crf 18-22 but with x265 it takes along time looking for decreasing time ,i use slower preset ,bframe 6 rc lookahead 30 ref 3 ,with subme 3 i can encde 1.8-2.5 fps for 720p ,any better setting ?

[sneaker_ger]

how i can findout tune animation added or not?
In doubt just test it and see if there is an error message or look into the documentation (http://x265.readthedocs.org). (--tune animation does not exist)

also about encode setting i always use crf mode it's really good for re-encoding anime, i use crf 18-22 but with x265 it takes along time looking for decreasing time ,i use slower preset ,bframe 6 rc lookahead 30 ref 3 ,with subme 3 i can encde 1.8-2.5 fps for 720p ,any better setting ?
Try adding --limit-refs 3 and --limit-modes. These are new options still in testing and not yet added to the presets. They improve speed significantly while hopefully only marginally reducing compression efficiency:
http://forum.doom9.org/showpost.php?p=1746714&postcount=2905

I the long-term I'd not use too many options because you might miss future improvements of the presets. Preset slower uses rc-lookahead 30, ref 3 and subme 3 anyways. I guess limit-refs and limit-modes are among those options that will be incorporated into the presets in the not so distant future.

If it's still too slow do the obvious and switch to preset "slow", "medium", "fast" etc. That's the reason they exist.

[Motenai Yoda]

@vivian my bad, but it's always a sample, isn't rappresentative of the entire video
btw what pingfr want to do make me think about an absolute signal-noise difference percentile

@nima2010 it isn't
try with more reference and limit-ref 3 and limit-mode

[FranceBB]

@nima2010... basically what a codec does is removing spacial redundancy and, to do that, it uses a transform to transform "blocks of pixels" into coefficients (that's why you see blocking artifacts with low-bitrate: the transform is not applied to the whole picture because of a complexity matter; they tried with JPEG2000). Then, these coefficients are passed to the quantiser in order to get rid of high frequencies (that are not important for the human vision) and to save space.
The better transform available in terms of compression efficiency is the KLT (Karhunen–Loève transform), but its drawback is that it's an highly complexity transform, so they decided to use the DCT (Discrete Cosine transform) in x264 because it has a relatively good compression efficiency.
What x265 does, instead, is using both DCT and KLT (NOT simultaneously: it automatically switch between DCT and KLT depending on which blocks it has to encode) in order to compress images in a better way than the DCT alone, without increasing complexity too much.
That said, it's pretty normal that x265 takes more time to encode than x264 with the same settings.
Anyway, x265 is able to use multiples processors and its development is going on actively, so I strongly suggest to keep it update.
Besides, x265 is a way better than x264 in terms of compression and the initial designed target of a 50% bitrate reduction has been fulfilled.
As soon as I'll have time, I'm gonna run an encode on a xeon phi coprocessor using both x264 and x265 in order to see if x265 will be able to fully use all the cores and to demonstrate that, probably, x264 will not be able to use them.

[x265_Project]

Try adding --limit-refs 3 and --limit-modes. These are new options still in testing and not yet added to the presets. They improve speed significantly while hopefully only marginally reducing compression efficiency:
http://forum.doom9.org/showpost.php?p=1746714&postcount=2905

I the long-term I'd not use too many options because you might miss future improvements of the presets. Preset slower uses rc-lookahead 30, ref 3 and subme 3 anyways. I guess limit-refs and limit-modes are among those options that will be incorporated into the presets in the not so distant future.

Yes. limit-refs and limit-modes will be added to updated presets as soon as we are able to complete our testing (delayed a week due to flooding in Chennai).

[undfeatable]

@undfeatable: how is this one?
https://dl.dropboxusercontent.com/u/79532365/x265_10bit_bronto.zip

x265 --version
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Only did a very fast test like
x265 in.y4m --crf 21 out.mp4
and it didn't seqfault.

Negative, it still happens randomly
yuv [info]: 3840x2160 fps 23976/1000 i420p10 frames 0 - 199 of 200
raw [info]: output file: HDRTest.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-6.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 1 / 25 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-40000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 120000 / 120000 / 0.900
x265 [info]: tools: rect rd=4 psy-rd=0.30 rdoq=2 psy-rdoq=1.00 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Segmentation fault: 11

I just download Handbrake, won't be able to test much for at least a week or so, but Ill let y'all know.

[benwaggoner]

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.
I can't speak to Handbreak specifically (it's more of a heartbreak for me whenever I've tried to us it for anything mildly interesting :)).

But there are a bunch of somewhat esoteric parameters that need to be set for a proper HDR-10 bitstream. Looking at a test file I did a few months ago:
--colorprim bt2020
--transfer 16
--colormatrix bt2020nc
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0)"
--max-cll "1000,274"
--chromaloc 2
And, of course, you'll need to know what your master-display, MaxCLL, and MaxFALL values are for your content.

And you'll need to have a >=10-bit source that's already in the SMPTE 2084 PQ space, not gamma.

Also, I note you're targeting Level 5.1. AFAIK, there aren't any existing HEVC Main10 decoders that support beyond Level 5.1. Which can do 2160p60 :)!

[Ma]

Negative, it still happens randomly
yuv [info]: 3840x2160 fps 23976/1000 i420p10 frames 0 - 199 of 200
raw [info]: output file: HDRTest.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
...


If the same binary works with SSE4.2 CPU and hangs with AVX2 CPU, you can add '--asm AVX' option or '--asm SSE4.2' option and retest.

[Vesdaris]

So, I've been playing with medium preset and crf/psy-rd\rdoq\psyrdoq\loo filter values trying to preserve as much details as possible compared to the original and making encoded video smaller than x264(x264 hi10p, crf18 very slow preset) one and I got a question- Is it even possible?

We have three files :
A - original
B- x264 hi10p, crf18, very slow preset (subme-9 instead of 10 coz I don't like how it make things look)
C- x265 main10 medium(slow doesn't help things just makes encoding very slow and possibly but now always smaller size-wise) with tweaked differently crf\psy-rd\rdoq\psyrdoq\loo filter values.

A and B are identical visually. However, no matter how much I tried I couldn't get x265 encode look the same as the original\x264.There were always small details missing here and there, small blur here and there, you name it. These issues were prolly not that obvious when watching it in motion but clearly distinguished when comparing png screenshots(original\x264\x265).

I even got really close to x264 bitrate-wise and x264 still looked more "clean".And there was no point increasing bitrate any further coz ,well, why bother if x264 hi10p does it all and faster.

What settings do you guys use to make x265 encode as close to the original'x264hi10p as possible but still keeping it smaller in size?

[luigizaninoni]

you might try these: (good for sd; for hd you had better increase crf, max-tu-size, merange, ctu)

--crf 17.5 --preset slow --output-depth 10 --rd 5 --ctu 16 --max-tu-size 8 --limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 1 --no-rect --b-intra --qg-size 16 --qcomp 0.71 --subme 5 --merange 32 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --ref 5 --min-keyint 1 --keyint 400 --no-strong-intra-smoothing --rdpenalty 2 --deblock -2:-2 --psy-rd 0.7 --psy-rdoq 1.7 --no-sao

[LigH]

*TILT*

With so many single options, does any "preset" still make sense, or are all contained options superseded anyway?

And could you explain for each of them why they would be better than the preset defaults?

[Vesdaris]

you might try these: (good for sd; for hd you had better increase crf, max-tu-size, merange, ctu)

--crf 17.5 --preset slow --output-depth 10 --rd 5 --ctu 16 --max-tu-size 8 --limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 1 --no-rect --b-intra --qg-size 16 --qcomp 0.71 --subme 5 --merange 32 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --ref 5 --min-keyint 1 --keyint 400 --no-strong-intra-smoothing --rdpenalty 2 --deblock -2:-2 --psy-rd 0.7 --psy-rdoq 1.7 --no-sao

Thanx but I guess I forgot to mention one important detail. Encoding speed mustn't be that of a dying turtle lol as in 6-8fps is a min.(3770k@4.5)
PS crf17.5? Even lower than x264 to get supposedly the same quality? I'm testing these settings on a sample file and judging by the bitrate the file size will be too close(4700-4800 vs 5200+) to x264 hi10p size. So, no point, especially taking into account absolutely ridiculous encoding speed....even if I set crf higher than 17.5 encoding speed won't change.

[luigizaninoni]

@ligh: tune-film does not exist at the moment, so this would be a suggestion for tune-film SD. imho there should also be tune-film HD and UHD (different from one another). I sure won't comment on each parameter (for some of them I have only a very rough idea of what they do), but I can say that no-rect is a necessity at the moment, because rect and amp give practically no benefit, and speed is 40% slower. Useless atm. Merange 32 is more than enough for SD, sure it could be increased for HD. Keyint 400 is a little trick to gain a bit of compression in static scenes, maybe it saves 1% or 2% bitrate. Defaults for psy-rd and psy-rdoq are too low (0.30 and 1.00 if I remember correctly), they definitely should be increased (how much exactly, remains to be seen).

@Vesdaris: I easily attain 11-12 fps on my i7-4770s on SD, it is an acceptable speed in my opinion. I agree that with HD it is very slow.

[burfadel]

@ligh: tune-film does not exist at the moment, so this would be a suggestion for tune-film SD. imho there should also be tune-film HD and UHD (different from one another). I sure won't comment on each parameter (for some of them I have only a very rough idea of what they do), but I can say that no-rect is a necessity at the moment, because rect and amp give practically no benefit, and speed is 40% slower. Useless atm. Merange 32 is more than enough for SD, sure it could be increased for HD. Keyint 400 is a little trick to gain a bit of compression in static scenes, maybe it saves 1% or 2% bitrate. Defaults for psy-rd and psy-rdoq are too low (0.30 and 1.00 if I remember correctly), they definitely should be increased (how much exactly, remains to be seen).

@Vesdaris: I easily attain 11-12 fps on my i7-4770s on SD, it is an acceptable speed in my opinion. I agree that with HD it is very slow.

I totally agree about rect, amp, and merange. A while ago I mentioned to Stax to put in a variable merange into Staxrip, which was done (at a basic level). Maybe the same thing could be done with x265. That is, if the input resolution is say, 864x480 that the merange is set to say, 25, and scale that up to 57 the higher the resolution you go, or at least to a value that gives you the best quality without penalty of encode time.

At the moment if you think of it, at least the way I see it, having a fixed rate of 57 means that it is actually significantly greater at SD resolution (and effectively be 'placebo' at 57) than it is at UHDTV resolution.

I also agree with the psy-rd statement (not so sure about psy-rdoq). I have mine set at 0.5 which I think is better. Realistically though, even 0.5 may be too conservative.

With these settings:
--crf 21 --output-depth 10 --limit-refs 1 --tu-intra-depth 3 --early-skip --b-intra --aq-mode 3 --qg-size 16 --subme 3 --me star --merange 25 --max-merge 5 --weightb --bframes 6 --rc-lookahead 40 --ref 6 --keyint 600

I am currently getting around 26-28 fps encoding material of 1280x720 to 864x480. That is actually what it is getting running in the background as I type this. This is using Staxrip with the latest 1.8+132 x265, latest ffmpeg, AVX build, using the latest l-smash-works, avisynth+, and the filters vinverse2, deveed, f3kdb, and using blackmanresize with 8 taps.

This is on a i5-3570K at 4.3 GHz, so isn't using AVX2.

I found that setting --tu-intra-depth 3 gave slightly better quality with no noticeable performance penalty. I also found adding --early-skip gave noticeably better performance without a quality or file size hit (or so fractionally slight the speed gain far outweighed any 'loss'). --max-merge 5 is probably overkill, but setting it higher than default I believe gives a small quality/and or file size improvement with only a small penalty in performance. Basically --qg-size 16 is a must, and I believe --aq-mode 3 is as well :). Adding --limit-refs 1 was certainly worth it, I did try the higher ones but the performance gains were only small compared to --limit-refs 1, I didn't see the need to use anything higher.

I found --me-star to be quite surprisingly good both quality an speed wise, at least for what I've been encoding at non-UHDTV resolutions. The setting --me-star actually kind of makes hex and umh modes redundant seeing as your get hex speeds with what appears to be umh quality.

So, with those settings I not only get better quality than the default settings, but I believe it is also faster!

[Blowis]

So, I've been playing with medium preset and crf/psy-rd\rdoq\psyrdoq\loo filter values trying to preserve as much details as possible compared to the original and making encoded video smaller than x264(x264 hi10p, crf18 very slow preset) one and I got a question- Is it even possible?

We have three files :
A - original
B- x264 hi10p, crf18, very slow preset (subme-9 instead of 10 coz I don't like how it make things look)
C- x265 main10 medium(slow doesn't help things just makes encoding very slow and possibly but now always smaller size-wise) with tweaked differently crf\psy-rd\rdoq\psyrdoq\loo filter values.

A and B are identical visually. However, no matter how much I tried I couldn't get x265 encode look the same as the original\x264.There were always small details missing here and there, small blur here and there, you name it. These issues were prolly not that obvious when watching it in motion but clearly distinguished when comparing png screenshots(original\x264\x265).

I even got really close to x264 bitrate-wise and x264 still looked more "clean".And there was no point increasing bitrate any further coz ,well, why bother if x264 hi10p does it all and faster.

What settings do you guys use to make x265 encode as close to the original'x264hi10p as possible but still keeping it smaller in size?

After several tests I managed to approach the x264.
To do that I use medium profile I change ctu = 16 psy-rd = 1.00 rdoq-level = 2 psy-rdoq = 1.10.