HEVC encoded files future safe?

[Dschee]

Hi, I'm currently encoding a movie to the HEVC format using Handbrake and the results are quite impressive! 2:30 h of a movie in 1080p just about 3 GB. Using VLC (2.1.5) the file plays very well on my Mac, so here's my question:

Apart from the fact that encoding takes very long (14 h of encoding for a 2:30 h movie on my Mac) is there any disadvantage in already encoding movies like this first one now?
I mean, everybody is saying that x265 isn't finished and one should only use it for demo purposes but as long as everything seems to work fine for me, I don't see why not to encode a few movies already when I have the time for it, or is there any reason not to do this?

Especially this question includes the following:
Will files I encode now stay playable with feature versions of VLC (they also use x265) when it is playable now? Or how probable is it?
Will the efficiency in terms of file size improve significantly over the time as well (although it is already near the goal of half the size)?
Or is it (like I suppose) that people just don't recommend it because it is very slow to encode and might have quality issues / bugs during encoding that could lead to a crash?

Love to get more info on this. Thank you in advance. =)

[s55]

Will files I encode now stay playable with feature versions of VLC (they also use x265) when it is playable now? Or how probable is it?
Will the efficiency in terms of file size improve significantly over the time as well (although it is already near the goal of half the size)?

Running something that's very much beta does have it's risks. Non-complaint spec bugs are a risk at this point so while it seems pretty unlikely, they should still play.

x265 is still very on in it's development life. Right not, it doesn't offer much in the way of improvements over x264, especially when you use slower x264 settings, the different is minor. I expect it'll get a fair bit better once they've implemented all the various features that are still not done yet. I don't however expect it'll live up to all the marketing hype. It'll be a nice improvement, but nothing so earth shattering as the marketing guru's would have you believe.


My personal opinion is hold off a year and let this thing mature a bit more. You can always re-encode later.

[Dschee]

Thank you for this assessment, s55. I'll keep that in mind and wait a bit more – but as long as the software is not officially called at least "beta" but more likely "stable" people will always tend to say "wait a little bit longer". I already thought about using x265 half a year ago but at that time I couldn't see any advantage. Now things have already matured quite a bit more and I see some improvement already, so I thought about it again.

But as you are saying that "slower x264 settings" can lead to similar results I got curious: With which settings in Handbrake could I manage to get similar quality for the same file size? Can you give me an example configuration for 1080p where I want to reach a very good quality of around 20 with a file size as small as possible (hopefully about 3GB like with x265) for a 2:30 h movie?

[Deleted User 11865]

A "quality of about 20" means nothing.

Depending of which settings you use, a given RF (say, 20) will give a (slightly or wildly, again dependent on settings) different quality (even using using the same encoder in both cases, i.e. x264).

Assuming than x265 RF 20 and x264 RF 20 result in the same quality is even more of a stretch, by a large margin.

Comparing compression efficiency by using CRF ratecontrol and then comparing file size is not reliable (or often, even remotely feasible).

[JohnAStebbins]

One method you could use to get some feel for how x265 compares to x265 would be to lower the RF until artefacts are clearly visible. Adjust the RF of each encoder so that an encode from each encoder looks equally artefacted (i.e. use your eyes instead of relying on a magic RF value). Then have a look at the resulting bitrate of the output. I would also use x264 slow or slower preset since x265 is extreemly slow and it is only fair to allow x264 the same amount of time to mull things over as x265 is taking.

I also recommend starting with a high quality source, e.g. bluray (or better) input.

[Dschee]

Thank you rodeo and JohnAStebbins. I've now done a more detailed comparison. Here's its documentation:

x264 vs. x265

Used Handbrake Version:
Version 6268svn x86_64 (2014080601) ~ self-compiled with '--enable-x265‘ option

Test System:
Mac with 2,4 GHz Intel Core i7, 8 GB 1600 MHz DDR3 and Intel HD Graphics 4000 1024 MB

Source File:
Interstellar (2014) Trailer #3 [4K] ~ https://www.youtube.com/watch?v=ly-az-ndyn0

Source File Info:
4K (4096x1716), 24 fps, H264 (AVC), 2:19 min --> 199,1 MB

Output Configurations & Results:
all (x264 & x265): 1080p (1920x804), same as source (variable framerate), Auto 0/0/0/0 (crop)
all x264: film (tune), main-4.1 (profile-level), veryslow (preset)

#1: x264 (codec), CRF: 20 >> 66,6 MB in 382 sec (~ 8,7 fps)
#2: x265 (codec), CRF: 21 >> 37,2 MB in 795 sec (~ 4,2 fps) >> file size: -44%, encoding time: +107%
#3: x264 (codec), CRF: 28 >> 22,9 MB in 292 sec (~ 11,4 fps)
#4: x265 (codec), CRF: 30 >> 12,8 MB in 640 sec (~ 5,1 fps) >> file size: -44%, encoding time: +122%

The CRF20 in x264 and CRF21 in x265 seemed to have visually comparable quality to me. Same is true for CRF28 in x264 and CRF30 in x265.

Results (August 2014):
The x265 encoder saves 44 percent disk space for 1080p movies compared to the 'veryslow’ preset of the x264 encoder. The x265 encoder needs 115% percent of additional encoding time compared to the 'veryslow‘ preset of the x264 encoder.

Conclusion:
The x265 encoder already has a significant better compression rate (nearly half the size which is exactly what "the marketing hype“ is about) but also needs significantly more time to reach that (more than twice the time).

This test confirms my first impression that the compression is already much better but there’s still a lack of performance. I hope this comparison makes more sense. My personal prediction is that the compression rate will only improve slightly until finalization of x265 but the performance will improve significantly to only need 30-50% longer than x264. But only time can tell.

I’ll see if I can upload the encoded files somewhere and link them here so you can compare their quality.

[s55]

Your test is still not a valid comparison.

[JohnAStebbins]

Your claims would be better supported if you also supplied links to screenshots of same sample frame in source and encodes and links to the source and encoded videos.

We are dubious because people that are more knowledgable than you have concluded that x264 still beats x265 in quality.

[Dschee]

I have no idea about the details of encoding (although I have read a lot already, but nothing in depth). I just try to find the most efficient way to encode my videos and currently I get the best results with x265. If one of those "more knowledgable" people could tell me how they got better results with x264 than I would be happy and just use those. But for now, I can't get anything better using Handbrake than with x265.

Thank you for your unbelievably helpful comment, s55. It really tells me a lot about what I did wrong in my comparison.

@JohnAStebbins: Yeah, I'm still converting and trying different configurations (and am always getting better results with x265 although it takes longer). I've created a Dropbox folder where I put all the files in where you can check the encoded files: https://www.dropbox.com/sh/vt2qatd6x75a ... cdON5a?lst

I hope this helps to clarify things. Thank you for your patience.

[Deleted User 11865]

The proper way to compare compression efficiency is to use two-pass average bitrate and looking at the output (psychovisual optimizations have rendered objective metrics somewhat less relevant than they used to be), so that the rate control has the same target.

The problem with CRF is that the output quality varies depending on the settings. "RF X w/x264 looks about the same as RF Y w/x265" is that it's quite approximative (for all you know, you might wake up tomorrow, do the test again, and decide "seems like RF X + Z w/x264 looks looks closer to RF Y w/x265 than RF X after all".

With ABR, you can look at the video (must be the exact same source, with all settings except video encoder and its parameters being identical) and determine (more less, but certainly more than with the previous method): encoder A provides higher quality (and therefore better compression efficiency) than encoder B at rate R. This will still be true when using CRF encoding, except ABR makes the actual comparison much easier and more accurate than above.

To sum up: CRF is good for consistent quality when encoding, but sucks for comparisons; ABR is great for comparison but gives inconsistent quality across different sources.

Of course such comparisons are not possible yet, since x265 does not yet have 2-pass ABR rate control (at least in the version we currently ship in HandBrake, which BTW does not have psychovisual optimizations either).

[TechnoPhil]

I have no idea about the details of encoding (although I have read a lot already, but nothing in depth). I just try to find the most efficient way to encode my videos and currently I get the best results with x265. If one of those "more knowledgable" people could tell me how they got better results with x264 than I would be happy and just use those. But for now, I can't get anything better using Handbrake than with x265.

Thank you for your unbelievably helpful comment, s55. It really tells me a lot about what I did wrong in my comparison.

@JohnAStebbins: Yeah, I'm still converting and trying different configurations (and am always getting better results with x265 although it takes longer). I've created a Dropbox folder where I put all the files in where you can check the encoded files: https://www.dropbox.com/sh/vt2qatd6x75a ... cdON5a?lst

I hope this helps to clarify things. Thank you for your patience.

Hi there,
I am trying to encode the original trailer you posted in DropBox into x265 with the new stable version of HandBrake.
If the extension of the file is .mp4 VLC cannot work (unknown video format "hev1").
If the extension of the file is .mkv VLC cannot play correctly (video flickering etc).

What are the suggested settings for a correct x265 encoding using HandBrake 0.10 ?

Thanks!

[Ritsuka]

You need to use VLC 2.2 or 3.0 . They forgot to include h.265 support in the current mac version.

[TechnoPhil]

You need to use VLC 2.2 or 3.0 . They forgot to include h.265 support in the current mac version.

Many thanks for your help,
but I tried VLC 2.2 or 3.0 and both are not working!

If I play the h265 videos linked in DropBox above, VLC works perfectly, so it is probably my fault using HandBrake's settings.

Have you ever tried to encode in h265 with HB 0.10 stable?
What are the settings you use?

[TechnoPhil]

Anyone can help me?
It is not possible to encode and mkv h264 into an mov h265 with the new version of HandBrake 0.10.

HB converts without problem, but the file is not playable (with VLC or MPlayerX)!
I use these settings:

https://imageshack.com/f/p5S05p2Vp

Thanks!

[Ritsuka]

h.265 inside mp4 works for me in VLC 2.2 and 3.0.
And by forum rules, Activity Log is required for support requests.