x265 HEVC Encoder

[littlepox]

It frustrates us when we see someone say that x265 is no better than x264 for typical video resolutions and bit rates. That's not our experience, or the experience of any of the dozens of video experts at the companies and organizations we work with. We take it as a challenge. And so, we challenge you or anyone else to show us what you're seeing.

Please point us to a good test sequence that x264 encodes better than x265, and let us know the bit rate you prefer. Not something that was already compressed to consumer streaming video bit rates (which already has H.264 compression artifacts) - a real uncompressed or very lightly compressed (very high bit rate) video test sequence, like one of the videos posted on media.xiph.org (or CableLabs, Elemental, Harmonic, etc.). Any test video, at any bit rate. Tell us your preferred x264 settings also, and we'll encode to the same bit rate with x265 and let everyone judge which encode is better.

Before you run your own tests, be sure you're using the latest development build of x265. Littlepox - I know you have your own favorite x265 command-line recipe, but after May 12th, things changed, and I think that recipe won't deliver the best visual quality. I suggest that you start with default settings for --preset veryslow, and if you have time, also try --preset placebo (which is now noticeably better than veryslow). If you want to run faster than veryslow, also try adding --no-recursion-skip to your command line.

I see I've offended you, my apologize. I don't mean to sneer at x265 nor the developers.

Our testcases are carefully taken from commercial BluRay Disc sources so none of them are heavily compressed. I'm asking my teammate to prepare a 720p one(properly down-scaled) that is short enough and it shouldn't violate the forum policies to be posted. Meanwhile, an x264 benchmark will also be available. We shall get back to you in a few days.

The three massive tuning tests we've done before is very expensive to carry(>500 encodes per time) so we only do that for stable builds; the latest one is with v1.9, and the next one shall be with v2.0. Indeed we don't have a good idea about the most updated version; but we shall be the first to cheer for your guys if major breakthrough is seen next time.

Last but not least, don't expect many users to tolerate --placebo. It's not pragmatic for daily use. The slowest one we are able to accept would be veryslow, if not deciding to use x264 when speed is a concern.

[LigH]

Just as a suggestion for a commonly available and uncompressed, "Creative Commons" licensed source: "Tears of Steel" should provide a good variety of different scenes, from stills to heavy action. The cartoonish credits may have their own challenge for an encoder possibly optimized for real-world footage.

[x265_Project]

I see I've offended you, my apologize. I don't mean to sneer at x265 nor the developers.
No apologies necessary - I'm not offended. We want your feedback, good or bad. We want to address any concerns head-on. x265 has all of the coding tools of x264, and many, many more. In other words, there is never any reason why x265 should be inferior to x264. In the worst case, x265 could encode the video with the exact same frame types, block structures, motion vectors and modes. But thanks to the HEVC standard, x265 has many other options to choose from, including larger block sizes. If there are any areas where x265 is not equal to or better than x264, we need to understand and fix them. If this is a myth, we want to bust it.

[Jamaika]

It gets worse though, in addition to bare trees/bushes, I have observed these artifacts on pine trees, rocky mountains and trees with leaves too (to a lesser degree). I can provide more samples if needed.
I think you will have to wait. The patches to the codec are tested so maybe something after the holidays to improve. I present only two pictures 6000kbps option 'best' latest codec Mainconcept (surcharge) and 'veryslow' X265. There is a difference, and that's all. Cyberlink and Corel have even poorer HEVC encoders. Only preset medium. Get worse using X265 on Google.
Mainconcept 6000kbps, 1920x1080, bframes=3, best, pass=1
http://i65.tinypic.com/295wtv9.png
X265 6000kbps, 1920x1080, bframes=5, veryslow, pass=2
http://i67.tinypic.com/33yj314.png

What can I require?

[pingfr]

The three massive tuning tests we've done before is very expensive to carry(>500 encodes per time) so we only do that for stable builds; the latest one is with v1.9, and the next one shall be with v2.0. Indeed we don't have a good idea about the most updated version; but we shall be the first to cheer for your guys if major breakthrough is seen next time.

Which is why I believe you should wait for a 2.0 official release before running any further tests since they are expensive to carry as you've stated.

By then you should be able to compare original vs. 1.9+1 encode vs. 2.0 encodes and I believe this is where we'll see most of the improvements between 1.9 and 2.0, from there you should also be able to compare your best tuning results (from 2.0, I believe) vs any x264 encodes of the same segment.

My two cents.

[pingfr]

If there are any areas where x265 is not equal to or better than x264, we need to understand and fix them. If this is a myth, we want to bust it.

On point. Couldn't have said it better myself.

[x265_Project]

Just as a suggestion for a commonly available and uncompressed, "Creative Commons" licensed source: "Tears of Steel" should provide a good variety of different scenes, from stills to heavy action. The cartoonish credits may have their own challenge for an encoder possibly optimized for real-world footage.
Yes, it's definitely one of the better test sequences, although it doesn't have any particularly challenging scenes. The higher the original quality, the better (although we need to show that we can handle grainy/noisy content also). There are a bunch of new 4K test sequences on https://media.xiph.org/video/derf/ contributed by Netflix that are excellent 10 bit content. Amazon also contributed high quality gaming captures from Twitch.

[eclipse98]

I think you will have to wait. The patches to the codec are tested so maybe something after the holidays to improve. I present only two pictures 6000kbps option 'best' latest codec Mainconcept (surcharge) and 'veryslow' X265. There is a difference, and that's all. Cyberlink and Corel have even poorer HEVC encoders. Only preset medium. Get worse using X265 on Google.

I can wait, no problem - just wanted to make sure developers are aware of the issue so it can get addressed whenever it becomes a higher priority. As I said before, I am very happy with x265 video quality, your Mainconcept screenshots confirm it.

I also tested Nvidia x265 encoder and it produces even worse color ghosting. I also tested similar footage shot in 1080 rather than 4K and there appears to be no issue, it seems to be 4K related.

Cheers !

[LigH]

There are a bunch of new 4K test sequences on https://media.xiph.org/video/derf/ contributed by Netflix that are excellent 10 bit content.

Wonderful. Rollercoaster videos always used to be challenging, now in UHD even. :cool:

[Selur]

@x265_Project: are there any plans to further improve the x265 performance on multi socket systems when encoding SD content? (for SD cpu usage&speed became better with https://patches.videolan.org/patch/13436/ but it still doesn't seem good,...)

[mandarinka]

@x265_Project: are there any plans to further improve the x265 performance on multi socket systems when encoding SD content? (for SD cpu usage&speed became better with https://patches.videolan.org/patch/13436/ but it still doesn't seem good,...)

For such usage, I think you should probably consider doing multiple encodes at once.

[x265_Project]

@x265_Project: are there any plans to further improve the x265 performance on multi socket systems when encoding SD content? (for SD cpu usage&speed became better with https://patches.videolan.org/patch/13436/ but it still doesn't seem good,...)

We're always working to improve performance, but with a single instance of x265 we run into Amdahl's law. We can only parallelize so much. With SD encodes, there isn't enough parallel work to keep many cores/threads busy, even with frame parallelism. So, that's one of the reasons we developed UHDkit, which can break a single encode into many chunks, and encode the chunks in parallel. If you're encoding many different videos, you can do them all in parallel. Just be sure to pin each encode to a different thread pool using our pools feature.

[pingfr]

We're always working to improve performance, but with a single instance of x265 we run into Amdahl's law. We can only parallelize so much. With SD encodes, there isn't enough parallel work to keep many cores/threads busy, even with frame parallelism. So, that's one of the reasons we developed UHDkit, which can break a single encode into many chunks, and encode the chunks in parallel. If you're encoding many different videos, you can do them all in parallel. Just be sure to pin each encode to a different thread pool using our pools feature.

May I ask what OS does UHDKit runs on natively? I would assume Linux?

Any public pricing models available?

Cheers.

[LigH]

but with a single instance of x265 we run into Amdahl's law.

Thank you, now I know the "RTFM term" to smash against the forehead of people who keep complaining about a "low CPU utilization" ;) ;)

I already suspected that the more complex an algorithm gets, the more restricted parallelizability gets as well (because many intermediate results have to be collected to a final result). You confirmed this assumption here.
__

P.S.:

Matheusz just mentioned in the mailinglist that there are some quirks regarding DLLs and compilers and speed ... not all compilers can handle optimization of multilib builds correctly, so in general, using a build with separate encoder library DLLs per bitdepth should be the fastest solution. On top, GCC 6.1 seems to be faster for Win32 8-bit, but GCC 5.3 for 10-bit and 12-bit code.

I won't be able to use several compiler versions easily, therefore I will keep building with GCC 5.3.

To be able to place both 32-bit and 64-bit builds in the same directory, the scripts will soon produce a new naming pattern, libx265-32_main[10|12].dll for separate Win32 DLLs.

[Motenai Yoda]

Thank you, now I know the "RTFM term" to smash against the forehead of people who keep complaining about a "low CPU utilization"
Nop, Amdahl's law says that optimizing a part x of a program y will make y faster in proportion to how much time y spent on x.

ie a program with function a() and function b(), where a() take 80% of time and b() 20%, optimizing b() to run twice faster will make the program run in 80%+(20%/2) = 90% the time not 50%.

In this case x265's unparallelizable parts will slowing down so much any further (if) possible optimization of the parallelized parts, or parallelizations, will give negible speedup with SD content.

[x265_Project]

Nop, Amdahl's law says that optimizing a part x of a program y will make y faster in proportion to how much time y spent on x.

ie a program with function a() and function b(), where a() take 80% of time and b() 20%, optimizing b() to run twice faster will make the program run in 80%+(20%/2) = 90% the time not 50%.

In this case x265's unparallelizable parts will slowing down so much any further (if) possible optimization of the parallelized parts, or parallelizations, will give negible speedup with SD content.
That's right. Amdahl's law tells you that if you have an algorithm that is 100% parallelizable, you can speed this up proportionally by adding more processor cores. But when you have both serial and parallel operations, some threads will end up waiting for the information they need from another thread that isn't finished, and adding more threads ends up having diminishing returns.

There are many routines involved in HEVC encoding that are serial in nature. For example, to find the true "cost" (# of bits) of a candidate encoding mode for a block, we have to encode and decode the predicted block, calculate the residual error (the difference between the source block and the predicted block), calculate the discrete cosine transform of the residual error, quantize the transformed residual error, and compress the encoded result with CABAC entropy coding. All in series. This can't be further parallelized. CABAC encoding itself is an inherently serial process.

Thanks to Wavefront Parallel Processing, we can encode multiple rows of blocks in parallel, and thanks to x265's frame parallelism, we encode multiple frames in parallel. But the number of rows per frame is limited by the frame size. x265 can operate on more rows per frame with larger frames.

[LigH]

x265 1.9+200-6098ba3e0cf16b11 (https://www.mediafire.com/download/fckfmb1eiol4idp/x265_1.9+200-6098ba3e0cf16b11.7z) (oh, revision hashes are longer now): some thread pool changes, git version ID and other fixes

[Ma]

oh, revision hashes are longer now

x264 has 7 chars long revision hash, x265 had 12 chars long, now it is 16 chars long. On page https://bitbucket.org/multicoreware/x265/commits/all there are 7 chars long revision hashes (and it is enough).

I think we should switch to 7 chars long revision hashes in x265.

[RiCON]

I don't know why I thought {node|short} gave 16-char long hash, but yeah, it should be 12 character instead.
It shouldn't be 7 characters because that can be mistaken with git short form and git/hg commits have no relation whatsoever.

[LigH]

A patch was offered today which reduces the hash length to 12 again.

[RiCON]

I did, yes. After reading the replies here.

[LigH]

Oh, that was you. :)

[pingfr]

Hey guys,

Development appears to be quiet since commit ad961f5 on the 30/05... I mean sure I can see a few minor commits here and there, but they are mostly "minor fixes" such as warning silencing, clarifications, commit hash fixing, etc.

I'm wondering what would be the "next" step or what's the "direction" at the moment from the MulticoreWare team, specifically if anything in the "visual optimization" field of expertise or "compression efficiency" is either in the works or in the pipeline? :)

Cheers.

[x265_Project]

Hey guys,

Development appears to be quiet since commit ad961f5 on the 30/05... I mean sure I can see a few minor commits here and there, but they are mostly "minor fixes" such as warning silencing, clarifications, commit hash fixing, etc.

I'm wondering what would be the "next" step or what's the "direction" at the moment from the MulticoreWare team, specifically if anything in the "visual optimization" field of expertise or "compression efficiency" is either in the works or in the pipeline? :)

Cheers.
There are some optimizations to SAO in development that should be ready this month. Longer term there are a number of visual quality and performance improvements we're working on, but for now we'd prefer to keep our powder dry, so we can make a bigger bang when we have some results to show.

[pingfr]

There are some optimizations to SAO in development that should be ready this month. Longer term there are a number of visual quality and performance improvements we're working on, but for now we'd prefer to keep our powder dry, so we can make a bigger bang when we have some results to show.

Amazing, thanks for the heads up! :)

[filler56789]

.....

PS: Isn't "(now it only enables B GOP structure)" on x265 help outdated

It is the same as version 0.3 when you didn't have b-adapt...

Yes$S... HEVC encoder version 1.9+215-78ffb67a844e still says the same thing.

x265 --help

[Barough]

There are some optimizations to SAO in development that should be ready this month. Longer term there are a number of visual quality and performance improvements we're working on, but for now we'd prefer to keep our powder dry, so we can make a bigger bang when we have some results to show.

That's gr8 info/news. Thnx. :)

[filler56789]

Very-well, my next MinGW builds will not say:

"(now it only enables B GOP structure)"

Sometimes Wikipedia is right: be bold :)

[innosia]

Thanks guys for all of the efforts

I am noob here, can I ask the cli syntax to run x265 to convert mkv to mkv for smaller CRF for tune animation

[LigH]

Unfortunately, a "vanilla" build of x265 can neither read video input from an MKV directly, nor create the encoded result inside an MKV container.

You will need some helping frameserver script (usually AviSynth) to decode the video from your source MKV, using avs4x26x or similar piping helper tools, and will get a raw HEVC video stream you have to multiplex later with e.g. mkvmerge.

Your only way to achieve your desired workflow may be using ffmpeg with libx265 as video encoder. Probably something like:

ffmpeg -i input.mkv -vcodec libx265 -crf 20 -preset slow -tune animation -acodec copy output.mkv

[innosia]

Unfortunately, a "vanilla" build of x265 can neither read video input from an MKV directly, nor create the encoded result inside an MKV container.

You will need some helping frameserver script (usually AviSynth) to decode the video from your source MKV, using avs4x26x or similar piping helper tools, and will get a raw HEVC video stream you have to multiplex later with e.g. mkvmerge.

Your only way to achieve your desired workflow may be using ffmpeg with libx265 as video encoder. Probably something like:

ffmpeg -i input.mkv -vcodec libx265 -crf 20 -preset slow -tune animation -acodec copy output.mkv

thanks LigH for pointing it out
will try and let you know if it works

thanks again

[innosia]

hi i found some guide
but it was 8 bit ffmpeg

can i confirm the page : https://ffmpeg.zeranoe.com/builds/ (64 bit static) has 10 bit? and how to specify for 10 bit depth?

[Ma]

can i confirm the page : https://ffmpeg.zeranoe.com/builds/ (64 bit static) has 10 bit? and how to specify for 10 bit depth?

It has only 8-bit x265 stable 1.9 (outdated). You can start with 100 frames sample like this:
ffmpeg -i ../original.mkv -ss 50 -frames 100 -v error -f yuv4mpegpipe - | x265-10b --y4m - -p slow --crf 24 o.hevc
where x265-10b is current (1.9+217) 10-bit x265.

[LigH]

All libx265 options not explicitly exposed by ffmpeg have to be added in internal parameter format (not x265 CLI format) following the ffmpeg '-x265-params' parameter:

ffmpeg -i input.mkv -vcodec libx265 -crf 20 -preset slow -tune animation -x265-params output-depth=10 -acodec copy output.mkv

Possible problem: x265 does not offer a tuning "animation" yet. Without a tuning parameter it does something, let's see if it used 10 bit depth...

No. It recognizes neither "-x265-params output-depth=10" nor "-x265-params D=10" nor "-x265-params profile=main10".

BTW, I tested with an ffmpeg build created with jb-alvarado's media-autobuild_suite. It may contain multiple x265 libraries with several bit depths. But their selection does not seem to work.

[easyfab]

You can try ffmpeg with -c:v libx265 -pix_fmt yuv420p10le perhaps

[LigH]

The problem is that the mentioned parameters are not recognized:

...
[libx265 @ 000000000294d940] Unknown option: {output-depth|D|profile}.
x265 [info]: HEVC encoder version 1.9+192-aeade2e8d8688ebf
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit+10bit+12bit
...

So, libx265 inside ffmpeg reports providing three bitdepth libraries, but I cannot find a recognized parameter to select one specific out of the three.

Piping Y4M from ffmpeg to x265 CLI is probably the best OS-independent way to get high bitdepth video streams. They just have to be multiplexed afterwards.
__

The suggestion by easyfab was confirmed in IRC. Testing...

OK, profile "Main 10" is selected, so this appears to be a correct suggestion. Tanks, easyfab!

[Ma]

So, libx265 inside ffmpeg reports providing three bitdepth libraries

Are you sure that you are writing about Zeranoe FFmpeg Build?

[qyot27]

The problem is that the mentioned parameters are not recognized:

...
[libx265 @ 000000000294d940] Unknown option: {output-depth|D|profile}.
x265 [info]: HEVC encoder version 1.9+192-aeade2e8d8688ebf
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit+10bit+12bit
...

So, libx265 inside ffmpeg reports providing three bitdepth libraries, but I cannot find a recognized parameter to select one specific out of the three.
You're supposed to use -pix_fmt, because that's how FFmpeg selects the format, and when used inside FFmpeg, libx265 works in direct I/O mode - give it 8-bit, it outputs 8-bit. Give it 10-bit, it outputs 10-bit*, etc. Overriding that has to be done by the part of the toolchain that resamples formats, and that's FFmpeg, not libx265.

*So long as it's a multilib libx265, anyway.

[LigH]

Are you sure that you are writing about Zeranoe FFmpeg Build?

No, as I added later:

BTW, I tested with an ffmpeg build created with jb-alvarado's media-autobuild_suite. It may contain multiple x265 libraries with several bit depths.

[innosia]

Thanks all and ligh for confirming that ffmpeg+libx265 does not support converting from 8bit to 10bit (my source is 8 bit).

My only option will be below

It has only 8-bit x265 stable 1.9 (outdated). You can start with 100 frames sample like this:
ffmpeg -i ../original.mkv -ss 50 -frames 100 -v error -f yuv4mpegpipe - | x265-10b --y4m - -p slow --crf 24 o.hevc
where x265-10b is current (1.9+217) 10-bit x265.

May I know
1. Where to get x265-10b.exe? I can't compile myself coz a noob here
2. How to convert o.hevc back to mkv?

Thank you

[LigH]

1. There are several sources for both "multilib" builds (one EXE with all three bitdepth variants of the encoder included, which you can select by the parameter -D) and separate builds; my MinGW / GCC packages contain both kinds, more links to different builds can be found e.g. in the VideoHelp forum thread (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds).

2. Multiplex it using mkvtoolnix (with mkvmerge as CLI tool, or with the formerly usual MKVmergeGUI or the current MKVToolnixGUI as GUI application) or maybe with ffmpeg too. This is not a "conversion", just wrapping the raw HEVC video stream into a Matroska container (which may then also contain more than just the video stream, like an additional audio stream).
__

P.S. 1.: x265 1.9+217-626fcbac7ffb (https://www.mediafire.com/download/1l666559dr8u691/x265_1.9+217-626fcbac7ffb.7z)

[innosia]

1. There are several sources for both "multilib" builds (one EXE with all three bitdepth variants of the encoder included, which you can select by the parameter -D) and separate builds; my MinGW / GCC packages contain both kinds, more links to different builds can be found e.g. in the VideoHelp forum thread (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds).

2. Multiplex it using mkvtoolnix (with mkvmerge as CLI tool, or with the formerly usual MKVmergeGUI or the current MKVToolnixGUI as GUI application) or maybe with ffmpeg too. This is not a "conversion", just wrapping the raw HEVC video stream into a Matroska container (which may then also contain more than just the video stream, like an additional audio stream).
__

P.S. 1.: x265 1.9+217-626fcbac7ffb (https://www.mediafire.com/download/1l666559dr8u691/x265_1.9+217-626fcbac7ffb.7z)

Thanks Ligh, it works!
currently i am experimenting with the speed vs quality i can get, my cpu took more than 2 hours encoding 200MB 9 mins animation so i terminate it. I used preset veryslow

ffmpeg -i %1 -an -me_method umh -b_strategy 2 -subq 10 -refs 10 -v error -weightp 2 -trellis 2 -qmin 10 -qmax 81 -f yuv4mpegpipe - | x265_main12 --y4m - --level 5.1 --preset veryslow --min-keyint 12 --scenecut 40 --bframes 10 --qcomp 0.6 --rc-lookahead 60 --aq-mode 1 --aq-strength 0.8 --merange 24 --psy-rd 0.60 --crf %5 --output %2

will probably tweak for faster encode.
i appreciate if you can help?

[Jamaika]

Which of the following web pages is current? Maybe there are some new?
http://x265.ru/builds/
https://encoder.pw/
http://msystem.waw.pl/x265/
https://github.com/videolan/x265/commits/master

[x265_Project]

Which of the following web pages is current? Maybe there are some new?
http://x265.ru/builds/
https://encoder.pw/
http://msystem.waw.pl/x265/
https://github.com/videolan/x265/commits/master
The videolan github should be a mirror of our main repository... https://bitbucket.org/multicoreware/x265

None of the other sites are supported by us.

[filler56789]

Which of the following web pages is current? Maybe there are some new?
http://x265.ru/builds/
https://encoder.pw/
http://msystem.waw.pl/x265/
https://github.com/videolan/x265/commits/master

Just compare the builds they offer with the list below:

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

encoder.pw and x265.ru do NOT contain the builds based on the most recent commits.
waw.pl apparently is up-to-date, but their content is a mess :scared:

[Jamaika]

The videolan github should be a mirror of our main repository... https://bitbucket.org/multicoreware/x265

Hmm... At the github I have a patch from 7 June, Videolan 24 June, Bitbucket 16 June. Hence my question.
https://patches.videolan.org/project/x265-devel/list/
https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

You forgot my build archive at MediaFire (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC); but I will not build daily or even automatically, only after a few important commits, more or less weekly.

[Jamaika]

I didn't forget. You are here from the beginning.
He should ask: Do users LigH, El Heggunte, Selur, others have full accreditation, and are now confident creators codec X265?
encoder.pw and x265.ru do NOT contain the builds based on the most recent commits.
We not only Selur's codecs are also outdated.(GNU 5.3.0)

[kypec]

He should ask: Do users LigH, El Heggunte, Selur, others have full accreditation, and are now confident creators codec X265?

They're not creators, just builders. They compile the source code which is being written (created, developed) by MulticoreWare programmers so that we (=regular users) can use x265 on our systems and encode video streams.

[Ma]

1. Where to get x265-10b.exe? I can't compile myself coz a noob here
2. How to convert o.hevc back to mkv?

You need 3 EXE files:
1) ffmpeg.exe from https://ffmpeg.zeranoe.com/builds/
2) x265-10b.exe from http://www.msystem.waw.pl/x265/ (first table, ver. 1.9+217, Minimum CPU arch AVX)
3) mkvtoolnix-gui.exe from http://www.fosshub.com/MKVToolNix.html (portable 64bit)

Let your original MKV file will be org.mkv
First you encode video:
ffmpeg -i org.mkv -v error -vf scale=384:-2 -f yuv4mpegpipe - | x265-10b --y4m - -p0 new.hevc
After a while (should be ultra fast) you will have new.hevc file with encoded video.

Then you start mkvtoolnix-gui.exe.
1) press button "+ Add source files" and choose your original org.mkv
2) second time press button "+ Add source files" and choose your encoded new.hevc
3) in window "Tracks, chapters and tags:" please move last track "MPEG-H/HEVC/h.265" to second place from top (by mouse)
4) uncheck original video track, it should looks like in attached picture
5) press "Start muxing" button
You will have "org (1).mkv" file with replaced video track. If you do this, you can see if audio is sync with video (video quality should be very low). If all is OK, you can remove '-vf scale=384:-2' from ffmpeg options and instead of '-p0' in x265 options you can insert '-p8 --crf 20' and encode to better quality (but very slow).