x265 HEVC Encoder

[nandaku2]

@ Selur + foxy:

That's why I halted my reply so far. I knew there are routines for Main (8 bit) and Main10 (10 bit) HEVC profiles. I am not sure if there are finer resolutions for internal encoding parameters mentioned in HEVC specs, I only heard about it in theory so far but couldn't remember any specific implementation (of course not in assembler, but not even in C), and I also wondered if this would be even another HEVC profile if "Main10" is already so specific in its name.

@ Ma + Atak:

It would be a pity if non-Microsoft builds would require Microsoft DLLs. And this is only a workaround for Windows; what would you have to substitute if there were a similar issue only with GCC builds on Linux, assuming there are also other Linux compilers? I would hope for a mostly compiler independent solution which will certainly require understanding of the reason. But I fear it may require severe efforts and background knowledge in thread-safe development. A reply from the team will be welcome.

Ma had identified the root cause of the issue on the issue tracker - fprintf is not thread safe as implemented on MingW. We will replace this with sprintf and fputs. POSIX requires stdio to be atomic, and MSVCRT file operations are also always thread safe. So, this problem is restricted to MingW afaik.

[LigH]

Weekly: x265 1.7+257-483c85f83f07 (https://www.mediafire.com/download/8903gq836zvpc8c/x265_1.7+257-483c85f83f07.7z) (as usual: MSYS/MinGW, GCC 4.8.2)

[hector1980]

hi i was wondering that what app is the best for encoding hevc x265 and offers more settings and abilities like for example what MEgui is doing for x264 i will appreciate if you could help me... tnq

[stax76]

hi i was wondering that what app is the best for encoding hevc x265 and offers more settings and abilities like for example what MEgui is doing for x264 i will appreciate if you could help me... tnq

StaxRip and Hybrid have a rich x265 GUI and generally many advanced options.

[mandarinka]

Hey, there are also completely confident users of "placebo" presets. If I ever want to top that, I'll call my custom preset "homeopathic" (= "placebo forte").

You know, at least in x264, placebo isn't really *placebo* at all. You can test it with metrics and it will give you better results than veryslow.

For example, --no-fast-pskip IIRC only gets used in preset placebo, and just that option has noticeable impact visually. Not saying you will spot it when playing back, but comparing stills I think it is fairly conclusive that it helps.

Not sure --me tesa helps much (and --subme 11 probably doesn't), but just going --preset placebo --me umh --subme 10 is going to be better than veryslow and I would recommend it when slower speed is not a problem.

(You can probably get some real improvement when going to parallel --threads 1 encodes over a single encode with automatic thread count on a machine with lots of cores and HT - say 36 threads on a 1280x720 video is probably fairly suboptimal. But that is beyond the scope of presets.)

[LigH]

If you know exactly why, then go on and use all the parameters you like. But if you believe that more efforts automatically mean more quality, then you are probably just wasting time and energy, and will enlarge your CO2 footprint. :rolleyes:

[kolak]

I doubt any 8-bit was at about the perceptual threshold, and sometimes not enough. For Rec. 709, 10-bit is ample.

Also, very little cel animation has been created at >10-bit anyway. Maybe a few films from the last decade, and recent remasters of old film sources.

Maybe if there is HDR animation some day, a 12-bit PQ curve would be better than 10-bit PQ. But I've never heard even a rumor of anyone even contemplating high dynamic range cel animation.

There are some animation based projects in progress from big boys and these are one of the first which may have special HDR version. Of course I can't say more. Dolby is working hard to push their HDR technology- not only for pro, but home market also.

[LigH]

"Merge with stable" and working CPU features identification for alternative encoder libraries (i.e. -D 10 -V warns about "noasm" option for Win32 builds in multilib EXE as well as 8-bit EXE with 10-bit DLL):

x265 1.7+266-68d089360477 (GCC 4.8.2) (https://www.mediafire.com/download/ykww46evv72k606/x265_1.7+266-68d089360477.GCC482.7z)
x265 1.7+266-68d089360477 (GCC 4.9.2) (https://www.mediafire.com/download/omxapjqcgoa2m2q/x265_1.7+266-68d089360477.GCC492.7z)

[ShamisOMally]

Shit, I got hyper distracted by IRL shit (Friends dying) I lost track of making the exports of raw footage for L4D2 for encode examples.

I'll do that in a few hours. Sorry guys!.

*EDIT* https://www.mediafire.com/?58huw703ap5o0c6 Fireworks scene in L4D2, probably one of the best sources I ever found for testing video compression quality

[LigH]

My condolences.

And thank you for the useful material. Game recordings are special.

[LigH]

12bit and 16bit encoding did work last time I tested it, only the asm optimizations weren't up-to-date,...

Meanwhile, some first patches to prepare a future 12-bit encoder implementation got submitted ... To me, they appear only like some sort of placeholders yet; but there is a beginning.

[ShamisOMally]

https://www.mediafire.com/?5o49wbitxjei681

Ok last raw file example, this one of Planetside 2

This is yet another game I find that if I encode it at the typical 7-8K bitrate that youtube puts out, it gets absolutely mangled quality wise

This and L4D2 seem to have the biggest issues when it comes to clarity and encoding bitrates vs other games

I hope you guys find these useful, both games I use in order to test stream settings/youtube encode settings for uploads

[dipje]

just as a quick-n-dirty test to see how it went, tried that Fireworks source ('source', 40mbps h264? From NVENC or something?) through x264.

Just a simple 'core.ffm2.Source' vapoursynth script into x264 8bit, crf 23 quickly ended up being 23mbps. (--preset slow --tune animation --crf 23).

Added a dirty 'anti alias' method (surely not perfect) to get rid of a bit of the extreme sharpness from captured game footage (although having 420-8bit-40mbps as source it probably lost a lot already).

nnedi3_rpow2 to scale up, sangnommod, transpose, sangnomod, transpose, bilinear size back to 1920x1080.

Encoding that into x264 (--preset slow --tune animation --crf 32) at _32_ CRF finally ended up being an average of 6mbps at the end and it's good watchable. I would not call it mangled at all, although in still frames it will probably show it's ugly face.
Doing a crf-30 now to see if that ends up being roughly at the 8mbps average 'challenge' point.

Challenging footage to be sure, I wonder what x265/hevc will make it of it at end. Will do some tests next.

[ShamisOMally]

Its from an ElgatoHD 60, and it actually handles L4D2 quite well at 40MBit

Planetside 2 however? Absolutely exhausts 40Mbit, just look at the sky and the macroblock artifacts banding between blue/purple. But then again, Blue/purple transition has been encodings achilles heel since day one.

You can easily spot it running out of bandwidth when you look through the night vision scope, the bands of macroblock errors in the purple/blue there.

Again these are the only two games I've ever had look less than perfect with the ElgatoHD 60, but you can see by the weirdly insane amount of random detailing on screen its no wonder why.

[LigH]

WARNING! HIGHLY EXPERIMENTAL!

By manually patching the file linklibs.rsp I was able to build x265 v1.7+282 not only as separate specific EXE and DLL files, but also as a multilib EXE (which is untested except for the point that it reports a meaningful version string) with 8 bit, 10 bit, and 12 bit encoders.

:scared: — :cool:

Now I wonder if I should release it at all...

[dipje]

I ended up with a simple --preset slow --tune animation --crf 30 for x264 with a filtered version of your source (filtered as I described early, upscale, sangnommod, rotate, sangnommod, rotate back, bilinear scale back to full-hd).
The videostream ended up being +/- 7600 kbps average at the end (crf is of course not comparable to the constant 8mbps Youtube probably does :)).

Not being up2date on current x265 settings and the like, took LigH's latest compile (1.7+266) with --preset slow --crf 26, nothing else on the command line. Videostream ended up being +/- 8700 kbps and to be honest, I think I enjoy the x264 version more. With the sudden jerky gameplay action they are both very watchable though.

Both handle the fireworks well and keep it pretty detailed / good in motion, but the bits spent on the fireworks mean detail is lost somewhere else. The other most important parts of gameplay footage I think are the HUD and the gun/item held in first person in front of the player. Both versions do fine. But I keep noticing that x264 manages to keep more 'detail' on the face of Coach around the 2-second mark (where he pulls / reloads his guns) while the x265 version has more noticeable blur there, even in high 60fps motion.

Like I said, I'm not up2date on the latest settings that are best for this kind of thing and the bitrates aren't matched very well, so this is NOT a fair shoot out or anything close :). But it does show that x265 has some problems with this footage that x264 does better. It's not about detail retention directly, both handle the fireworks well. But x265/hevc seems to have too little bits left over on some other parts. Well, it's CRF so it can use all the bits it wants. So x265/hevc seems to think the head of Coach at the early point is not detail worth saving or something.

[LigH]

With so little "bitrate per pixel and frame", both encoders need to suppress a lot of information. Which approach appears more or less annoying to you, is specific to you. But yes, it may depend on the material as well. You are probably right that the fireworks effect draws a lot of bitrate from the rest of the content. How much from where, will be the difference between AVC and HEVC in general already.
_

P.S.: New samples (https://www.mediafire.com/folder/ldwl20fppplbx/samples) with a downscaled "L4D2 Fireworks" clip (640x360) in 8 (https://www.mediafire.com/download/305tak1cu7uvdem/Fireworks_360_medium.hevc.mp4) / 10 (https://www.mediafire.com/download/biljcp8rc51p8rj/Fireworks_360_medium.10bit.hevc.mp4) / 12 (https://www.mediafire.com/download/xvx3ktu13d2b3lg/Fireworks_360_medium.12bit.hevc.mp4) bit encoding resolution.

LAV Filters can't play the 12 bit sample correctly. I guess it is not yet supported?

And here the experimental build: x265 1.7+282-1867f1703846 (https://www.mediafire.com/download/2d9kjgc5cbtx032/x265_1.7+282-1867f1703846.GCC492_EXP.7z) (GCC 4.9.2)

[ShamisOMally]

Yeah that's the same conclusion I keep coming to when I do my HEVC encodes, having since gone back to X264 for my own personal collection. Yeah its bigger but when it comes to things as fine detail AVC tends to keep fine details far better, even if HEVC on average is far smaller.

But like I saw like Dipje saw in order to do high motion scenes with insanely high amounts of detail HEVC needs a lot more bitrate to compensate, and still doesn't do as good a job.

The reason I remembered these two games and how they get butchered by encodings is from days ago with my Atlantis: The Last Empire findings a few days ago, where HEVC just destroyed the firefly scene. It only worked after I gave it an insanely high buffer to play with.

[qyot27]

I kind of wonder when the -strict -1 restrictions on encoding 4:2:2 or 4:4:4 with libx265 through FFmpeg will go away, since x265 CLI no longer throws the warning about it.

[nevcairiel]

I kind of wonder when the -strict -1 restrictions on encoding 4:2:2 or 4:4:4 with libx265 through FFmpeg will go away, since x265 CLI no longer throws the warning about it.

Should be able to remove it by now I would think. I'll inquire!

[Ma]

Ma Your earlier patch works fine so no need to mess with compiler options. x265 team should implement your workaround because without it gcc builds are semi broken. However it is iteresting why non gcc builds work fine...

The earlier patch is wrong because it change not buggy code.

We should patch code that is really buggy -- mingw-w64 stdio implementation (see attached diff file). With the newest patch all mingw printf functions (printf, vfprintf, fprintf, ...) are atomic and threads safe.

You can test sample x265 builds with patched mingw_pformat.c file (linked to old msvcrt.dll):
www.msystem.waw.pl/x265/test4-Atak.7z

[qyot27]

I kind of wonder when the -strict -1 restrictions on encoding 4:2:2 or 4:4:4 with libx265 through FFmpeg will go away, since x265 CLI no longer throws the warning about it.
I realize I made a slight typo. It's actually -strict -2 (experimental), not -strict -1. I was confusing it with the extended y4m restrictions when piping into x265.

Although the point that it's restricted at all still stands.

[Ma]

https://www.mediafire.com/?58huw703ap5o0c6 Fireworks scene in L4D2, probably one of the best sources I ever found for testing video compression quality

I encoded this sample to 12-bit HEVC with options:
--preset slower --crf 27.0 -D12 --no-asm --deblock -2

It is smaller (68.2 MB instead of 116 MB) and still watchable.

It looks like that without --no-asm option x265 12-bit encoding is pure crap.

[LigH]

Interesting. So the assembler routines for the encoder are probably not correct yet. I'll check that too and then mention it in the developer mailing list. Still ... a reference decoder or internal reconstruction will possibly be more reliable than usual players?

[foxyshadis]

Cool, no more need to make the dll on windows; the exe now exports the full library as well. (The commit message says to change the filename to do so, but LoadLibrary() doesn't care what it's named.)

[LigH]

In theory, it would be very convenient to have one "All In One" binary; in practice, I did not yet manage to build it. With v1.7+298, I still get either a DLL with export chapter, or an EXE without export chapter (at least Microsoft PE Scanner can't find any; PE Tools' readpe also reports: "export directory not found").

[foxyshadis]

It works for me, but I think you have to enable cli and shared (so the dll still gets built even though the exe has the exports).

[LigH]

I did so, even explicitly. PE Scanner (http://sourceforge.net/projects/pescanner/) detects "Export(fn)" (see bottom) only in the DLL, but not in the EXE. The tool "readpe" in pev (http://sourceforge.net/projects/pev/) logs the PE structure to stdout and reports several exports from the DLL (even though the names appear wrong) but prints "export directory not found" on stderr while analyzing the EXE.

I had to modify the sample script from the x265 project slightly: It did not care about a 32 bit build requiring to disable assembly for HBD libraries, and did not care about using the cross-compile toolchain for x64 target on x86 MSYS/MinGW32 either. In addition, I prefer to clean the project from generated files because I usually need to rebuild it completely.

multilib32.sh
#!/bin/sh

mkdir -p 8bit 10bit 12bit

cd 12bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DWINXP_SUPPORT=ON -DENABLE_ASSEMBLY=OFF -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main12.a

cd ../10bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DWINXP_SUPPORT=ON -DENABLE_ASSEMBLY=OFF -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main10.a

cd ../8bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DWINXP_SUPPORT=ON -DENABLE_ASSEMBLY=ON -DEXPORT_C_API=ON -DENABLE_SHARED=ON -DENABLE_CLI=ON -DHIGH_BIT_DEPTH=OFF\
-DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
make ${MAKEFLAGS}
# linebreak escape for forum layout saving only!

multilib64.sh
#!/bin/sh

mkdir -p 8bit 10bit 12bit

cd 12bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DCMAKE_TOOLCHAIN_FILE=../toolchain-x86_64-w64-mingw32.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main12.a

cd ../10bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DCMAKE_TOOLCHAIN_FILE=../toolchain-x86_64-w64-mingw32.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main10.a

cd ../8bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DCMAKE_TOOLCHAIN_FILE=../toolchain-x86_64-w64-mingw32.cmake -DEXPORT_C_API=ON -DENABLE_SHARED=ON -DENABLE_CLI=ON -DHIGH_BIT_DEPTH=OFF\
-DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
make ${MAKEFLAGS}
# linebreak escape for forum layout saving only!

Did I make a mistake with the explicit sets of parameters?

Would you like to have my binaries to compare?

P.S.: Did you use MSVC? It may be possible that linking EXE with exports currently works only with MSVC the way it was implemented, but not with GCC. Investigating further...

[LigH]

It appears that export definitions via x265.def were provided only if MSVC was used. Expanding this clause in the CMakeLists.txt template to (MSVC OR GCC) enabled GCC to build an EXE with exported funcions too.
__

Here are the first "All-In-One" x265.exe v1.7+298 which could also be linked as if they were DLLs (in theory yet, to be tested):

x265 1.7+298-523540864864 AIO (GCC 4.8.2) (https://www.mediafire.com/download/mo0338nxxlc77f6/x265_1.7+298-523540864864_AIO.GCC482.7z)
x265 1.7+298-523540864864 AIO (GCC 4.9.2) (https://www.mediafire.com/download/w5w91t6c833b35e/x265_1.7+298-523540864864_AIO.GCC492.7z)

[Ma]

I compare x265 builds linked to old msvcrt.dll with linked to new msvcr120.dll.

265-AVX means build linked to old msvcrt.dll with option -march=corei7-avx
AVX-120 means build linked to new msvcr120.dll + option -march=corei7-avx
265-GEN means generic build linked to old msvcrt.dll
GEN-120 means generic build linked to new msvcr120.dll

Platform: Win 7 64-bit, CPU i5 3450S
Options: -D10 --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709

Result (encode time in seconds):

fast medium slow slower verysl placebo
265-AVX 93,71 139,66 163,27 163,39 161,46 165,18
AVX-120 93,43 138,94 162,57 161,89 160,76 163,88
265-GEN 94,09 140,47 163,51 163,97 161,87 166,05
GEN-120 93,64 139,95 163,20 163,89 161,13 165,25


There is interesting that builds linked to new msvcr120.dll are faster even with slow presets. There is close battle between 265-AVX vs. GEN-120.

Full results & batch file used to test attached.

[Ely]

Have you guys figured out good parameters for high quality sources such as 1080p blurays ? From my tests, 6mbps seems to be a threshold after which x264 -tune film will be better overhaul than x265 with the same bitrate. For now I have much better results with "aq-strength=1.2:qcomp=0.5:psy-rd=0.5:deblock=-1", but it still doesn't match x264.

[benwaggoner]

Have you guys figured out good parameters for high quality sources such as 1080p blurays ? From my tests, 6mbps seems to be a threshold after which x264 -tune film will be better overhaul than x265 with the same bitrate. For now I have much better results with "aq-strength=1.2:qcomp=0.5:psy-rd=0.5:deblock=-1", but it still doesn't match x264.

Can you share your full command lines for both x264 and x265 for this comparison?

Try adding --qf-mode 32 --aq-mode 2 --aq-strength 2.0. Sometimes --ipratio 1.3 --pbratio 1.2 can help.

I think a good community project would be to figure out recommended --tune film and --tune animation presets for x265. We already have grain, zerolatency, and fastdecode.

[Boulder]

There are still the old problems pointed out by several of us, the x265 devs have not yet addressed them. My old bug report is on "major" priority but I think they have some more urgent (=sponsor demands) matters to handle first.

https://bitbucket.org/multicoreware/x265/issues/122/loss-of-details-compared-to-x264

[stax76]

Sponsor demands were mentioned before but think about it, there could be several other reasons.

[Ely]

Can you share your full command lines for both x264 and x265 for this comparison?

Try adding --qf-mode 32 --aq-mode 2 --aq-strength 2.0. Sometimes --ipratio 1.3 --pbratio 1.2 can help.

I think a good community project would be to figure out recommended --tune film and --tune animation presets for x265. We already have grain, zerolatency, and fastdecode.

Sure. X265 :

ffmpeg -i input.mkv -t 10 -vcodec libx265 -preset veryslow -b:v 7M -x265-params pass=1:colorprim=bt709:colormatrix=bt709:transfer=bt709 -an -f hevc NUL
ffmpeg -i input.mkv -t 10 -vcodec libx265 -preset veryslow -b:v 7M -x265-params pass=2:colorprim=bt709:colormatrix=bt709:transfer=bt709 -an out-x265-vanilla.mkv

X264 :

ffmpeg -i input.mkv -t 10 -vcodec libx264 -preset veryslow -tune film -b:v 7M -pass 1 -x264-params colorprim=bt709:colormatrix=bt709:transfer=bt709 -an -f h264 NUL
ffmpeg -i input.mkv -t 10 -vcodec libx264 -preset veryslow -tune film -b:v 7M -pass 2 -x264-params colorprim=bt709:colormatrix=bt709:transfer=bt709 -an out-x264-film.mkv

Here's a screenshot comparison between x264 and x265's outputs from the above commands :

http://screenshotcomparison.com/comparison/134774

Source is a Luther 1080p25 bluray I own, which I ripped without re-encoding.

I then added the following to x265 :

aq-strength=1.5:qcomp=0.5:psy-rd=1.0:deblock=-1:aq-mode=2

And here is a screenshot between x265-vanilla and x265-tuned :

http://screenshotcomparison.com/comparison/134776

It's a bit better but still far from the x264 output. I tried setting qg-size=32 and aq-strength=2.0 like you said, but the result doesn't look any different really.. The lines on the girl's shirt are still as blurry for example.

[RainyDog]

Here's a screenshot comparison between x264 and x265's outputs from the above commands :

http://screenshotcomparison.com/comparison/134774

Source is a Luther 1080p25 bluray I own, which I ripped without re-encoding.

And here is a screenshot between x265-vanilla and x265-tuned :

http://screenshotcomparison.com/comparison/134776

It's a bit better but still far from the x264 output. I tried setting qg-size=32 and aq-strength=2.0 like you said, but the result doesn't look any different really.. The lines on the girl's shirt are still as blurry for example.

But which is closer to the source?

I'm not really seeing any alarming differences between the the x264 and x265 outputs really. Certainly wouldn't call the x265 output far from x264 nor the girl's shirt blurry as such.

If anything, I'd say the x264 just looks slightly rougher with more blocking and banding and x265 looks like it's applying more aggressive deblocking. Which may or may not be a good thing depending on the source I suppose.

Can you try setting deblock to -3 in x265?

[Ely]

But which is closer to the source?

I'm not really seeing any alarming differences between the the x264 and x265 outputs really. Certainly wouldn't call the x265 output far from x264 nor the girl's shirt blurry as such.

If anything, I'd say the x264 just looks slightly rougher with more blocking and banding and x265 looks like it's applying more aggressive deblocking. Which may or may not be a good thing depending on the source I suppose.

Can you try setting deblock to -3 in x265?

The shirt definitely looks much better in the x264 version (imho). It's so much sharper and detailed (again, imho :) ).

Same goes with the hair, the eyelashes, her face..

I'll do a deblock -3 and keep you updated.. I'll also post a comparison with the source.

EDIT :

Source vs x264 : http://screenshotcomparison.com/comparison/134805
Source vs x265 : http://screenshotcomparison.com/comparison/134807
Source vs x265 deblock -3 : http://screenshotcomparison.com/comparison/134809

deblock -3 doesn't seem to cut it either I'm afraid. I didn't notice at first, but x264 applies kind of a light sharpen filter over the source.. I still prefer that to x265's blurring though.

EDIT 2 :

Soo.. I went ahead and applied a light sharpen filter before encoding with x265 (vanilla settings).

Source vs sharpen/x265 : http://screenshotcomparison.com/comparison/134812
x265 vanilla vs sharpen/x265 : http://screenshotcomparison.com/comparison/134813

I really like the results here ! I've found a good compromise for my encodes.

[Barough]

In the end so is it always up to each person to say what they think looks best in the end but it's always good to get feedback/input into settings etc.

A friend of mine is working in the video encoding business and he have tried 2 help me with a good general custom command line to get the final 'tweaks' in there but it's not easy since sometimes we think different things looks good etc. Then there is the case of what monitor etc. you viewing your encode on. There is many aspects in the end that have to be counted in.

[CruNcher]

But which is closer to the source?

I'm not really seeing any alarming differences between the the x264 and x265 outputs really. Certainly wouldn't call the x265 output far from x264 nor the girl's shirt blurry as such.

If anything, I'd say the x264 just looks slightly rougher with more blocking and banding and x265 looks like it's applying more aggressive deblocking. Which may or may not be a good thing depending on the source I suppose.

Can you try setting deblock to -3 in x265?

Really nice to see x264 HVS tuneing still holding up so amazingly (for now) especially if you count the decoding complexity Ratio :)

The shirt definitely looks much better in the x264 version (imho). It's so much sharper and detailed (again, imho :) ).

Same goes with the hair, the eyelashes, her face..

I'll do a deblock -3 and keep you updated.. I'll also post a comparison with the source.

EDIT :

Source vs x264 : http://screenshotcomparison.com/comparison/134805
Source vs x265 : http://screenshotcomparison.com/comparison/134807
Source vs x265 deblock -3 : http://screenshotcomparison.com/comparison/134809

deblock -3 doesn't seem to cut it either I'm afraid. I didn't notice at first, but x264 applies kind of a light sharpen filter over the source.. I still prefer that to x265's blurring though.

EDIT 2 :

Soo.. I went ahead and applied a light sharpen filter before encoding with x265 (vanilla settings).

Source vs sharpen/x265 : http://screenshotcomparison.com/comparison/134812
x265 vanilla vs sharpen/x265 : http://screenshotcomparison.com/comparison/134813

I really like the results here ! I've found a good compromise for my encodes.

I would say the additional CPU cycles you threw in for the additional external sharpening pass wasn't really worth it, the difference is so marginal i doubt that even in motion you would realize the difference in anyway ;)

[birdie]

I for one prefer x264/x265_with_sharpening - everything looks sharper and clearer. Not meaning to sound harsh or offensive but are you eyes and displays OK? Cause the difference is humongous.

[CruNcher]

Yeah see the difference now noscript blocked the js

http://screenshotcomparison.com/comparison/134833

what predicts the uncompressed source input the most accurate (not the blu-ray source) is the question ;)

looking @ the deconvolution effect on the Depth of Field you can start to argue here ;)


http://screenshotcomparison.com/images/1436688946_3760491582.png
http://screenshotcomparison.com/images/1436702963_1364025978.png
http://screenshotcomparison.com/images/1436702962_8761439502.png


@Ely

Could you upload a sample of both results x264/x265 before the Depth of Field, when she gets down to the baby and most probably the DOF sets in and then after the Baby scene a bit (she moves up again ?) thx

My Personal Preference for the spatial result would be the x264 one even with that small deconvolution on the DOF which might be even a good thing, that we don't know exactly :)

http://screenshotcomparison.com/images/1436702963_1364025978.png

Though we don't watch Video/Movies spatial but temporal and in the end only the superiority in motion and how that is overall perceived really count's

[Ely]

Yeah see the difference now noscript blocked the js so nice would be also comparing x264 plain hvs vs sharpen h.265 ;)

What do you mean by "x264 plain hvs" ?

Could you upload a sample of both results x264/x265 before the Depth of Field, when she gets down to the baby and most probably the DOF sets in and then after the Baby scene a bit (she moves up again ?) thx

I'll try to get it up when I'm home :) .

[benwaggoner]

If you want sharper, you could try increasing psy-rdoq. That can increase apparent noise and detail retention. Too much can wast a lot of bits. A little --nr-inter can help improve detail at a given bitrate by shifting bits from random noise to static or predicted edges.


-Ben Waggoner (via TapaTalk)

[LigH]

Another "comprehensive" weekly build:

x265 1.7+338-8023786c5247 (GCC 4.8.2) (https://www.mediafire.com/download/982yaxtz6w62mkx/x265_1.7+338-8023786c5247.GCC482.7z)
x265 1.7+338-8023786c5247 (GCC 4.9.2) (https://www.mediafire.com/download/en2zcc8du27afp7/x265_1.7+338-8023786c5247.GCC492.7z)

[CruNcher]

Im currently testing Nvidias HEVC Encoder vs x265

i really wonder if Nvidias SIP Core is based on Vanguards IP http://www.vanguardvideo.com/

Not officially

[Ely]

Im currently testing Nvidias HEVC Encoder vs x265

Would love to see some results ! Their HEVC encoder on the Tegra X1 can do 4K30 in real time, probably gonna be the same with the encoder on their graphics cards. I have a feeling the quality won't be that good though, as with any hardware encoder..

Sorry about the screens I didn't post, there weren't the scenes you talked about and I've moved on to other things ^^ .

[benwaggoner]

Would love to see some results ! Their HEVC encoder on the Tegra X1 can do 4K30 in real time, probably gonna be the same with the encoder on their graphics cards. I have a feeling the quality won't be that good though, as with any hardware encoder.
Yeah, I'd be interested in seeing this. x265 was able to do 2160p30 on a dual-socket Broadwell system several months ago, so we could have a quality comparison. I think Elemental has already demoed 2160p60 live as well.

[LigH]

@ foxy etc.: Can you confirm that zones don't work for n-pass, --pass 3|2?

[RainyDog]

If you want sharper, you could try increasing psy-rdoq. That can increase apparent noise and detail retention. Too much can wast a lot of bits. A little --nr-inter can help improve detail at a given bitrate by shifting bits from random noise to static or predicted edges.

Is psy-rdoq basically the equivalent of x264 psy-rdo?

Was thinking that the sharper x264 image between the x264/x265 comparison Ely made could be partly attributed to --tune film being used which adds psy-trellis in x264. And even a tiny amount of psy-trellis increases sharpness quite a bit.

[CruNcher]

It's a combination of different things the visual impression doesn't just come from 1 specific setting ;)

Nvidias H.265 Hardware Encoder isn't that bad @ all and they still working on more features it looks much better then the begining of their H.264 FreXt Encoder and Performance is comparable to the H.264 Hardware part so the Parallel Redesing seems to have really helped here :)
It still loses High Frequency Details of course a lot and bitrate doesn't really matter in that case @ all.

I guess it would be absolute Game Recording Ready even in it's current state.

Especially hard it becomes to further compress down VC-1 with adaptive deadzones and it's nice Grain Retention ;)

Also Nvidia has revealed that they can programm this thing partly it's not entirely fixed function :)

they revealed the underlying firmware that is loaded by the driver ;)

Also that a external Motion Compensation mode will be released for utilization of their Hardware Motion Estimation :)