x265 HEVC Encoder

[Boulder]

Has anyone else noticed how the bitrate shown during the encoding phase and the final bitrate differ from each other quite a lot sometimes? Yesterday I happened to be watching an 70000-frame encode finish and at the last frames, the average bitrate was ~6800 kbps. When the encode finished, the final bitrate was suddenly over 7100 kbps.

[Wolfberry]

@FranceBB I made a x86 test binary targeting SSE4.2 (only 8 bit).

You can test if it works or not, I also compiled ffmpeg with libvmaf, and you can test that as well.

[FranceBB]

@FranceBB I made a x86 test binary (https://drive.google.com/open?id=1YAdAX8xhX5wPYllY4_tOZX0GEzpelCsb) targeting SSE4.2 (only 8 bit).

You can test if it works or not, I also compiled ffmpeg (https://drive.google.com/open?id=1eq85KZ3YLxbbrUbOpYpFelrDBlqS1oVm) with libvmaf, and you can test that as well.

It's weird.
Dependency Walker didn't find any issue with the installer, but when I try to run it it says that's not a valid x86 application.
Are you sure that you targeted SSE4.2? Out of curiosity, can you try with 4.1 and one without any assembly optimisation?
The CPU is fully capable of handling SSE4.2, so I don't understand.
The OS is Windows Server 2003 x86 with PAE Enabled and 16GB of RAM.

[qyot27]

It's not weird when you consider that Windows Server 2003 is subject to the same problem that Windows XP faces: the error is almost definitely coming from x265 expecting modern Windows APIs (read: NUMA). The 'not a valid x86 application' error doesn't occur when the assembly is wrong (in that case it would crash and throw a SIGILL), it occurs when you try to run 64-bit programs on 32-bit OSes (which in this case it's not; the executable and dll are standard 32-bit PE32) or other similar OS incompatibilities.

https://bitbucket.org/multicoreware/x265/src/cb3e172a5f51c6a4bf8adb7953fe53277f5a1979/source/CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-443

[katzenjoghurt]

Hm.
Could it be that zones are broken in AU+7?
StaxRip crashes away for me with zones defined. AU+3 still worked.
(I'm using the VS 2019 Preview 3 AVX2 AU+7 build from http://msystem.waw.pl/x265/)

[Ma]

Could it be that zones are broken in AU+7?
StaxRip crashes away for me with zones defined. AU+3 still worked.

Yes, it could. Second suspect is commit Integrate SVT-HEVC encoder to x265 (https://bitbucket.org/multicoreware/x265/commits/878541319ea1375be0e981f6ea5fefdb4d509fbd) (first suspect was innocent)

Proposed fix is (it is only technical change, I totally don't understand x265_copy_params function):
diff -r cb3e172a5f51 source/common/param.cpp
--- a/source/common/param.cpp Tue Feb 19 20:20:35 2019 +0530
+++ b/source/common/param.cpp Tue Feb 26 16:16:16 2019 +0100
@@ -2240,16 +2240,7 @@
dst->rc.zoneCount = src->rc.zoneCount;
dst->rc.zonefileCount = src->rc.zonefileCount;

- if (src->rc.zones)
- {
- dst->rc.zones->startFrame = src->rc.zones->startFrame;
- dst->rc.zones->endFrame = src->rc.zones->endFrame;
- dst->rc.zones->bForceQp = src->rc.zones->bForceQp;
- dst->rc.zones->qp = src->rc.zones->qp;
- dst->rc.zones->bitrateFactor = src->rc.zones->bitrateFactor;
- }
- else
- dst->rc.zones = NULL;
+ dst->rc.zones = src->rc.zones;

if (src->rc.lambdaFileName) dst->rc.lambdaFileName = strdup(src->rc.lambdaFileName);
else dst->rc.lambdaFileName = NULL;

Could you test if it helps? (compiled gcc 8.3 binary with this patch: test-Au7.7z (http://msystem.waw.pl/x265/test-Au7.7z))

[katzenjoghurt]

Thx Ma... I'll try your version out as soon as I'm back from work (in 6 hours).

AU+7 crashed for me for two videos when I tried it out this morning just by setting
--zones 1,100,b=1.3

No crash any more after I replaced the exe with an older AU+3 version.

[Ma]

Thanks for the info. The prime suspect is innocent (I am able to reproduce the problem) -- please ignore the patch and binary to test. We should investigate the problem further...

[Ma]

In x265 version 3.0_Au+5 there is new function x265_copy_params which I don't know what problem solves -- for sure it create new problems (zones for example).

My question is: if we remove x265_copy_params function and go back to old code (memcpy) is there something wrong? I've attached patch that revert changes with x265_copy_params function (maybe instead of patching this function it is better to remove it).

[mandarinka]

Has anyone else noticed how the bitrate shown during the encoding phase and the final bitrate differ from each other quite a lot sometimes? Yesterday I happened to be watching an 70000-frame encode finish and at the last frames, the average bitrate was ~6800 kbps. When the encode finished, the final bitrate was suddenly over 7100 kbps.

Happens to me too, even with a bigger deltas possibly (not sure, I use higher rates generally).

[katzenjoghurt]

Hi Ma,

I fear I can't be of help finding an answer to your question but thanks a lot for looking into it! :) *thumbsup*

[FranceBB]

The only difference between Au+7 and Au+3 are SVT-HEVC (not enabled in the build you use) and the zone fix in linux (which probably breaks staxrip) (need to investigate further)

@FranceBB New test build Not Set (https://drive.google.com/open?id=1oBQ7GCPYojFrhn_gXI29_0cTaDC4LzTe) SSE4.2 (https://drive.google.com/open?id=1sz4flIccYFBqSA5ANnONJzq9LMPzdQcF)

This one works, however I can't encode anything higher than 8bit (if I try to use Main10 it reverts back to the default bit-depth).
I remember that I had this kind of issue when I tried to compile x265 x86 with Visual Studio (I never managed to get 10bit and 12bit builds for x86 out of Visual Studio).

I tried now with a longer test, but encoding at 8bit this time, letting x265 calculate the average speed for me and feeding it with a 16bit uncompressed clip:

- GCC 8.2 SSE4.2

6.19fps

- Wolfberry not SSE4.2

6.14fps

- GCC 9 Preview SSE4.2

6.11fps

- LigH

6.22fps


However, encoding at 8bit and comparing different compilers shows different results, 'cause for 8bit x265 there are manually written intrinsics by x265 developers.
The interesting part is with 10bit for which there aren't manually written intrinsics, so it's up to the compiler to optimize the plain C++ code as much as possible, that's why I was testing them with Main10 in my previous test.
For the 8bit, apparently, GCC9 is still slower than GCC8, your build without targeting SSE4.2 is somewhere in-between and the one made by LigH is faster than mine for whatever reason.
But again, for 8bit there are manually written intrinsics, so I can't really test the effectiveness of compilers.

[Ma]

@katzenjoghurt
In new binaries from http://msystem.waw.pl/x265/ (ver. 3.0_Au+8) zones are working.

Now I must do some work for living but at the weekend I should look into this bug closer and prepare proper patch that works with SVT_HEVC too.

[LigH]

x265 3.0 Au+8-31ab7e09a3b5 (https://www.mediafire.com/file/rt5dypooppdpkze/x265_3.0_Au+8-31ab7e09a3b5.7z/file) (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.3.0)

New 64-bit GCC 8.3.0, and zone issues should be fixed

[katzenjoghurt]

@katzenjoghurt
In new binaries from http://msystem.waw.pl/x265/ (ver. 3.0_Au+8) zones are working.

Now I must do some work for living but at the weekend I should look into this bug closer and prepare proper patch that works with SVT_HEVC too.

Yes! Wonderful! :) ... works like a charm for me again.
Immediately tried it out this morning but had to get to work as well (really quick) and was running out of time to post about it.

Thank you, Ma. :)

[Barough]

x265 v3.0_Au+9-2abd2a1909a4 (http://www.mediafire.com/file/69a6j1zgkt2k21g/x265-3.0_Au%252B9-2abd2a1909a4_Win_GCC.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[filler56789]

↑ @Barough: many :thanks: for the new build :)

[Barough]

x265 v3.0_Au+14-c7e5878bdd31 (https://www.mediafire.com/file/g37kine05h521q3/x265-3.0_Au+14-c7e5878bdd31_Win_GCC.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 3.0 Au+14-c7e5878bdd31 (https://www.mediafire.com/file/j8c5ddgmpb3tmub/x265_3.0_Au+14-c7e5878bdd31.7z/file) (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.3.0)

3 flavours:

"Win32XP" (XP compatibility enabled, should disable NUMA support)
"Win32" (XP compatibility disabled, NUMA support should be enabled in Win7+)
"Win64"

AVX2 for normFactor and ssimDistortion

[filler56789]

x265.exe 3.0_Au+16-0018ca1ca42f

(GCC 7.4.0, 64-bits, multilib)

http://www.mediafire.com/file/gtr4ehsp52vho20/x265-3.0_Au%2B16-0018ca1ca42f.7z

[Forteen88]

@Wolfberry. You're not releasing a ICC19-compile of x265 anymore?

[filler56789]

x265-3.0_Au+21-bac0e1acb874-win64-multilib (https://drive.google.com/open?id=1nfhUE3fHqKefSwIhDf3LN67jANU9zroF)

x265 [info]: build info [Windows][GCC 8.3.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec 58.51.100)
x265 [info]: (libavformat 58.27.102)
x265 [info]: (libavutil 56.26.100)
x265 [info]: (lsmash 2.16.1)

Compiled with LAVF & LSMASH support, patches from msg7086.

Your build doesn't work on 64-bit Windows 7, it simply crashes :confused:

[lvqcl]

Your build doesn't work on 64-bit Windows 7, it simply crashes :confused:

I suspect that the problem is not an OS. Probably your CPU doesn't support AVX (or AVX2?), and this build requires it for some reason.

[filler56789]

Yeah, that build requires AVX.

New build (https://drive.google.com/open?id=1nKb6zeAT7pqC3LhEky66NglWTMNPy-XI)

x265 [info]: HEVC encoder version 3.0_Au+21-bac0e1acb874
x265 [info]: build info [Windows][GCC 8.3.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec 58.52.100)
x265 [info]: (libavformat 58.27.103)
x265 [info]: (libavutil 56.26.100)
x265 [info]: (lsmash 2.16.1)

I'm using march=core2 for this build (I use --with-arch=core2 when configuring gcc), so it should work for most people, but no guarantee as I don't have a spare machine to test.

Thanks for the compatible build :thanks:

It is somewhat bloated because of the additional stuff, but I compressed it with upx and now it has a healthy weight.

[Boulder]

How does one get rid of the "onion gradient" artifacts of x265? In the sample images, they are apparent in the character's forehead and also in the purplish stripe near his hair (zoom a bit to see both better). The bitrate of the encodes is ~6900 kbps.

x264
https://i.ibb.co/RprZzRn/x264.png (https://ibb.co/3y6GBgX)

x265, aq-mode 1
https://i.ibb.co/zfyTdx0/x265-aq1.png (https://ibb.co/9YFkPgC)

x265, aq-mode 2
https://i.ibb.co/19DYDXf/x265-aq2.png (https://ibb.co/55NXNjW)

Some base settings of the x265 encode:
--deblock -2:-1 --no-strong-intra-smoothing --cbqpoffs -3 --crqpoffs -3 --subme 3 --merange 24 --no-sao --no-rect --qcomp 0.7 --rd 6 --rd-refine
--aq-mode 1/aq-mode 2 --aq-strength 0.9 --ctu 16 --max-tu-size 8 --qg-size 16 --tu-inter-depth 2 --tu-intra-depth 2 --limit-tu 1 --limit-refs 3
--max-merge 2 --ref 5 --bframes 10

The x264 settings are pretty much --preset veryslow --tune film --no-fast-pskip --no-dct-decimate --deblock -2:-1 --qcomp 0.7.

[mini-moose]

How does one get rid of the "onion gradient" artifacts of x265? In the sample images, they are apparent in the character's forehead and also in the purplish stripe near his hair (zoom a bit to see both better).

Maybe post a source cap too.

[benwaggoner]

How does one get rid of the "onion gradient" artifacts of x265? In the sample images, they are apparent in the character's forehead and also in the purplish stripe near his hair (zoom a bit to see both better).

Some base settings of the x265 encode:
--deblock -2:-1 --no-strong-intra-smoothing --cbqpoffs -3 --crqpoffs -3 --subme 3 --merange 24 --no-sao --no-rect --qcomp 0.7 --rd 6 --rd-refine
--aq-mode 1/aq-mode 2 --aq-strength 0.9 --ctu 16 --max-tu-size 8 --qg-size 16 --tu-inter-depth 2 --tu-intra-depth 2 --limit-tu 1 --limit-refs 3
--max-merge 2 --ref 5 --bframes 10

The x264 settings are pretty much --preset veryslow --tune film --no-fast-pskip --no-dct-decimate --deblock -2:-1 --qcomp 0.7.
You are doing some weird settings in there which may have combinatorial effects. Can you try just --preset slower and see how that turns out?

A 8x8 max tu is pretty unusual, and those are also big chroma offsets which can suck bits away from luma. What are the goals of these settings, and how tdid you come to them?

[Boulder]

I got you the original clip here. I basically did a very slight MDegrain and then downscaled to 1280x720 using a very sharp Bicubic and fed to the encoders.

https://drive.google.com/open?id=1Qm_JWO-bksBTRgPZkN9NZavzXFTSkGIr

My x265 settings are based on frame-by-frame comparisons that I made several times. A small CTU and TU size look better (least distortion compared to the original image) with 720p encodes. For 1080p, I would use one notch higher values (also based on my tests). The chroma offsets don't change the bitrate much in CRF mode so the difference in 2-pass shouldn't also be big. Besides, x264 already does a similar thing by default.

EDIT: does anyone else have problems with topic notifications? I don't get any emails at all from any thread I've subscribed to.

[excellentswordfight]

I got you the original clip here. I basically did a very slight MDegrain and then downscaled to 1280x720 using a very sharp Bicubic and fed to the encoders.

https://drive.google.com/open?id=1Qm_JWO-bksBTRgPZkN9NZavzXFTSkGIr

My x265 settings are based on frame-by-frame comparisons that I made several times. A small CTU and TU size look better (least distortion compared to the original image) with 720p encodes. For 1080p, I would use one notch higher values (also based on my tests). The chroma offsets don't change the bitrate much in CRF mode so the difference in 2-pass shouldn't also be big. Besides, x264 already does a similar thing by default.

EDIT: does anyone else have problems with topic notifications? I don't get any emails at all from any thread I've subscribed to.
Dont seem to be an "general" issue with x265. Did a re-encode of your sample and I didnt get an gradiant issue, and overall I think x265 did a better job. I think benwaggoner is right, its your settings thats causing it.

x264 2pass @ 5Mbps, veryslow tune film
https://i.ibb.co/F08sSQf/x264.png (https://ibb.co/yYghwzM)

x265 2pass @ 5Mbps, slow, --no-sao --no-strong-intra-smoothing --deblock -1:-1
https://i.ibb.co/rGn5b5H/x265.png (https://ibb.co/fYmr8rH)

[Boulder]

Dont seem to be an "general" issue with x265. Did a re-encode of your sample and I didnt get an gradiant issue, and overall I think x265 did a better job. I think benwaggoner is right, its your settings thats causing it.

Thanks, that's exactly what I was looking for since I was experimenting a lot with aq-strength and the psy options to try to figure out what is wrong but was clearly looking in the wrong place.

I did some more testing now that I found those troublesome frames (it seems they evaded me when I pinpointed my go-to settings a long time ago), and using CTU 32 makes the onionize effect go away. I also left max-tu-size and qg-size at their defaults since things looked good.

[jethro]

Thanks, that's exactly what I was looking for since I was experimenting a lot with aq-strength and the psy options to try to figure out what is wrong but was clearly looking in the wrong place.

I did some more testing now that I found those troublesome frames (it seems they evaded me when I pinpointed my go-to settings a long time ago), and using CTU 32 makes the onionize effect go away. I also left max-tu-size and qg-size at their defaults since things looked good.

Encoder Settings:
x265 CRF 28, veryslow, --no-sao --no-strong-intra-smoothing --deblock -1:-1


https://i.ibb.co/7C52R4Z/Av-ringing-1.png (https://ibb.co/fF54nvy)

https://i.ibb.co/cyzLmnh/Av-ringing-2.png] (https://ibb.co/9pRtM5H)

https://i.ibb.co/wp58wYv/Av-ringing-3.png] (https://ibb.co/mhfdXSx)

More bitrate removes the artifacting.

[Boulder]

In those cases, I had thrown quite a lot of bitrate there. Using CRF18 produced a smaller file than 6900 kbps, which was x264@CRF18. CRF28 is something I'd never use :) The onion artifacts were visible only in certain frames with very high motion, that's probably why I missed them in my test rounds earlier. I do recall someone complaining that tune grain sometimes did those as well.

[Blue_MiSfit]

I'd caution against doing too much settings tuning using still frame comparisons, especially when evaluating max CU size (--ctu).

I've spent a lot of time doing this. Using --ctu 32 can indeed produce a sharper / more detailed / less blurred image when looking at single frames - relative to keeping the default (--ctu 64) in some cases. However, the trade-off is typically more blocking, which you're more likely to notice in motion. In other words, an inferior user experience unless you're using very high bitrates.

You're kind of performing a brute force non-adaptive psy tuning. x265 will use smaller CUs when it sees fit, you're just forcing it to never consider 64x64, even when coding giant uniform areas.

In my opinion, you're typically best off trusting the extensive tuning and testing that MulticoreWare has done, and just using a preset. They set --ctu to 64 starting with --preset veryfast, and keep it that way all the way through placebo. In fact, in looking at the documentation for this parameter: https://x265.readthedocs.io/en/default/cli.html#cmdoption-ctu it appears the only reason they set this to 32 for superfast and lower is that this increases parallelism and can therefore be faster.

Do what's right for you, of course :)

[tuanden0]

I got crash when using zone in x265_12bit.
So I tried to use VSEdit to test it and here is result.
Here is x265 file: http://msystem.waw.pl/x265/x265-3.0_Au+21-bac0e1a_gcc83-AVX2.7z
Here is everything else: https://i.imgur.com/FFlFylW.png

[Boulder]

I'd caution against doing too much settings tuning using still frame comparisons, especially when evaluating max CU size (--ctu).

I've spent a lot of time doing this. Using --ctu 32 can indeed produce a sharper / more detailed / less blurred image when looking at single frames - relative to keeping the default (--ctu 64) in some cases. However, the trade-off is typically more blocking, which you're more likely to notice in motion. In other words, an inferior user experience unless you're using very high bitrates.

You're kind of performing a brute force non-adaptive psy tuning. x265 will use smaller CUs when it sees fit, you're just forcing it to never consider 64x64, even when coding giant uniform areas.

In my opinion, you're typically best off trusting the extensive tuning and testing that MulticoreWare has done, and just using a preset. They set --ctu to 64 starting with --preset veryfast, and keep it that way all the way through placebo. In fact, in looking at the documentation for this parameter: https://x265.readthedocs.io/en/default/cli.html#cmdoption-ctu it appears the only reason they set this to 32 for superfast and lower is that this increases parallelism and can therefore be faster.

Do what's right for you, of course :)I've always considered 64x64 to be quite a lot for 720p video, and also the difference in performance is substantial. I can see that the average QP is lower with 32x32 than 16x16 though so it could be that there are situations where the encoder could squeeze some more out of the video. Of course, I could always run two simultaneous encodes to keep the CPU as busy as possible.

As you apparently have been testing things quite a lot, do you have any opinion regarding AQ-mode? I'm still quite unsure if the new default of mode 2 is the best general option for film.

[excellentswordfight]

I've always considered 64x64 to be quite a lot for 720p video, and also the difference in performance is substantial. I can see that the average QP is lower with 32x32 than 16x16 though so it could be that there are situations where the encoder could squeeze some more out of the video. Of course, I could always run two simultaneous encodes to keep the CPU as busy as possible.

As you apparently have been testing things quite a lot, do you have any opinion regarding AQ-mode? I'm still quite unsure if the new default of mode 2 is the best general option for film.
I wrote to Ma a fem months back regarding ctu 64 being overkill for reslutions under 2160p, and asking why this as the default value. And he responded with numbers that showed a loss in compression with using lower ctu values, even for lower res material. The difference is probably pretty negligible though, but i dont see any reason to lower it IF youre not trying to saturate more threads (were it can do wonders). I only lower it to 32 for 1080p if i’m at 16 threads or more.

[Barough]

x265 v3.0_Au+22-feec4bdf9866 (https://www.mediafire.com/file/5y74h3vjekjvho4/x265-3.0_Au+22-feec4bdf9866_Win_GCC.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Blue_MiSfit]

The difference isn't huge, but it does help.

IMO aq-mode 2 is definitely better in most cases. I set this always unless doing extremely low bitrate when I'll use mode 3.

[~ VEGETA ~]

I wanted to encode a 10-bit H.264 MKV video (lossless, 30 gb) to HEVC 10-bit... I piped it via ffmpeg but I put this "-pix_fmt yuv420p" instead of this "yuv420p10le"... I suspect this is wrong, but it is the only way it worked. Can you kindly guide me here?

I encoded .vpy file to lossless 10-bit H.264 since my device is slow with the filters I used... so now how to encode the 10-bit .mkv using x265? << I assumed using -pix_fmt yuv420p is wrong.



Plus, next time when I want to encode like this (lossless 10-bit H.264 then 10-bit HEVC), should I encode to .yuv/.h264 in x264 (--muxer yuv\raw)? So I can input it directly to x265 without piping??



Here is my command line:

"C:\.....\ffmpeg.exe" -i "C:\....\lossless_H264_video.mkv" -pix_fmt yuv420p -f yuv4mpegpipe - | C:\....\x265_64bit_10bit.exe --y4m --preset slower --crf 17 --ref 6 --rd 6 --psy-rd 1 --ctu 64 --aq-strength 0.8 --output-depth 10 --input-res 1920x1080 - --output "C:\....\ep07_1080p_video_HEVC.hevc"

[sneaker_ger]

Post your complete command line and ffmpeg log.

(Yes, if you want 10 bit output setting -pix_fmt yuv420p is wrong. Make sure your ffmpeg build is compiled with 10 bit libx265.)

[~ VEGETA ~]

Post your complete command line and ffmpeg log.

(Yes, if you want 10 bit output setting -pix_fmt yuv420p is wrong. Make sure your ffmpeg build is compiled with 10 bit libx265.)

I posted my command line as you see now.

Where can I find such ffmpeg build for windows?

I thought -pix_fmt is to get the input as 10-bit...

[sneaker_ger]

I thought you wanted to use libx265 from within ffmpeg. Ignore my last post.

Use:
ffmpeg -i "INPUT" -f yuv4mpegpipe -strict -1 -
Then make sure the log says it's "yuv420p10le".

[excellentswordfight]

I wanted to encode a 10-bit H.264 MKV video (lossless, 30 gb) to HEVC 10-bit... I piped it via ffmpeg but I put this "-pix_fmt yuv420p" instead of this "yuv420p10le"... I suspect this is wrong, but it is the only way it worked. Can you kindly guide me here?

I encoded .vpy file to lossless 10-bit H.264 since my device is slow with the filters I used... so now how to encode the 10-bit .mkv using x265? << I assumed using -pix_fmt yuv420p is wrong.



Plus, next time when I want to encode like this (lossless 10-bit H.264 then 10-bit HEVC), should I encode to .yuv/.h264 in x264 (--muxer yuv\raw)? So I can input it directly to x265 without piping??



Here is my command line:

"C:\.....\ffmpeg.exe" -i "C:\....\lossless_H264_video.mkv" -pix_fmt yuv420p -f yuv4mpegpipe - | C:\....\x265_64bit_10bit.exe --y4m --preset slower --crf 17 --ref 6 --rd 6 --psy-rd 1 --ctu 64 --aq-strength 0.8 --output-depth 10 --input-res 1920x1080 - --output "C:\....\ep07_1080p_video_HEVC.hevc"

I never had issues with the following:
"ffmpeg.exe" -i "input.mkv" -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m
So maybe you need to ad -strict -1

[~ VEGETA ~]

I thought you wanted to use libx265 from within ffmpeg. Ignore my last post.

Use:
ffmpeg -i "INPUT" -f yuv4mpegpipe -strict -1 -
Then make sure the log says it's "yuv420p10le".

I see:

video: wrapped_avframe, yuv420p10le in cmd so I guess this is ok.

what about my other question about better way to encode next time?

[sneaker_ger]

I encoded .vpy file to lossless 10-bit H.264 since my device is slow with the filters I used

Plus, next time when I want to encode like this (lossless 10-bit H.264 then 10-bit HEVC), should I encode to .yuv/.h264 in x264 (--muxer yuv\raw)? So I can input it directly to x265 without piping??
I don't understand the need for a temporary file at all in this case. Usually this is to speed up encoding when we do slow filtering + multiple passes of video encoding and time of
filtering + 1st pass + filtering + 2nd pass + .. > filtering + encode to lossless + 1st pass from lossless + 2nd pass from lossless ..

But you are encoding CRF, e.g. now instead of filtering + x265 crf you do filtering + x264 lossless + x265 crf. That's slower?

[~ VEGETA ~]

I don't understand the need for a temporary file at all in this case. Usually this is to speed up encoding when we do slow filtering + multiple passes of video encoding and time of
filtering + 1st pass + filtering + 2nd pass + .. > filtering + encode to lossless + 1st pass from lossless + 2nd pass from lossless ..

But you are encoding CRF, e.g. now instead of filtering + x265 crf you do filtering + x264 lossless + x265 crf. That's slower?

I have very low fps doing my filters, so I put everything to lossless x264 --preset ultrafast... then I can encode directly using x264 with slow settings in both 1080p and 720p. While If I want to encode in 1080 and 720 from vpy in both times I guess it will be slower since now I've gotta encode the filtering twice.

while if I wanna encode 720p only (from horriblesubs tv shows), then yes I go vpy directly without lossless.


what do you do for encoding BDs to 1080 and 720?

[sneaker_ger]

So you encode to multiple resolutions? Ok, then it may make sense to create an intermediate to only do (slow) filtering once.

I think you may save a little bit of time/CPU by saving to uncompressed y4m/yuv instead of encoding x264 lossless as intermediate. But with slow filtering + slow x265 it will probably not make too much of a difference either way. And the size of the file increases so the wear on the HDD/SSD increases. P.S.: ffmpeg allows multiple outputs but I don't know how it affects speed and it may result in HDD fragmentation.


what do you do for encoding BDs to 1080 and 720?
I don't.

[~ VEGETA ~]

So you encode to multiple resolutions? Ok, then it may make sense to create an intermediate to only do (slow) filtering once.

I think you may save a little bit of time/CPU by saving to uncompressed y4m/yuv instead of encoding x264 lossless as intermediate. But with slow filtering + slow x265 it will probably not make too much of a difference either way. And the size of the file increases so the wear on the HDD/SSD increases. P.S.: ffmpeg allows multiple outputs but I don't know how it affects speed and it may result in HDD fragmentation.




save to uncompressed video?? like using virtualdub2 to do that? not bad but I never tried it. I just hope it won't be more size than lossless h.264, at least not too much. plus, it has to be 10-bit.

I encode on a dedicated server so no problem about HDD xD, or so I think.

[sneaker_ger]

You don't need VirtualDub. vspipe can create y4m files. But yes, unsurprisingly, uncompressed files are bigger than compressed ones...

But again: if you are doing slow filtering and slow x265 encoding the difference between uncompressed or lossless x264 --preset ultrafast intermediate is probably not worth worrying about. If you want to know exactly you have to benchmark it.

[~ VEGETA ~]

You don't need VirtualDub. vspipe can create y4m files. But yes, unsurprisingly, uncompressed files are bigger than compressed ones...

But again: if you are doing slow filtering and slow x265 encoding the difference between uncompressed or lossless x264 --preset ultrafast intermediate is probably not worth worrying about. If you want to know exactly you have to benchmark it.

I thought of doing this:

ffmpeg -i inputfile.vpy -c:v rawvideo outputfile.yuv

so you suggested vspipe, so maybe this:

vspipe script.vpy output.raw

or add --y4m

I will try next time to see how much time will it take. Lossless x264 ultrafast 1080p is about 8 hours.