Switch to x265 or stick with x264?

[nick1977]

I'm after opinions here, so feel free to share your ideas and experience.

I've got a very large media collection, mainly in DVD and Blu-ray format. Over the past few years I've been progressively adding them to my PC media player. I now have a newer TV which supports 4k and I'm using PLEX for playback.

Up until now I've used Handbrake with Very Slow preset x264 and crf 18 for DVD and 20 for Blu-ray.

These settings have given me (mostly!) good size reduction, and quality that's indistinguishable from the original in normal playback.

However now that I can playback x265 with my TV, I'm considering switching.
A recent TV show I've started to rip has episodes that are around 9gb. My crf 20 very slow conversion to x264 is only bringing it down to around 4gb. This would mean the whole series would take about 300gb.

I've experimented with x265 on medium preset and 10bit and that brings it down to around 2.2gb. I can't see any obvious quality loss and the encode takes roughly the same amount of time. However I'm conscious that the TV I have currently is a cheap 49" one, and my plan is to get a bigger OLED in the next 12 months or so.

I suppose what I'm wondering is, is there going to be a noticeable difference in quality between x264 very slow and x265 medium, when I upgrade to a bigger / better screen?
Also, if anyone has any other x265 tips or recommendations, I'd like to hear them (even if it's upgrading processor or graphics card to get hardware encoding option.)

Thanks!

[sophisticles]

I personally like x265 a lot, it absolutely kills x264 at the same bit rates, but that's to be expected considering that HEVC is a much newer standard than AVC. Having said that, I have stopped encoding anything, I have been playing around with AV1 and despite the atrocious encoding speeds and pathetic decoding, it does show a lot of promise and since NetFlix and Intel seem to have partnered up to improve SVT-AV1, I have decided to wait to see where that goes.

Not to mention that some of the work being done on libaom seems to be getting backported to libvp9, so VP9 is becoming very interesting suddenly.

My vote is if you absolutely feel you have to encode now, go with x265 over x264 but if you can hold off for a couple of years, then wait.

[nick1977]

Thanks for sharing your thoughts - very interesting.
I'm not in the same mindset as you in some respects, as I certianly don't want to wait another 2-3 years as I've already done over 450 films and many TV episodes at x264. There'll always be something bigger and better around the corner, but x265 is now pretty well established so I think it's only right to consider it. I've been happy with x264 on very slow preset, but even with a large storage drive, the number of files I have take up a signifcant amount of room.

I'm never saying never to going back and reconverting everything, but for now, I'm just considering whether I could shave some of the size off future encodes whilst maintaining the same (or better) quality in comparison to my x264 encodes.

Processing x265 on anything "above" medium makes the time taken impractical (and I'm a patient guy!) so I'd just like to know if an x265 medium at crf 20 will look the same or better than an x264 very slow at crf 20.
I've done a fair bit of googling, but most articles seem to focus on speed and filesize, which I can easily see for myself.If anyone knows of any tests that show image quality for relative presets in comparison to x264 please do share!

Thanks

[smrpix]

Based on ubiquity, H.264 will probably outlive H.265. But no one really knows.

[sophisticles]

Based on ubiquity, H.264 will probably outlive H.265. But no one really knows.

What's really hurting H265 as a whole is the whole patent mess that surrounds it.

[blud7]

Please note that crf 20 is not the same on both h264 and h265.

[nick1977]

Please note that crf 20 is not the same on both h264 and h265.

Thanks, yes that's something else I've picked up over the last couple of days. Is there a generally accepted equivalent of what crf 20 in h264 is in h265?
It's tricky this, as I've tried a medium x265 with crf20 but don't have a good enough display to know if it is better or worse than Very Slow x264 at crf20. I'm happy with the speed of encode and the filesize, just would like some picture quality comparisons to know what the difference is. Like I said, most comparisons I've found are based on time to encode and filesize, which are easy enough to test myself.

[ProWo]

H.264 current video standard, good quality, reasonably fast encoding, plays smoothly on most devices and players.
H.265 better quality at the same bitrate, but slower encoding, gives problems when playing back on many devices and players.

[KarMa]

Not to mention that some of the work being done on libaom seems to be getting backported to libvp9, so VP9 is becoming very interesting suddenly.

Meh, VP9 was pretty good years ago when doing my own testing. VP9 has been a valid alternative to H.265 for years now with more appealing detail retention and artifacts, at least with default/preset settings. Along with better device support over h.265.

[sophisticles]

Not to mention that some of the work being done on libaom seems to be getting backported to libvp9, so VP9 is becoming very interesting suddenly.

Meh, VP9 was pretty good years ago when doing my own testing. VP9 has been a valid alternative to H.265 for years now with more appealing detail retention and artifacts, at least with default/preset settings. Along with better device support over h.265.

VP9, specifically libvp9, is very exciting, and an encoder to keep your eyes on. If you look at the recent builds of ffmpeg with libvp9 support and look at libaom, it seems that many of libaom's features are being backported to libvp9 and in fact I found an entry in git for build of libvp9, not yet found in ffmpeg, that supported 7 different AQ versions, including something called PSNR_AQ and PERCEPTUAL_AQ.

[Selur]

Never could find any use for VP9 since it was way to slow to be useful and didn't give me really good results.
AV1 itself does look way more promising to me especially the noise handling features,...

[nick1977]

Hi all

I'm resurrecting my thread as I noticed something interesting the other day and I am curious to others opinions.

I started to encode another one of my TV shows. Original file is Bluray at around 9gb for 45 mins.

First attempt was using x265 10-bit, Medium preset, crf 20.
This produced a file that was around 3gb, but when looking at a few shots I was sure there was softening being applied.
Comparison to the original file showed my suspicions to be correct.
As I was using an extra line in handbrake which apparently stops smoothing (--selective-sao 0 - - no-sao) I tried again without that line. The file came out a fraction smaller but looked no different to my eyes.

I then tried my x264, Very slow, crf 20 encode.
It came out around 4gb, and was pretty much indistinguishable from the original file.

Could it be down to VLC decoding?
Poor settings in Handbrake?
Poor choice of encoder?
Or is it just not possible to get equivalent quality from x265?

[blud7]

Something about Handbrake still using an 8-bit pipeline when encoding to 10-bit?
Also for Blu-Ray source you can try crf 22-24 with x265.
Also video card settings can affect you playback quality, the have settings for denoise, deinterlace etc.

[poisondeathray]

Hi all

I'm resurrecting my thread as I noticed something interesting the other day and I am curious to others opinions.

I started to encode another one of my TV shows. Original file is Bluray at around 9gb for 45 mins.

First attempt was using x265 10-bit, Medium preset, crf 20.
This produced a file that was around 3gb, but when looking at a few shots I was sure there was softening being applied.
Comparison to the original file showed my suspicions to be correct.
As I was using an extra line in handbrake which apparently stops smoothing (--selective-sao 0 - - no-sao) I tried again without that line. The file came out a fraction smaller but looked no different to my eyes.

I then tried my x264, Very slow, crf 20 encode.
It came out around 4gb, and was pretty much indistinguishable from the original file.

Could it be down to VLC decoding?
Poor settings in Handbrake?
Poor choice of encoder?
Or is it just not possible to get equivalent quality from x265?

Was x264 8bit or 10bit?

4 vs 3 gb - It's not a great comparison if one version uses 1.33x more bitrate.

For a typical TV show, in the old days people would use something like --tune film for x264 . But there is no film tuning for x265. So many people tend to use a modified lower tune grain setting for x265. So in addition to adjusting --selective-sao 0 --no-sao , lower deblock values (negative values, like -3 or -4; if you recall --tune film for x264 also used negative values) and increase --psy-rd and --psy-rdoq , but lower than 4 and 10 used in the grain preset

Something about Handbrake still using an 8-bit pipeline when encoding to 10-bit?

This won't affect direct encoding of 8bit source to 10bit encoding

[nick1977]

OK thanks guys. I'll have a play with it and see how I get on.

[nick1977]

I think I might have made a bit of an error before.
I was putting the line --selective-sao 0 --no-sao into the "Advanced options" box in Handbrake Video tab.
I thought the resulting filesize was different, but on further inspection it made no difference at all.
Am I using the notation correctly, or should I be using a different format for Handbrake to apply the parameters to the encode?

Thanks

[poisondeathray]

The --option notation syntax format is for x264 and x265 CLI

HB syntax for the advanced options in the GUI are listed with key=<value> separated by colons .

option1=<value>:option2=<value>

it would look like this

no-sao=1:selective-sao=0

To check to see if settings were actually passed, you can use mediainfo(view->text) on the output file

[nick1977]

Thanks poisondeathray.
That has improved things considerably. I can't believe I was applying that code up until now and it wasn't actually doing anything.
I've also tried changing the crf to 22 and can't see any obvious difference, so thanks to blud7 for that tip too

Looks like I'll be doing a lot more x265 stuff now!

One other question if anyone knows, as it's closely related - is there support for interlaced video in x265?
I used to use tff=1 for x264. Is there an equivalent?

[poisondeathray]

One other question if anyone knows, as it's closely related - is there support for interlaced video in x265?
I used to use tff=1 for x264. Is there an equivalent?

It' s not recommended to use interlaced encoding with x265. It has to be implemented properly in decoder side as well, and often it's not. Currently it can work... but it's full of issues more often than not. Stick with x264 if you need interlaced (MBAFF) encoding

https://x265.readthedocs.io/en/latest/cli.html

--interlace <false|tff|bff>, --no-interlace

        progressive pictures (default)
        top field first
        bottom field first

    HEVC encodes interlaced content as fields. Fields must be provided to the encoder in the correct temporal order. The source dimensions must be field dimensions and the FPS must be in units of fields per second. The decoder must re-combine the fields in their correct orientation for display.

[nick1977]

Great, thanks again.
I'll stick to x264 for interlaced then.

[M.Shiver]

It remains apparent how fast x264/avc handles transcodes at very decent quality and acceptable file size, also on somewhat more modest systems.

I"ll tell you more about my findings of the performance aka conversion speed of x265/hevc after my new laptop has arrived