x265 HEVC Encoder

[James Freeman]

Alright surami.

Basically What I need now is the smallest high bitdepth Image file that After Effects will render the fastest.
Cineform RGBA 12bit is smaller that PNG 16bit?

[surami]

I need to test too what you did, what was your exact visual source, settings, etc., let's continue in the other topic, if that is good for you and so poeple could follow there the process.

[James Freeman]

Alright moving there, I'll reserve the x265 HEVC question to this thread.

[Jamaika]

I hope your mp4box example is better, I don't know enough about mp4box to judge it.
MP4Box recently is more stable. Although HEVC codec without command ":xps_inband" has a black screen. Player reads it as 8bit.
I use .h265 in MP4Box because of .hevc I had problems previously.
I had to add "-vf colormatrix=bt601:bt709" to ffmpeg so the RGB -> YUV color conversion will be correct.
For what purpose?

[James Freeman]

Actually everything is A OK with the mp4box I'm using with the very basic settings.
Right image and 10bit.

[James Freeman]

After few tests, OpenEXR sequence is actually smaller and faster to render than PNG, and it is in floating point too.
And most importantly ffmpeg can work with EXR.

I had to add "-vf colormatrix=bt601:bt709" to ffmpeg so the RGB -> YUV color conversion will be correct.
For what purpose?

Without this command the last few steps of Chroma are clipped (shifted).
I read somewhere that ffmpeg treats RGB as 601 so this conversion has to occur for the colors to be right in 709.
After encoding I compared with the original RGB image and indeed the colors are accurate 1:1 which is important when creating calibration/measurement patterns.
http://forum.videohelp.com/threads/366469-x264-Which-colorspace-is-best-for-input?p=2340122&viewfull=1

EDIT Important!
The "-vf colormatrix=bt601:bt709" should be changed to "-vf scale=out_color_matrix=bt709" because the colormatrix command is only 8bit and it dithers down to 8bit.
While the scale=out_color_matrix=bt709 command bypasses any conversion while retains correct chroma values between RGB to YUV conversion.

[LigH]

If you have an ffmpeg with included libx265, you may not need to pipe to a separate x265 encoder, not even create a raw *.h265 video first. But anyway, remultiplexing to a complete MP4 container using MP4Box or L-SMASH is still recommendable, I am not sure how complete the MP4 container created by ffmpeg is (it used to be adversely arranged, due to its "filter" / FIFO behaviour: attributes only known at the end of the conversion have to be written to the end of the output).

[benwaggoner]

Alright surami.

Basically What I need now is the smallest high bitdepth Image file that After Effects will render the fastest.
Cineform RGBA 12bit is smaller that PNG 16bit?
I would stay away from an RGBA codec if at all possible, since that'll force another two color transforms. I'd want to render in 32-bit float to a YUV color space. There's no reason not to render to 10-bit if you're already in PQ space with 2020 primaries. You only need 12-bit if targeting Rec. 2020 12-bit HDR. Note both 12-bit 2020 and HDR-10 require non-gamma luma curves, and I'm not sure how to get the Adobe products to do those natively.

Looking at what Adobe Media Encoder supports, high quality options include:

DNxHR
Cineform YUV 10-bit
JPEG 2000 MXF OP1a YUV 4:2:2 10-bit


Blackmagic v210 certainly works as well, although is huge.

If you can get native OpenEXR to work as you describe, with the correct luma curve, that seems pretty optimal to me.

In practice, the best HDR-10 mezz format is likely a high quality HEVC, as that's the only bitstream format that can include all the HDR-10 metadata, including MaxFALL and MaxCLL. And it can do chromaloc 2, if you can find a tool that'll actually do the 0.25 pel chroma sample vertical offset. That might require a whole new color space format in ffmpeg.

[Magik Mark]

Guys,

Can you help me with my ghost problem. Maybe a missing switch? Doing x265 10bit 2pass via staxrip

http://s32.postimg.org/nr161hk4h/Capture.jpg (http://postimg.org/image/nr161hk4h/)

[fauxreaper]

Guys,

Can you help me with my ghost problem. Maybe a missing switch? Doing x265 10bit 2pass via staxrip

http://s32.postimg.org/nr161hk4h/Capture.jpg (http://postimg.org/image/nr161hk4h/)

There is some discussion about this in https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when.

[Magik Mark]

There is some discussion about this in https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when.

This one is happening using 2pass. I didn't have this problem before. I think it may have something to do with some switches being change when x265 was updated.

I'm comparing my encodes with others, the only difference that I could see right now are bitrate and "tune->grain". I'm inclined it may have something to do with the latter. Maybe the developers can take a look at it.

[Jamaika]

I read somewhere that ffmpeg treats RGB as 601 so this conversion has to occur for the colors to be right in 709.
I am surprised by this limitation. How to cut off the gamut colors to the BT601 isn't regain it when converting to BT2020.
http://www.earthboundlight.com/phototips/in-camera-color-space-for-raw-shooters.html
http://www.laserfocusworld.com/content/dam/lfw/print-articles/2014/04/1404LFW06f3.jpg
PS It also means that the software isn't for this conversion.):

[Ma]

Can you help me with my ghost problem.

You can try --no-cutree option.

[Magik Mark]

You can try --no-cutree option.

"Tune->Grain" --no-cutree has been activated. Still "Ghosting"

x265 1.9+147-19cced21060f:[Windows][GCC 6.1.0][64 bit] 10bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / 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=20 / lookahead-slices=6 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=0 / qg-size=64 / aq-strength=0.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / no-cutree / no-intra-refresh / rc=2 / pass / bitrate=1483 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=1 / cplxblur=20.0 / qblur=0.5 / ipratio=1.10 / pbratio=1.00

[LigH]

x265 1.9+150-00ea3784bd36 (https://www.mediafire.com/download/5td3190cir9dbbe/x265_1.9+150-00ea3784bd36.7z): Unicode filenames support for output and stats; and some rate control improvements

[Magik Mark]

x265 1.9+150-00ea3784bd36 (https://www.mediafire.com/download/5td3190cir9dbbe/x265_1.9+150-00ea3784bd36.7z): Unicode filenames support for output and stats; and some rate control improvements



Ghosting has been addressed?

[LigH]

My post was not a reply to your post.

Ah, by the way: Your x265 was compiled with GCC 6.1.0; this new version has different defaults, I would not be surprised if x265 did not yet ensure to be still compatible. May or may not be related to your ghosting sample. Anyway, if the reason was already found, I guess we would have read about a fix. But not in the last 10 commits.

[littlepox]

I don't think there is an easy solution to the ghosting effect; it is not a single bug, but symptom resulted from the entire RC scheme of x265, which heavily relies on comprehensive macroblock-based temporal prediction and strong psy tuning.

We might need to see tons of "RC improvements" before we get it done, with some sacrifice in other aspects.

[hajj_3]

a new VP9 encoder called Eve is out, it claims to be much better than x264, no info about how it compares to x265, thought you guys would be interested: https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/

[Magik Mark]

My post was not a reply to your post.

Ah, by the way: Your x265 was compiled with GCC 6.1.0; this new version has different defaults, I would not be surprised if x265 did not yet ensure to be still compatible. May or may not be related to your ghosting sample. Anyway, if the reason was already found, I guess we would have read about a fix. But not in the last 10 commits.

What I did right now is turned off "Tune->Grain" then activate --no-cutree option. So far it's looking good.

This started happening during the last 3-4 update of x265. I do not now if staxrip has messed up the switches or it's a new bug in the encoder

[Atak_Snajpera]

a new VP9 encoder called Eve is out, it claims to be much better than x264, no info about how it compares to x265, thought you guys would be interested: https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/

How many times I heard that some codec was suppose to be better than x264 ;) Even x265 in some situations looks worse than x264.
Most users here already know than PSNR and SSIM values mean nothing for perceived quality.

[mastrboy]

How many times I heard that some codec was suppose to be better than x264 ;) Even x265 in some situations looks worse than x264.
Most users here already know than PSNR and SSIM values mean nothing for perceived quality.

Have to agree here, x265 slightly beats x264 on low bitrates, but x264 is still the champ in medium/high bitrate encodes.
All other codecs seems visually soft/blurred compared to x264.

[LigH]

Well, you might have heard of the 100th birthday of Claude Shannon. His work is not completely unrelated, even though people may argue that it is more related to lossless compression. The concept of an entropy as threshold of information may be rather soft than hard in case of lossy compression. Still, you will have to sacrifice details for a convenient remaining quality, and even though you can optimize the choice which kind of loss is how annoying, there will always be objective loss, and there will always be different people with different opinions how annoying this loss feels to each of them.

Brief: Don't expect miracles about a matter of taste.

[Magik Mark]

x265 1.9+150-00ea3784bd36 (https://www.mediafire.com/download/5td3190cir9dbbe/x265_1.9+150-00ea3784bd36.7z): Unicode filenames support for output and stats; and some rate control improvements



I could confirm that encoding fps is a lot stable

I could further confirm that at least on my part that, --rc grain causes ghosting sporadically. Turning this off fixes it

[nandaku2]

I could confirm that encoding fps is a lot stable

I could further confirm that at least on my part that, --rc grain causes ghosting sporadically. Turning this off fixes it

We just found a bug with tune grain and 2-pass. Fixing.

[Magik Mark]

We just found a bug with tune grain and 2-pass. Fixing.



Thanks a lot!

[Motenai Yoda]

If the chroma qp offsets are decreased a bit when psy-rd and psy-rdoq are used, as x264 do, will be nice

[littlepox]

If the chroma qp offsets are decreased a bit when psy-rd and psy-rdoq are used, as x264 do, will be nice

Agreed. We've seen some cases for anime, where the colored edges are sharp, and x265 produce some chroma edge ringing/haloing.

Setting the two offsets to be ~-2 alleviates the problem.

[gamebox]

Some unrelated questions :)

- is some sort of Trellis quantisation step planned for x265? Is it missing for the time being only because it is not (yet) coded?

- can someone explain to me what --sao-non-deblock does? The encode I'm doing right now using this switch seems sharper than previous ones, but I changed other options too (AQ/RD strength). Sharpness I see also comes with more ringing/blocking noise, primarily around strong (high contrast) edges - it is (visually) much closer to x264, so SAO seems suppressed. Deblock is set to -1 -1, both for this encode and the one I did before without this switch

- does --no-strong-intra-smoothing work only on 64px CTUs - I enabled it for an encode limited to 32px CTUs, but it seems ignored by encoder

Thanks in advance, and keep up the great work :)

[eclipse98]

Hi Everybody,

I am getting some bad "color bleeding", that's what I think it is but I think a more accurate description is "color trailing". It gets pretty bad and mostly occurring when the object that leaves the color trail (car, road sign) passes in front of bare trees or dry grass.

Original footage is UHD, Sony AX53 Handycam, XAVC 100mbps shot from moving car (camera mounted outside) - resized to HD and encoded with x265 5mbps very slow preset (StaxRip, HEVC encoder version 1.9+150-00ea3784bd36). I tried different presets (medium-very slow) and problem occurs in each of them. It seems a bit better with SSIM tune, but still clearly present.

Attached is zoomed in image where a trail of blue/purple spots left by passing car can be clearly seen:
https://drive.google.com/open?id=0B8kqMOSsi4R-SElnSzBBNkV2NXc

Tested with h264 and it does not have the same problem.

Link to shared folder that has screenshot from original footage (no spots), h264 video, x265 video and zoomed in x265 version:
https://drive.google.com/folderview?id=0B8kqMOSsi4R-ZFFGQ0xFdkp1VGs&usp=sharing

Would appreciate your help if there is any setting I can try that might help with getting rid of this issue.

Thanks for your help, Cheers !

[Jamaika]

Hi elipse98
Maybe I shouldn't write, but also once had a problem with color XAVC.
Which did you use the decoder for codec H264?

Depending NLE editor may be different shades of decoding.
http://filmowiec.pl/forum/viewtopic.php?f=12&t=25255&start=195
Video Bitrate 5Mbps far too small for the dynamic films FullHD.

It is worth remembering about parameters XAVC.
Color primaries : BT.709
Transfer characteristics : IEC 61966-2-4
Matrix coefficients : BT.709

[eclipse98]

Hi elipse98
Maybe I shouldn't write, but also once had a problem with color XAVC.
Which did you use the decoder for codec H264?

Depending NLE editor may be different shades of decoding.
http://filmowiec.pl/forum/viewtopic.php?f=12&t=25255&start=195
Video Bitrate 5Mbps far too small for the dynamic films FullHD.

It is worth remembering about parameters XAVC.
Color primaries : BT.709
Transfer characteristics : IEC 61966-2-4
Matrix coefficients : BT.709

Hi Jamaika,

I am not using any NLE editor, pretty much loading source XAVC video directly with StaxRip and choosing Automatic AviSynth+ filter, it picks LSMASHVideoSource, can this be an issue ? Do you think if I convert XAVC with some intermediate codec (Avid) it might help ?

For 264 I am using x264 r2692 8-Bit x64 'very slow' profile, 2 pass encoding using StaxRip (same LSMASHVideoSource filter, same 5mbps bit rate).

Yes, 5mbps is on low side, but this is a requirement for streaming, so not much choice here, it is accepted that I am not shooting for BD quality.

I would not necessarily call it far too small either, the reason I am using x265 is because it excels at low bit rate compared to x264. I made some incredible x265 encodes at 5mbps (same type of dynamic footage) - overall very happy until this problem appeared.

I uploaded a very short video to shared folder where you can see trailing color problem - I am not sure if it's a color issue - as you can see in the video the bushes in front of the car do not exhibit any artifacts, but you can clearly see them behind the car :(

Thanks for your help !

[fauxreaper]

Hi Everybody,

I am getting some bad "color bleeding", that's what I think it is but I think a more accurate description is "color trailing". It gets pretty bad and mostly occurring when the object that leaves the color trail (car, road sign) passes in front of bare trees or dry grass.

Original footage is UHD, Sony AX53 Handycam, XAVC 100mbps shot from moving car (camera mounted outside) - resized to HD and encoded with x265 5mbps very slow preset (StaxRip, HEVC encoder version 1.9+150-00ea3784bd36). I tried different presets (medium-very slow) and problem occurs in each of them. It seems a bit better with SSIM tune, but still clearly present.

Attached is zoomed in image where a trail of blue/purple spots left by passing car can be clearly seen:
https://lh5.googleusercontent.com/RwLLOJuFPWELc0-YsswBN0MCpkDyTf4vnulzVCNoLkqlYMzmvJsOzCKSs_hSSYOAHYTeMw=w1896-h873

Tested with h264 and it does not have the same problem.

Link to shared folder that has screenshot from original footage (no spots), h264 video, x265 video and zoomed in x265 version:
https://drive.google.com/folderview?id=0B8kqMOSsi4R-ZFFGQ0xFdkp1VGs&usp=sharing

Would appreciate your help if there is any setting I can try that might help with getting rid of this issue.

Thanks for your help, Cheers !

Can you test a x265 encode with "--no-cutree" option? Maybe these spots are just ghosting.

[eclipse98]

Can you test a x265 encode with "--no-cutree" option? Maybe these spots are just ghosting.

Fauxreaper,

"--no-cutree" made it much worse, more spots and now they are glowing with every color of the rainbow :(

Here are encode settings:

x265 [info]: HEVC encoder version 1.9+150-00ea3784bd36
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX LZCNT
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(17 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 : 25 / 250 / 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 : 4 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 0
x265 [info]: Rate Control / qCompress : ABR-5336 kbps / 0.60
x265 [info]: tools: rect limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: signhide tmvp strong-intra-smoothing lslices=4 deblock sao
x265 [info]: tools: stats-read

[Ma]

"--no-cutree" made it much worse

You can try '--cbqpoffs -2 --crqpoffs -2'.

[eclipse98]

You can try '--cbqpoffs -2 --crqpoffs -2'.

Ma, slightly better, maybe 20% or so, but still persists. I tried '--cbqpoffs -4 --crqpoffs -4' and it returned back to original. You think experimenting with different values might yield some improvements ?

Thanks !

[Ma]

Ma, slightly better, maybe 20% or so, but still persists. I tried '--cbqpoffs -4 --crqpoffs -4' and it returned back to original. You think experimenting with different values might yield some improvements ?

You can try -1 or -3 values. You can also try '--aq-mode 3' option.

[Jamaika]

Hi Jamaika,

I uploaded a very short video to shared folder where you can see trailing color problem - I am not sure if it's a color issue - as you can see in the video the bushes in front of the car do not exhibit any artifacts, but you can clearly see them behind the car :(
Add the original.

PS These are the ghosts. On my decoder MPC-BE the spots of color they are in other places.

[Ma]

For volunteers I have x265 build with Unicode support for input files to test (yuv and y4m) -- www.msystem.waw.pl/x265/utf-input.7z (diff file in archive)

Example (from Total Commander):x265.exe "żółć-liść-będąc-23甜蜜的一天(玛丽亚.凯丽&男人男孩).y4m" -o o.hevc

[eclipse98]

Add the original.

PS These are the ghosts. On my decoder MPC-BE the spots of color they are in other places.

Screenshots were taken from different encode, that is probably why spots of color are in different places.

I uploaded a 90 sec segment of original video (original.mp4, XAVC, 100mbps) as well as new encode from this segment (x265.mp4, slow preset, 3 pass, 5mbps). You can see color ghosts left by car at 0:13, 0:18, 0:35, 0:44, 0:57. By road signs at 01:20 (on left), 1:34 and 1:44 (on the right). None of those artifacts exist in original video.

https://drive.google.com/folderview?id=0B8kqMOSsi4R-ZFFGQ0xFdkp1VGs&usp=sharing

So, is it possible to get rid of them ?

Thanks !

btw. Sorry to hijack the thread, I thought it was relevant to x265 as a possible issue. If you think otherwise please let me know and I'll start a new thread specific to this issue.

[Motenai Yoda]

try raising qcomp to .75~.8 and cbqpoffs/crqpoffs to -2

[eclipse98]

try raising qcomp to .75~.8 and cbqpoffs/crqpoffs to -2

--bitrate 5000 --preset slow --qcomp 0.75 --cbqpoffs -2 --crqpoffs -2

Doesn't seem to make any difference.

You can try -1 or -3 values. You can also try '--aq-mode 3' option.

Tried different values and aq-mode 3, didn't work either :(

[Jamaika]

The problems are with the SAO.

My attempt to film processing:
https://www.sendspace.com/filegroup/W3SSQSOzcOkRC8NxqCCdQ7wn9gLOXuaRRNvFBAzseMl5hp8ABy05nGTfmeml27dD1IzOnJ%2BKKrwlMCB35dd9o%2FHCHZGW5y0sHsm9MM%2BGPqwyShIA369DbjYPMLX4LFOt

[eclipse98]

The problems are with the SAO.

My attempt to film processing:
https://www.sendspace.com/filegroup/W3SSQSOzcOkRC8NxqCCdQ7wn9gLOXuaRRNvFBAzseMl5hp8ABy05nGTfmeml27dD1IzOnJ%2BKKrwlMCB35dd9o%2FHCHZGW5y0sHsm9MM%2BGPqwyShIA369DbjYPMLX4LFOt

Jamaika,

Thank you so much for testing this, appreciate it. I am looking at your settings and will replicate them in my tests. In addition to no-sao, I see other settings that differ from mine - you also use a different scaler (Lanczos vs Bicubic), not sure if it makes any difference.

I'll update once I have some test results !

Cheers !

[x265_Project]

Some patches were just committed that address some of the issues reported here... especially with respect to tune grain. We look forward to your feedback.

[ndkamal]

I made some tests with x265 V19 R165 and tune grain, and the result is really impressive. This version retains more grain than x264 (at equivalent bitrate). Very good job. I hope there will be a significant progress in normal mode (without tune grain), in the next months.

[Magik Mark]

I made some tests with x265 V19 R165 and tune grain, and the result is really impressive. This version retains more grain than x264 (at equivalent bitrate). Very good job. I hope there will be a significant progress in normal mode (without tune grain), in the next months.



Can you post a before & after image? Thanks

[nandaku2]

Guys,

Can you help me with my ghost problem. Maybe a missing switch? Doing x265 10bit 2pass via staxrip

http://s32.postimg.org/nr161hk4h/Capture.jpg (http://postimg.org/image/nr161hk4h/)

Hi, is this clip a grainy one (heavy film grain, ie)? If so, you may want to check with the new tune grain setting.

[Jamaika]

The problem hasn't been solved.
To test, I used material from the drone. Cloudy sky, the sun's rays reflecting in the water. At some point drone changes its position and is another angle of sunlight. And here curiosity. Where are the frames B all is well. Next frame "I" and there are violets.
Excision of extra functions give nothing "--no-amp --no-temporal-mvp --no-signhide --no-strong-intra-smoothing --no-b-intros". The use of "open-gop" also doesn't give results.
As for the focus. It seems to me that better falls x264. There is no pulsation between sharp and blurred places between frames.

PS I realize that we are talking about cheap cameras with poor optics.

Edit: It isn't satisfied with the settings tune grain.
https://github.com/videolan/x265/commit/69bb8ea79f7db1ed6c35216ad399b95f2e37d46f
First, I have problems with:
*: Option: `--aq-mode` 0
*: Option: `--cutree` 0
*: Option: `--qpstep` 1
Here there are large pixels.
I don't know what's going on with recursion-skip` 1. The inclusion doesn't improve quality. For me it is worse.
Settings:
*: Option: `--sao` 0
*: Option: `--psy-rd` 4.0
*: Option: `--psy-rdoq` 10.0
They are better than mine --psy-rd` 2.0 --psy-rdoq` 50.0
Use of me = umh causes more blemishes. Therefore, the above badly written.
The advertised the function 'lanczos' is bullshit. How would I not configured and so is the 'bicubic'.
My best settings for version 1.9 + 167 (veryslow):
--psy-rd 4.00 --psy-rdoq 10.00 --no-sao --high-tier --no-recursion-skip --keyint 60 --bitrate 6000 --vbv-bufsize 10000 --vbv-maxrate 10000
PS These settings in version 1.9 + 168 already look worse for the same film.
https://www.sendspace.com/file/inmvs6

[LigH]

x265 1.9+167-bebae72f9db7 (http://www.mediafire.com/download/6i1cizeppw4191t/x265_1.9+167-bebae72f9db7.7z) provides a few changes regarding the grain handling, and a new tweak:

--[no-]recursion-skip Enable early exit from recursion. Default enabled