x265 HEVC Encoder

[Selur]

anyone found a '--pools' setting which isn't slower on single socket systems than previous '--threads X' setting?

[LigH.de]

New results with freshly built Mac binaries at tags 1.4, 1.5 and tip (1.5+175) on a Dual Xeon X5675 @ 3.07GHz (2 sockets × 6 physical cores × 2 HT = 24 logical cores):

CPU utilization rises from v1.4 (~1200%/24) to v1.5 (~1400%/24), but drops remarkably for the current version (~900%/24). Yet the speed still rises from v1.4 (4.46 fps) over v1.5 (5.24 fps) to the current (6.60 fps).

So with about a third of the CPU capacity taken by one running encoder, it is even possible to run three encoders in parallel to utilize the CPU well (up to 2400%/24).

[Selur]

But running parallel encodes requires you to have multiple files to encode, which for home users probably isn't always the case.
+ seeing that --pools wasn't used, I still hope for some user guide lines from the developers in regard to --pools

[vhelp]

if i understood this...

But running parallel encodes requires you to have multiple files to encode, which for home users probably isn't always the case.

...then, actually, its not too hard to do the parallel part. you just need to set each trim's segments begin/end and if i understood correctly, encode the one video in shorter time. then, stitch the multiple segments together into one piece. i did this a few times in the early'er days of x265 development--worked successfully.

but i don't see any speed improvements for xp and dual core processors in any of these latest builds. so i still need to use the veryfast preset when using 720x480 dimensions.

[nima2010]

hi everyone ,recently i start to use x265 for encoding ,i have some problems about it , i read lots of post ,but its like inifite post there about x265 its just makes me more confused so i ask it here
i manage to encode file with x265 gui and new ver of megui but when i check media file with mpc there isnt any info about that is 10bit or 8 bit also nothing else for rest setting too
plz tell how i can find out about encode setting from encoded file with x265
the sec problem i have is in x265 setting there isnt any selection for enabling 10 bit encode like x264 ,how i can choose what bit depth for encoding? in megui x265 setting wasnt any enable part too all is available is encoding mode and tuning
and tuning is deferent with x264 too which one of x265 tuning is good for encoding anime ?
and is it possible to replace x264 with x265 in a encoder like vafe encoder to use it with x265 instead of x264? due to vafe doesnt update anymore and i dont know how to add x265 to this encoder too
sorry if my question does related to this thread dont know where should i ask
thanks in advance and looking forward for answer

[LigH.de]

... but when i check media file with mpc there isnt any info about that is 10bit or 8 bit also nothing else for rest setting too
plz tell how i can find out about encode setting from encoded file with x265

There is a "MediaInfo" tab in the details dialog (Shift+F10). The "Format profile" should tell you about whether 8 bit depth or a higher bit dept was used, if you know how to interpret its value. In addition, there is even a "Bit depth" field a bit lower in the text table.

the sec problem i have is in x265 setting there isnt any selection for enabling 10 bit encode like x264 ,how i can choose what bit depth for encoding? in megui x265 setting wasnt any enable part too all is available is encoding mode and tuning

Well, x265 is still changing so much, that MeGUI developers did not yet decide to support it completely. And they are probably right, x265 is still not yet "mature" enough for home use. StaxRip tries to support it a bit more up-to-date now, but I don't know if it offers a selection for normal or high bit depth. Testers will probably still use command line tools.

and tuning is deferent with x264 too which one of x265 tuning is good for encoding anime ?

The set of tunings in x265 is not yet final. But x265 should be quite useful for anime in general.

and is it possible to replace x264 with x265 in a encoder like vafe encoder to use it with x265 instead of x264? due to vafe doesnt update anymore and i dont know how to add x265 to this encoder too

I never heard of a "vafe encoder" before. But it looks like a GUI specifically designed to use x264.

No, of course you cannot simply exchange x264 with x265; x265 creates a substantially different kind of video format (HEVC), compared to x264 (AVC). There is a reason why their parameters and their behaviour differ in some places: Because it is "something else". Consumer players older than a few months will probably not yet support playback of HEVC clips.

[nima2010]

thanks for responding
about media info i download media info tools too but still cant see encode setting form media info ,i upload mpc media info here
thats all i can know about hevc video

[Attachment 30668 - Click to enlarge]

[LigH.de]

Which MPC-HC version do you have? Version 1.7.8 should contain a MediaInfo version which is able to report such details. But possibly only if the HEVC video stream was created by x265; I am not sure if all other HEVC encoders out there will produce the same "completeness" of the headers.

You can also try to use MediaInfo as separate application. If you can use the CLI version, use the parameter "-f"; if you prefer the GUI version (be careful to avoid adware while installing), enable the "Advanced mode" in the Debug menu, then export the result as text, so you can post it as a CODE block here (or a link to a pastebin service).

[nima2010]

my mpc ver is 1.7.8.61 i have k lite codec 11
i test it with 2 different file but still no info ,this time i use media info tools

[Attachment 30669 - Click to enlarge]

[Attachment 30670 - Click to enlarge]

how can i get CLI or GUI ver? also what is the best encoder for x265 right now?

[LigH.de]

ZOMFG, he has a Codec Pack !!!1eleven! ... despite the fact that MPC-HC won't need any, because it uses LAV Filters. Codec packs can only corrupt your system if you don't know how to handle them carefully.

And he asks What is the best!!!1eleven! without knowing that x265 itself is the encoder, and everything else is only a user interface. Summary: It doesn't matter much, whether you use MeGUI or StaxRip or Hybrid or HandBrake or any other x265 GUI; they all only take your mouse clicks and key presses, but x265 does the real job.

By the way: VideoHelp downloads of MediaInfo will offer you the GUI version (you will find the letters "GUI" in the filename of the archives you download there). The one with a window, where you can click with a mouse arrow. (CLI would be the one where you have to type commands in a console, grey on black, you know...)

And I asked you to use the "Text" format output, and enable the "Advanced mode" in the "Debug" menu ...

[-Habanero-]

Does x265 support the use of zones like when you wanna encode the credits part of a movie with a much lower CRF or a lower bitrate weight?
How do I do this?

[Selur]

The same way you would do it with x264, but atm. you can only set either a fixed quantizer or a bitrate multiplier (no crf value).

   --zones <zone0>/<zone1>/...   Tweak the bitrate of regions of the video
                                 Each zone is of the form
                                   <start frame>,<end frame>,<option>
                                   where <option> is either
                                       q=<integer> (force QP)
                                   or  b=<float> (bitrate multiplier)

source: x265 --log-level full --help

[Gravitator]

Better to turn off the "Adaptive b-frames detsision" (visible some sort of comb).

[-Habanero-]

Thanks selur, though your advice came too late because I already started to encode my movie. I separated the film and the credits, encoding them with the same settings except different bitrate and then just combined them later.

The movie took until a few hours ago to finish at an average of 0.87 fps. God damn, and I thought 2fps with my old, overclocked computer sucked. I did --preset veryslow in 2pass mode. Goal was 811 kb/s but I knew x265 would undersize the encode based on a test with a shorter clip I did earlier, so I inputted 833 kb/s but I got 814.4 kb/s and now it's somewhat oversized. But honestly, after waiting days for this encode to finish, there's no way in hell I'm redoing it.

x264 did this too depending on number of refs so I had the exact percentage number in notepad to multiply the bitrate with.
I think this is more to do with the container overhead though, I just hope it is as consistent as x264.

Some questions about the commandline: can I use the veryslow preset but add corrections later? This is way too slow and I don't wanna use 5 refs but wanna keep other settings.

How do I turn all psy optimizations off? If my film has no noise or I'm encoding a cartoon, do I really need psychovisuals? I never used them with x264 because they made the image look worse.

Finally, does LAV decoder have any internal debanding like ffdshow? The banding isn't as bad with x264 but I'd rather it not be there at all.

[Selur]

Some questions about the commandline: can I use the veryslow preset but add corrections later? This is way too slow and I don't wanna use 5 refs but wanna keep other settings.

Sure.

How do I turn all psy optimizations off?

Hmm,.. I would say:

--rd 0 --no-psy-rd 0 --no-rdoq-level --no-psy-rdoq --no-cu-lossless

are probably the obvious choices.

Finally, does LAV decoder have any internal debanding like ffdshow?

No, LAV Decoder doesn't have an option to add dithering, MadVR does (which is a nice combination to MPC-HC).
Also to avoid banding you should:
a. remove the banding from the source if any is present
b. use 10bit encoding

[-Habanero-]

I don't wanna turn off RDO, just psychovisuals. But I will keep them on if you can convince me they're beneficial for my videos that have no noise or grain.

Can madVR be enabled for players other than MPC? There's no option in codec tweak tool to make madVR the default decoder for HEVC/MKV, only Microsoft, ffdshow or LAV.

Also to avoid banding you should:
a. remove the banding from the source if any is present
b. use 10bit encoding

At the constrained bitrates I use, banding is inevitable and 10-bit is not an option.

I have evaluated the quality of the movie and compared it to an x264 encode of the same bitrate. x265 is 16% better according to SSIM which is just at the border of being able to notice a difference and most frames have a consistently elevated score on the histogram. But SSIM is starting to show its age. On the many frames where x264 and x265 both got a similar score, x265 still looked noticeably better as well as on some scenes where x265 actually scored lower but still looked better for preserving more important details and distorting other areas in a way that didn't make them look unsightly unlike x264 which was rife with edge distortion.
We need a more modern metric. Just like PSNR was obsoleted by SSIM, we need something new this decade.

Progress is definitely here but the 20x slower encoding time is really not worth it. My movie is only 480p, not a chance in hell I'll ever encode 720p with this.
On the other hand, the MPEG-1 prototype in 1988 took 12 hours to encode and 30 minutes to decode... A SINGLE FRAME. Yet years later videos were being encoded at comfortable speeds. I have faith in the holy Techno Goddess to save us this millennium as well.

[Selur]

Can madVR be enabled for players other than MPC?

Sure, assuming your player has an option to select the renderer, there is no reason for it not to be used inside another player than MPC.

I don't wanna turn off RDO, just psychovisuals.

then try: '--no-psy-rd 0 --no-psy-rdoq', see: http://x265.readthedocs.org/en/latest/cli.html#psycho-visual-options

But I will keep them on if you can convince me they're beneficial for my videos that have no noise or grain.

Sorry, wrong user. I'm not trying to convince you that of using anything.

banding is inevitable and 10-bit is not an option.

May I ask why? Since unlike for H.264, 10bit is supported in one of the main profiles and hardware decoder support it nowadays (which was expected).

My movie is only 480p, not a chance in hell I'll ever encode 720p with this.

As a side note: the benefits of H.265 are more apparent the higher the resolution.

Just like PSNR was obsoleted by SSIM, we need something new this decade.

If you believe in metrics there are a bunch of others. (MSE, MSAD, VQM, NQI, DELTA,.. but none of them really spread outside of quality comparison tools and some academic papers, but I guess that is mainly because people are lazy and SSIM and PSNR are the easiest to understand and implement)

[-Habanero-]

Sure, assuming your player has an option to select the renderer, there is no reason for it not to be used inside another player than MPC.

I just checked, madVR is not supported for my player. It should be turned into an external decoder/splitter so any player can use it. Better yet, ffdshow should've not halted. LAV and the others don't have half the useful settings of ffdshow. Devolution... LAV doesn't even have volume normalization.

Sorry, wrong user. I'm not trying to convince you that of using anything.

I'm not interested in politics, only the truth. So far I cannot tell the difference on the limited tests I've done. I tried encoding a game platformer at a dialup bitrate with and without psychovisuals and on some frames it improved the quality while making it worse on others. I really couldn't tell if it was beneficial.

May I ask why? Since unlike for H.264, 10bit is supported in one of the main profiles and hardware decoder support it nowadays (which was expected).

Because I use bitrates that barely sustain high quality at 8-bit and 10-bit would require an increased bitrate which means I would have to lower resolution which means going back to H264 times.

As a side note: the benefits of H.265 are more apparent the higher the resolution.

I know that, but x264 has twice as better efficiency as Xvid at 720p and still 80% better at 320p despite the false stereotype of H264 being for HD only back in its early days. H265 should follow the same principle.

If you believe in metrics there are a bunch of others. (MSE, MSAD, VQM, NQI, DELTA,.. but none of them really spread outside of quality comparison tools and some academic papers, but I guess that is mainly because people are lazy and SSIM and PSNR are the easiest to understand and implement)

I don't believe in metrics anything more than their intended purpose which is measuring objective quality.

[-Habanero-]

I did a few tests on a short 4-minute game video which took almost 2 hours with x265.

Commandline:

avs2yuv "SCBW z1.avs" -o - | x265 --y4m --pass 2 --bitrate 511 --preset veryslow --stats "M:\x265.stats" --ref 16 --keyint 600 --no-psy-rd --no-psy-rdoq -o "SCBW z1.hevc" -

For this one I'm gonna have to say x264 was better quality at the same bitrate. x265 retained slightly better quality on moving objects but unacceptably blurred the static background. I tried with and without psychovisuals and I can't tell the difference.

Screenshots:
Edit: I should've subtitled them. The order is Source, x264, x265, x265psy

[Selur]

Because I use bitrates that barely sustain high quality at 8-bit and 10-bit would require an increased bitrate which means I would have to lower resolution which means going back to H264 times.

You are aware, that encoding in 10bit requires less bit rate then encoding in 8bit?
(since the compression gain due to higher precision, more than compensates the additional needed bits for the higher precision; this was true for x264 and even more is true for x265)

[-Habanero-]

You are aware, that encoding in 10bit requires less bit rate then encoding in 8bit?
(since the compression gain due to higher precision, more than compensates the additional needed bits for the higher precision; this was true for x264 and even more is true for x265)

I'm not aware of that, no. With x264 this was only true for video captures of old platformer games because the 8-bit smudging of the colors added entropy to the video making it harder to compress. This is not true for photographic videos where the extra color depth adds entropy.
With x264 I've tested this with footage of a game with 3D graphics and the 10-bit encode had stronger compression artifacts than the 8-bit one at the same bitrate. I haven't done a test with a photographic sample but I don't expect anything different. You're welcome to prove me wrong.

[Selur]

This is not true for photographic videos where the extra color depth adds entropy.

Don't mix color sampling and calculation precision!
A 10bit calculation precision should always provide better compression and thus bit rate savings compared to 8bit, if it doesn't something is broken. (and should be reported to the x264 or x265 developers)
Unneeded switching to a higher color sampling on the other hand will only cost you, unless you do it to compensate for some decoding problem.

You're welcome to prove me wrong.

Like I wrote before not interested in convincing you about anything.

[-Habanero-]

How do I encode at 10-bit? x265 automatically converts input to YV12.

M:\>avs2yuv ng2.avs -o - | x265 --y4m --crf 39.6 --preset veryslow --ref 16 --keyint 600 --no-psy-rd
 --no-psy-rdoq -o ng210.hevc -
ng2.avs: 256x224, 1008307711/16777215 fps, 2334 frames
converting input clip to YV12
y4m  [info]: 256x224 fps 1008307711/16777215 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.5+420-24fdb661bb57
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 16bpp

Like I wrote before not interested in convincing you about anything.

Clearly you are otherwise you wouldn't be telling me how great 10-bit is.

[Selur]

How do I encode at 10-bit? x265 automatically converts input to YV12.

10bit calculation precision has nothing to do with the color space. Like I wrote you are mixing calculation precision and color sampling!
Those are two different things!

here's an example of a 10bit call using raw data (not y4m wrapped):

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25 -pix_fmt yuv420p10le -f rawvideo - | x265-16bit --pools 8 --pmode --input - --input-depth 10 --input-res 640x352 --fps 25 --profile main10 --no-high-tier --no-open-gop --crf 20 --no-rdoq-level --no-psy-rdoq --colormatrix bt470bg --output "H:\Temp\test_06_23_37_5110_01.265"

Important are:
1. high bit x265 binary is used
2. binary is fed with 10bit precision raw data (there I feed it with 10bit 4:2:0 data)
3. x265 must know that it is fed with 10bit data (--input-depth 10)
(4. use a high10 or higher profile)

Cu Selur

Ps.: don't use avs2yuv so you have to figure out how to configure that properly yourself.

[poisondeathray]

You are aware, that encoding in 10bit requires less bit rate then encoding in 8bit?
(since the compression gain due to higher precision, more than compensates the additional needed bits for the higher precision; this was true for x264 and even more is true for x265)

I'm not aware of that, no. With x264 this was only true for video captures of old platformer games because the 8-bit smudging of the colors added entropy to the video making it harder to compress. This is not true for photographic videos where the extra color depth adds entropy.
With x264 I've tested this with footage of a game with 3D graphics and the 10-bit encode had stronger compression artifacts than the 8-bit one at the same bitrate. I haven't done a test with a photographic sample but I don't expect anything different. You're welcome to prove me wrong.

It's certainly true for 10bit AVC. Lots of papers and tests on this subject, objective metrics and subjective testing. Use search if you want more info. So the onus is on you to prove otherwise, because these are established facts backed by plenty of evidence.

Not as much evidence for HEVC , simply because it's newer - but early tests seem to show the same thing

[LigH.de]

The more modern and generic avs4x26x already knows how to handle "deep color" video piping to x265; avs2yuv is outdated for this use case.

avs4x26x.exe --x26x-binary "x265_64-16bit.exe" --output "out.hevc" --input-depth 16 "in_deepcolor.avs"

Brief parameter: --x26x-binary = -L (default EXE name for *.hevc output is "x265.exe")

[sneaker]

x265 hasn't been needing 10 bit input for 10 bit output for a long time. You can just replace the .exe with a high bitdepth build like you would for x264.

[Vsup]

if i understood this...

But running parallel encodes requires you to have multiple files to encode, which for home users probably isn't always the case.

...then, actually, its not too hard to do the parallel part. you just need to set each trim's segments begin/end and if i understood correctly, encode the one video in shorter time. then, stitch the multiple segments together into one piece. i did this a few times in the early'er days of x265 development--worked successfully.

but i don't see any speed improvements for xp and dual core processors in any of these latest builds. so i still need to use the veryfast preset when using 720x480 dimensions.

vhelp: can you explain how you do the trim of one video clip, encode these trim's segment using x265 and stitch them back into one clip? Thx!

[LigH.de]

Splitting a video source into segments can be done logically in the AviSynth scripts serving each encoder instance per segment. Therefore the mentioned "trim", which is the name of the AviSynth function to limit the output to a range of frames. Each encoder instance should run with the same parameters to avoid issues when joining as good as possible (some tools can be quite picky when it comes to evaluating if segments match according to their attributes). I believe e.g. RipBot264 supports segmented encoding for AVC already, adapting such a feature from x264 to x265 should be possible.

Joining the partial results may depend on the desired container and multiplexer. For a final MKV, mkvmerge should be able to append segments while multiplexing. Whether it works with HEVC segments ... to be tested. Whether MP4Box can append HEVC segments while multiplexing to an MP4 ... just as well.

[sneaker]

I believe e.g. RipBot264 supports segmented encoding for AVC already, adapting such a feature from x264 to x265 should be possible.

According to RipBot changelog it should already be supported for x265 as well.