x265 HEVC Encoder

[Atak_Snajpera]

Maybe you would prefer avs4x265 instead. It reads most clip attributes from the script and generates the full x265 command line internally. Shorter command line to type for you.
It is not a problem for me because whole command line is generated automatically by my gui ;) The question remains why x265 can't encode single frame like x264?

[kolak]

source/filters/filters.cpp:27
/* The dithering algorithm is based on Sierra-2-4A error diffusion. */

a.k.a. "Filter Lite" (http://www.algorytm.org/przetwarzanie-obrazow/algorytm-sierra-2-4a-filter-lite.html) — very simple and fast-computing; discussed before (http://forum.doom9.org/showthread.php?t=166368).

Thanks. So it's quite decent one and I assume taken from x264 code.

[Atak_Snajpera]

Bug report

--seek switch does not work. I've discovered that while testing x265 in my Distributed Encoding Mode

Log from first chunk

Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\1.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1343 --sar 1:1 --y4m --seek 0 --output "\\XEON-PC\RipBot264temp\job1\Chunks\1.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide
\\XEON-PC\RipBot264temp\job1\Chunks\1.avs: 624x464, 24000/1001 fps, 1343 frames

encoded 1343 frames in 132.88s (10.11 fps), 845 kbps

x265 [info]: frame I: 12 Avg QP:18.33 kb/s: 2804.80
x265 [info]: frame P: 418 Avg QP:21.51 kb/s: 1271.64
x265 [info]: frame B: 913 Avg QP:23.67 kb/s: 624.67
x265 [info]: global : 1343 Avg QP:22.95 kb/s: 845.51
x265 [info]: Weighted P-Frames: Y:0.7% UV:0.7%
x265 [info]: consecutive B-frames: 12.6% 7.7% 46.3% 21.9% 11.6%


Second chunk
Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\2.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1517 --sar 1:1 --y4m --seek 36 --output "\\XEON-PC\RipBot264temp\job1\Chunks\2.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide

encoded 1517 frames in 153.57s (9.88 fps), 1546 kbps

x265 [info]: frame I: 15 Avg QP:19.53 kb/s: 4746.50
x265 [info]: frame P: 424 Avg QP:22.39 kb/s: 2303.27
x265 [info]: frame B: 1078 Avg QP:24.35 kb/s: 1203.73
x265 [info]: global : 1517 Avg QP:23.75 kb/s: 1546.08
x265 [info]: Weighted P-Frames: Y:2.4% UV:2.1%
x265 [info]: consecutive B-frames: 7.7% 8.0% 26.7% 46.2% 11.4%
\\XEON-PC\RipBot264temp\job1\Chunks\2.avs: 624x464, 24000/1001 fps, 1553 frames
error: wrote only 432729 of 434304 bytes


Third Chunk
Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\3.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1379 --sar 1:1 --y4m --seek 82 --output "\\XEON-PC\RipBot264temp\job1\Chunks\3.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide

encoded 1379 frames in 144.78s (9.52 fps), 1240 kbps

x265 [info]: frame I: 20 Avg QP:19.26 kb/s: 4148.72
x265 [info]: frame P: 392 Avg QP:22.28 kb/s: 1951.58
x265 [info]: frame B: 967 Avg QP:24.43 kb/s: 892.26
x265 [info]: global : 1379 Avg QP:23.74 kb/s: 1240.61
x265 [info]: Weighted P-Frames: Y:0.8% UV:0.8%
x265 [info]: consecutive B-frames: 9.7% 7.8% 35.9% 31.3% 15.3%
\\XEON-PC\RipBot264temp\job1\Chunks\3.avs: 624x464, 24000/1001 fps, 1461 frames
error: wrote only 433254 of 434304 bytes


And last one

Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\4.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1566 --sar 1:1 --y4m --seek 24 --output "\\XEON-PC\RipBot264temp\job1\Chunks\4.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide

encoded 1566 frames in 157.09s (9.97 fps), 1685 kbps

x265 [info]: frame I: 15 Avg QP:18.92 kb/s: 3843.35
x265 [info]: frame P: 465 Avg QP:23.10 kb/s: 2284.15
x265 [info]: frame B: 1086 Avg QP:24.68 kb/s: 1400.03
x265 [info]: global : 1566 Avg QP:24.15 kb/s: 1685.96
x265 [info]: Weighted P-Frames: Y:19.8% UV:18.7%
x265 [info]: consecutive B-frames: 8.5% 14.0% 26.7% 44.4% 6.5%
\\XEON-PC\RipBot264temp\job1\Chunks\4.avs: 624x464, 24000/1001 fps, 1590 frames
error: wrote only 433252 of 434304 bytes



Error message at the end clearly shows that seek switch didn't discard those frames. Result repeated sequence at joined chunks.

I need working --seek switch in order to discard any corrupted frames caused by still buggy FFmpegSource()

[LigH]

@ Atak_Snajpera:

I have only a 32-bit OS available right now. But my just built x265 v1.0+21 was able to encode only one frame; just my script was based on ColorBarsHD.

avs2yuv.exe FullHD_1f.avs -o - | x265 --bitrate 128 --fps 1 --frames 1 --sar 1:1 --preset veryslow --y4m -o FullHD_1f.hevc -
FullHD_1f.avs: 1920x1080, 1 fps, 1 frames
y4m [info]: 1920x1080 fps 1000/1000 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+21-8963bc3aa2e1
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x265 [info]: WPP streams / pool / frames : 17 / 2 / 1
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-128 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 lft sao-lcu signhide
x265 [info]: frame I: 1 Avg QP:10.85 kb/s: 321.58
x265 [info]: global : 1 Avg QP:10.85 kb/s: 321.58
x265 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

encoded 1 frames in 9.89s (0.10 fps), 321.58 kb/s

FullHD_1f.avs:
ColorBarsHD(1920,1080)
AssumeFPS(1,1)
ConvertToYV12()
Trim(0,-1)
Info()

So maybe there is an issue in relation with ImageSource here? I'll try again with a PNG image as source.
__

P.S.: This works just as well for me. But it takes quite a long time to prepare the encoding.

avs2yuv.exe FullHD_1f.avs -o - | x265 --bitrate 128 --fps 1 --frames 1 --sar 1:1 --preset veryslow --y4m -o FullHD_1f.hevc -
FullHD_1f.avs: 1920x1080, 1 fps, 1 frames
y4m [info]: 1920x1080 fps 1000/1000 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+21-8963bc3aa2e1
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x265 [info]: WPP streams / pool / frames : 17 / 2 / 1
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-128 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 lft sao-lcu signhide
x265 [info]: frame I: 1 Avg QP:17.61 kb/s: 3320.82
x265 [info]: global : 1 Avg QP:17.61 kb/s: 3320.82
x265 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

encoded 1 frames in 19.97s (0.05 fps), 3320.82 kb/s

Encoded frame is playable in MPC-HC.

[Atak_Snajpera]

It is really weird

With this script (2 frames)

ImageSource("C:\Users\Dave\Desktop\Image compression test\1793814.png",1,2,1).ConvertToYV12(matrix="rec709")

x265 encodes 1 frame ;)

http://i.imgur.com/bHRAyQW.png

x264 for example correctly encoded 2 frames

http://i.imgur.com/guMx1DU.png

[nevcairiel]

With this script (2 frames)

ImageSource("C:\Users\Dave\Desktop\Image compression test\1793814.png",1,2,1).ConvertToYV12(matrix="rec709")

x265 encodes 1 frame ;)

Your commandline seems to include --frames 1, of course it encodes one frame. Everything else would be wrong. :)

[Atak_Snajpera]

Your commandline seems to include --frames 1, of course it encodes one frame. Everything else would be wrong. :)

You are right ofcourse in this example. My mistake.

How about this
ImageSource("C:\Users\Dave\Desktop\Image compression test\1793814.png",1,1,1).ConvertToYV12(matrix="rec709")

http://i.imgur.com/kDhTrkO.png

Script contains one frame. I tell x265 to also encode 1 frame but I get ZERO ;) Even If I remove --frame switch I still get 0.

For example this script
ImageSource("C:\Users\Dave\Desktop\Image compression test\1793814.png",1,2,1).ConvertToYV12(matrix="rec709")


is correctly encoded by x265

http://i.imgur.com/ZszYBVd.png

[zerowalker]

Here is a comparison from DeadSpace 2, just did a quick one as i wanted to try out 10bit in x264/x265 with dark gradients and higher details etc.
And the results are less than i actually expected, i thought the gain would be a bit more for x265, but it still loses till i get down to less than 1mbps.

As before, nothing to purely judge, just a quick one for you to see how it handles at dark with the advantages 10bit gains (x265 was done in 16bit but the output is 10bit).

http://i58.tinypic.com/5bqt60.png
http://i61.tinypic.com/xcknyd.png


BTW, is it possible to make the images less in size on the forum, and make it clickable to resize it to it's original?
As it wastes so much space, probably bothersome to most people.

[Atak_Snajpera]

And how many fps did you get on x264 and x265 during encoding?

[zerowalker]

17.97 fps on x264 10 bit.
2.28 fps on x265 16bit - 10bit output.

both default settings, except CRF.

[Atak_Snajpera]

lol x264 is ~8 times faster and quality is still more or less the same? x265 realy likes to waste cpu cycles and electricity ;)

[zerowalker]

Can't disagree, must be quite some optimization that has to be done, would like to get hold of the first public release of x264 to compare it with, just to see the evolution.

What bothers me most with x265 however, is the filtering it's doing, killing details is one thing, but the "haloing/ringing" effect is something that's frustrating at low bitrates.
Even if it looks alot better than x264 at those bitrates, the ringing gives of a, plastic unreal feeling.

But probably one of the least prioritized things on the list as it only occurs in those cases, at least as far as i have noticed.

[easyfab]

Zerowalker,

Here a freenode-x265.log extract for you:

2014-05-07 18:54:51 < Daemon404> im sitll having issues with detail retention at mid-to-high bitrate
2014-05-07 18:54:53 < Daemon404> or well
2014-05-07 18:54:56 < Daemon404> "detail"
2014-05-07 18:54:59 < Daemon404> since it is psy after all
2014-05-07 18:55:44 < muggs> yeah, this is tops on my list right now; since we've finally fixed the all the known bugs in analysis (that cost wrap problem was a bitch)
2014-05-07 18:56:10 < Daemon404> cool

[Sagittaire]

lol x264 is ~8 times faster and quality is still more or less the same? x265 realy likes to waste cpu cycles and electricity ;)

Well it's completely false. x265 produce really better quality than x264 at same bitrate in most case. You can certainely find some example to condradict that but for "real life case" x265 produce better result than x264 and by far and it's really simple to prove that ... lol

[LigH]

Exceptions are some known issues with psychovisual features, which are being fixed. Patience and trust. Developers are only humans, too.

[zerowalker]

easyfab,

did you mean that he has high priority of it?
Cause if so, i think that isn't the thing i meant, which is "ringing".

But then again, detail retention may actually go hand i hand, solving that will perhaps reduce the other.
Good news anyhow:)

Sagittaire,

Actually can't agree with you there.
In my tests, x264 wins pretty much all the time against x265, Except at very low bitrates.
When you reach the "medium", like 4k for 1080p, x265 will force filtering on much of the thing causing a blurry mess, while x264 will look blocky, but will retain a lot more detail.

So well, x265 win in a "silky" look, but i can't say that's realistically comparable to the original, but it does look good at some occasions where x264 "blocky mess" misplaces to much data and just appears as artifacts rather than an actual shape.

[Romario]

Can you, x265_project, add support for *.MPEG input and *. AVI input in x265 encoder, please ?

I find that Y4M format is very strange...and I don't like it, to be quite honest. Thank you.


X265 should be developed in much faster developing rate, for me x265 is not ideal, at the moment. Lack of details is evident, unfortunanely.


Can you predict when will be x265 on par(in quality terms) with x264 ? End this year, next year ?

[Atak_Snajpera]

Most likely next year. Y4M is fine. With avs2yuv you can import any format.

[LigH]

And avs4x265 will simplify the piping of AviSynth scripts even more.

Finishing the encoder core will certainly be preferred over adding interface features (like including libav libraries to read media files on its own).

Fixing the lack of detail preservation has been discussed during the last months. It is known, and it is being developed.

[LoRd_MuldeR]

Can you, x265_project, add support for *.MPEG input and *. AVI input in x265 encoder, please ?

I find that Y4M format is very strange...and I don't like it, to be quite honest. Thank you.

Y4M is nothing but "raw" YUV data with a minimalist header. So it's the format in which your input video data will end up anyway, regardless of how you feed it into the encoder.

As others have suggested, you can use avs2yuv or vspipe to feed current x265 directly from Avisynth or VapourSynth, respectively - which means you can load pretty much any video format in existence.

And if you don't want to do this manually, just use a GUI (https://forum.doom9.org/showthread.php?t=144140) which can accomplish this task more conveniently ;)


Also keep in mind that x265 is an encoder library, which takes "raw" YUV data as input and returns compressed H.265 data, not a fully-fledged video processing application. The same way x264 is an encoder library that takes "raw" YUV data and returns compressed H.264 data. Decoding the input video format to "raw" YUV before feeding it into the encoder library is the job of the calling application. Consequently, in case of x264, support for handling various types of input video formats is not implemented in the x264 "core" library, but in the x264 CLI front-end. Other front-ends exist, such as FFmpeg, Avidemux, etc. And, indeed, FFmpeg already does support x265 too! Look here (http://ffmpeg.zeranoe.com/builds/) for FFmpeg builds that have x265 support enabled.

[zerowalker]

X265 should be developed in much faster developing rate, for me x265 is not ideal, at the moment. Lack of details is evident, unfortunanely.


Not sure if you mean it Should develop faster, as in for some reason, or if you want it to.

However, if i am not entirely mistaken, x265 can use many features from x264, they just need to redevelop them or something.

And if that's the case, the evolution should go faster compared to x264 which didn't have anything to go with so everything was created from scratch, or at least most of it.

[foxyshadis]

Well, a very experimental psy-rd test patch (https://mailman.videolan.org/pipermail/x265-devel/2014-May/004371.html) was just posted to the mailing list, so I figured I'd make a build. It's incomplete, but hey, it's something. I still haven't had a chance to test it, so beware of dragons.

x265 1.0+38+psy-rd: 16bit (https://www.dropbox.com/sh/6mjj0iuzuatfllt/AACkf-Rjv3ZiJuX11uOJggAKa/x265-1.0-r38-psyrd.exe) - 8bit (https://www.dropbox.com/sh/6mjj0iuzuatfllt/AACkf-Rjv3ZiJuX11uOJggAKa/x265-1.0-r38-psyrd-8bit.exe) - Symbols (https://www.dropbox.com/sh/6mjj0iuzuatfllt/AABoi_Fgq7CevwnRHCy-sb_Ka), all x64 only. Requires VC2013 Runtime (https://www.microsoft.com/en-us/download/details.aspx?id=40784).

x264's default is --psy-rd 1.0 --aq-strength 1.2, while --tune stillimage is --psy-rd 2.0 --aq-strength 1.2 and --tune animation is --psy-rd 0.4 --aq-strength 0.6, for what it's worth. Might be good starting points.

[xooyoozoo]

Maybe it's just me, but I had to replace "psy-rd" with "psyrd" in the patch. Otherwise, the command line would complain whenever I try to change psyrd values from default 1.0.

I didn't save any shots from tests, but the effect so far is on the subtle end. Bad(?) news is that, at CRF28 and default psy, I couldn't tell much of a difference while a clip is playing. Good news is that in still shots, I can see extra "noise" in the right spots, like on a dog's fur or around a sprinkler.

Personally, I wouldn't mind a conservative ramp up with x265's psy features, as long as it adapts to high QPs more gracefully that x264's psy.

[easyfab]

Maybe it's just me, but I had to replace "psy-rd" with "psyrd" in the patch. Otherwise, the command line would complain whenever I try to change psyrd values from default 1.0.

same here : x265 [error]: invalid argument: psy-rd = 1.5

Thanks for the trick

[Kurtnoise]

Maybe it's just me, but I had to replace "psy-rd" with "psyrd" in the patch.
There is a typo in this patch :

+ OPT("psyrd") p->psyRd = atof(value);

Should be :
+ OPT("psy-rd") p->psyRd = atof(value);

[zerowalker]

Tried the 8bit build, not sure if the patch works or not as you can't change the settings, so i guess it means it's just a normal 8 bit build?

However, i did a test with my DeadSpace clip, and compared 16-bit to 8-bit, and the 8-bit looked quite a lot better, which doesn't make sense to me, either something has happened since the 16-bit build, or something is wrong.
The 16-bit should clearly win at the same bitrate in this clip.

EDIT:

Here are links:

x265 8bit with psyrd patch (typo) (https://docs.google.com/uc?export=download&id=0B_UKJFH8rbiNcTZ0dWFjVl9jNE0)
x265 16bit (https://docs.google.com/uc?export=download&id=0B_UKJFH8rbiNLWtINkVEbjdTWWM)

[easyfab]

Tried the 8bit build, not sure if the patch works or not as you can't change the settings, so i guess it means it's just a normal 8 bit build?


With the patch, psy-rd is enable by default for me .

x265 [info]: tools: rect amp rd=4 psyrd=1.0 lft sao-lcu signhide

Make sure to have rd >= 4.

The change with this experimental psy-rd is really sublte for the moment but it does not matter, I only test it out of curiosity :)

[Atak_Snajpera]

In terms of threading x265 also needs fixing. This is a real problem with low res videos. In my example I used XviD 624x352 video clip. First part of the movie shows cpu usage with x264 --preset veryslow. Second part x265 --preset medium. In both cases I used latest x64 builds. In this test x264 has ~2.5 better cpu usage than x265. And please do not tell me that x265 is only for stupid 4k footage. UHD will never be as popular as lower res videos.

https://www.youtube.com/watch?v=rrghV1yqaTU&feature=youtu.be

[zerowalker]

With the patch, psy-rd is enable by default for me .

x265 [info]: tools: rect amp rd=4 psyrd=1.0 lft sao-lcu signhide

Make sure to have rd >= 4.

The change with this experimental psy-rd is really subtle for the moment but it does not matter, I only test it out of curiosity :)


So, by previous versions, psy-rd doesn't exist?
If i am not completely out, isn't this a quite useful feature that took awhile for x264 to implement?
Something about predicting details and making more subtle changes to the eyes, so it looks better than it really is?

can't change the rd(psyrd?) as the typo exists, so would need another version for that.

[LoRd_MuldeR]

In terms of threading x265 also needs fixing.

You may wish to read this:
http://x265.readthedocs.org/en/default/threading.html

I suppose the x265 developers will be interested in your ideas of how this can be further improved ;)

Also keep the following in mind:
https://forum.doom9.org/showpost.php?p=1655710&postcount=15

[Atak_Snajpera]

You may wish to read this:
http://x265.readthedocs.org/en/default/threading.html

I suppose the x265 developers will be interested in your ideas of how this can be further improved ;)

Also keep the following in mind:
https://forum.doom9.org/showpost.php?p=1655710&postcount=15

Interesting read. Thanks mulder. So now I see that encoding multiple chunks at once is really a necessity for those with multiple logical cores. In order to achieve max speed with x265 (CU 64) now I have to encode 2-3 chunks at the same time.

UPDATE:
Ok. With CU 16 I have constant 100% , with CU 32 ~75%


UPDATE2
According to my test
CU 64 with 3 chunks gives the fastest encoding speed ~41 fps (average for all chunks)
CU 32 with 2 chunks is noticeable slower ~35 fps
CU 16 with 1 chunk is the slowest ~30 fps (despite constant 100% usage)

[nevcairiel]

Smaller CTUs also increase the number of CTUs to process, so seeing slower speed at higher CPU usage is not entirely unexpected. On top of that, they also reduce compression efficiency.
But the docs and the animation explain it quite well. As smaller as the image gets, WPP gets less and less effective.

[foxyshadis]

There is a typo in this patch :

+ OPT("psyrd") p->psyRd = atof(value);

Should be :
+ OPT("psy-rd") p->psyRd = atof(value);
Thanks for pointing the problem out, I've rebuilt them and included the new patch in the folder as well. It actually did work fine with --psyrd x before, but better to have it right.

zerowalker: Yes, use --psy-rd 0.0 to compare to previous versions that don't have it at all, since 1.0 is now default. (Although you might want to sanity check, using a real previous version to see if the output is really the same.)

What psy-rd does is try to keep the noisiness of blocks as close as possible to the original, and weights matches based on that, instead of purely on coding cost. Dark Shikari wrote a bit about it (http://x264dev.multimedia.cx/archives/37) a while back.

[fumoffu]

Good to see psyrd finally in the works.
I did some tests and for now the difference and image quality is very very slight. Understandable considering that with psy-rd set to 1.0 the bitrate increased only about 1% while on the same sample while encoding with x264 bitrate increased almost 20% when changing psy-rd from 0.0 to 1.0
(witch is why I think the default 1.0 in x264 is a bit too high but that is another story)

btw. using --early-skip shouldn't interfere with psy-rd, right?

[LoRd_MuldeR]

I did some tests and for now the difference and image quality is very very slight. Understandable considering that with psy-rd set to 1.0 the bitrate increased only about 1% while on the same sample while encoding with x264 bitrate increased almost 20% when changing psy-rd from 0.0 to 1.0

If you compare the effect of Psy-RD with encodes of different file size (i.e. different bitrate), then your test is completely useless. You need to compare files of identical size (i.e. same bitrate). For example, if the encode with Psy-RD has better quality (compared to the encode without Psy-RD) but also comes out bigger, then you have learned exactly nothing! Of course spending more bits results in better quality. That's not surprising and doesn't required Psy-RD at all. You could just have increased the target bitrate. So, it's all about achieving better quality at the same bitrate (file size). Alternatively, you could also create encodes of the identical perceived quality and then compare the file sizes - but that is much more difficult to do!

Another important point to consider: Who says that a Psy-RD strength of 1.0 currently is a good choice? Or a good choice for your particular source? With such Psy optimizations, choosing a strength that is too low will not give the desired effect. But choosing a strength that is too high will produce annoying side effects. It's all about finding the "sweet spot". And this can vary quite a lot between different types of sources. So if you think that the effect is too subtle, try a higher strength!

[foxyshadis]

It doesn't seem to be very strong yet. The differences aren't as pronounced as x264; given that they're pretty different and HEVC allows much larger blocks I'm not all that surprised. I don't even know if it's complete, as in touching all decisions.

But there seems to be a bit of difference, and hey, that's what's important. I'll post some shots if I'm sure I'm not just imagining it.

Just test everything with 0.0 and 2.0, to see the most difference and whether it helps anything. I don't think that the 0.0-2.0 scale or 1.0 default will change, but I'm sure it'll be scaled as it's modified over time.

As Mulder says, you have to pick a size and stick to it when comparing anything, even if you normally only do things by crf; anything else introduces more unnecessary variable that you can't intuitively correct for.

[fumoffu]

Yes I definitely agree that generally you should compare things with the same size.
But for now I was just testing if the implementation works at all and how switching it on changes the image and file size.

[mandarinka]

Seems there is a new version on the ML: https://mailman.videolan.org/pipermail/x265-devel/2014-May/004389.html

[LigH]

Psy-RD adaption from x264, 2nd edition, Request For Comments ... rather looks like it may take a little more until it will be committed. Patience, Padawans.

[fumoffu]

Seems there is a new version on the ML: https://mailman.videolan.org/pipermail/x265-devel/2014-May/004389.html

can someone post updated build? pretty please ^-^

[LoRd_MuldeR]

can someone post updated build?

Here we go:
x265-PsyRD.win-x64-8bit.2014-05-14.rar (http://www.mediafire.com/download/zp7i1aw6tt7be61/x265-PsyRD.win-x64-8bit.2014-05-14.rar)

[zerowalker]

Is the build inside already patched?

[LoRd_MuldeR]

Is the build inside already patched?

Yes. Would be difficult to patch the binary afterwards :p

[foxyshadis]

Sure, no problem: 16bit (https://www.dropbox.com/sh/ezw6te74q6j6roa/AADI_iwQ76pryb5_OcuFbEi6a/x265-1.0%2B53-psyrd.exe) - 8bit (https://www.dropbox.com/sh/ezw6te74q6j6roa/AADYxCcnxYq_bfSez4TzXFjFa/x265-1.0%2B53-8bit-psyrd.exe) - Patch and unmodified builds (https://www.dropbox.com/sh/ezw6te74q6j6roa/AAB39l7YxLoXRIDRFbukN7Tca)

Edit: Haha, Mulder at the same time!

[zerowalker]

Well i tried the supplied build which was patched, and it looks identical with and without Psy-RD (0,1).

Not sure if i am doing something wrong.

[LoRd_MuldeR]

Well i tried the supplied build which was patched, and it looks identical with and without Psy-RD (0,1).

Not sure if i am doing something wrong.

As others have reported before, the effect of this patch seems to be rather subtle at the moment. But you can try to adjust the strength.

Furthermore, you need to be aware that Psy-RD only has an effect with RDO enabled.

Last but not least, if you actually want to see a difference, you'll need to pick a bitrate that is low enough: If the version without Psy-RD already looks "transparent" already, then there isn't much to gain!

(But of course the bitrate must not be too low either. If both versions just look like a mess, you won't be able to learn anything)

[zerowalker]

Is RDO enabled by default?

Cause i am talking Identical, precise the same in size and looks, so it doesn't even use it, so something must be wrong;S

[LoRd_MuldeR]

Is RDO enabled by default?

http://x265.readthedocs.org/en/default/cli.html#cmdoption--rd

So the default value is "--rd 3", which means that RDO is enabled by default.

But the higher you set it, the more exhaustive the RD analysis - and thus the more chances for Psy-RDO to kick in (in theory).

So you might want to add "--rd 6" to your command-line, just to be sure...

Cause i am talking Identical, precise the same in size and looks, so it doesn't even use it, so something must be wrong;S

I just applied the patch, as it was posted on the mailing list, to latest x265. And that's it.

The only test I made with that build is that it would encode "foreman" with default settings without crashing right away ;)

So I have no idea whether something is wrong or not :p

[zerowalker]

It seems to work with --rd 6, then the file size changes at least, psy-rd is quite larger than the other, even with both using --rd 6.
Not really sure how i should test the files though, should i try to get the same size, or simply compare how Psy-RD acts?

[LoRd_MuldeR]

Not really sure how i should test the files though, should i try to get the same size, or simply compare how Psy-RD acts?

See here:
https://forum.doom9.org/showpost.php?p=1680298&postcount=786