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.)
+ Reply to Thread
Results 1 to 20 of 20
Last edited by nick1977; 17th Jun 2020 at 13:55.
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.
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!
Based on ubiquity, H.264 will probably outlive H.265. But no one really knows.
Please note that crf 20 is not the same on both h264 and 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.
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.
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.
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,...users currently on my ignore list: deadrats, Stears555
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?
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.
Last edited by blud7; 26th Aug 2020 at 15:53.
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
OK thanks guys. I'll have a play with it and see how I get on.
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?
Last edited by nick1977; 27th Aug 2020 at 05:30. Reason: incorrect text pasted in
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 .
To check to see if settings were actually passed, you can use mediainfo(view->text) on the output file
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?
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
--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.
Great, thanks again.
I'll stick to x264 for interlaced then.