Convert x264 to x265 ?

[Nico8583]

Hi,

I have a movies collection, all encoded by me from Blu ray to x264 CRF 18 and I would like to try to convert 1 or 2 movies into x265 in order to know if there is an interest for me to convert all my movies.

Are there importants parameters to use to convert x264 to x265 ?

My x264 parameters are simples :
"Movie.avs" --preset slower --tune film --profile high --level 4.1 --crf 18 --open-gop --keyint 24 --qpfile "Chapters.qpfile" --output "Out.264"

Thank you !

[Jamaika]

... is an interest for me to convert all my movies.
The interest isn't for you. This is useful for files RAW, DNG, ProRes.
My x264 parameters are simples :
"Movie.avs" --preset slower --tune film --profile high --level 4.1 --crf 18 --open-gop --keyint 24 --qpfile "Chapters.qpfile" --output "Out.264"
Little information. How is size frame, bitrate?
For FullHD you can convert with min. bitrate 4500. It can't be too high dynamics of the film. The video with depth 8bit can has banding. Not all players work with 'open-gop'.

[littlepox]

As far as I can recommend:

1. Re-encode will always worsen the quality unless you enable --lossless, which in this case, you won't. If you wish to try, get the blu-rays back again and re-encode from them.

2. The parameters you were using for x264 are good enough; the only suggestion is that you should make --keyint much bigger, say 250(default by x264). --keyint 24 is for blu-ray disc compatibility(say, you are making blu-ray discs to be played on your PS3) and NOT for re-encode. Setting it too small results in a big reduction in efficiency.

3. Currently, x265 is doing extremely bad @ high quality. It does gain some advantage in low bit-rate settings, where all you care is whether you can still watch it without saying "am I watching a video recorded by a ten-years-old handphone?". And if you care a bit of the quality, you'll get disappointed by the washed output, with all details and film-grains gone. If you are expecting a similar quality to your x264 products, I'd suggest not to waste your time.

[Nico8583]

Interest for me is not quality but file size with an equal quality.

Size frame is Full HD, bitrate is give by CRF 18. Movies are played on PC or Android.

[littlepox]

If the "equal quality" means the quality is equal to x264, crf=18
then you'll probably need 200%~300% of the bitrate for x265.
If you are encoding with x264, crf=28
then switching to x265 gives you a discount in size without sacrificing the quality.

[Nico8583]

Thank you :)

1. It's too long to rip BD again, so I would like to use x264

2. It's not the subject but what is the impact of keyint ? Efficiency with quality or file size ?

3. Ok it's clear ;) I want quality so x265 should not be a good way for me

[littlepox]

Keyint determines the maximum distance between two IDR frames.

An IDR frame is an independently encoded frame; the encoder must encode it without referencing to other frames. It's usually used at the beginning of a new scene, where the 1st frame has nothing to do with the previous scene. And its following, similar frames can refer to it; only the differences will be captured when encoding subsequent frames.

When you encode an IDR frame, it's bit-rate expensive: Having zero information from other frames is a penalty at encoding, while allowing longer distance lets the encoder enjoy the benefit by setting more frames to be non-IDR, and those frames can be encoded in higher efficiency.

x264 sets the default value to be 250. on a 25fps movie, it means two IDR frames can be at most 10 seconds away (it can be smaller than 10 seconds, x264 will judge it properly, so it's possible two IDR-frames are very close if scenes change very quickly).

If you set it to 24, that means every second there must be an IDR-frame. Do you expect your movie to change the scene every one second? If not, IDR frames inserted by compulsory limit does a harm to the encoding efficiency. On blu-ray discs this is not a serious problem, as they have enough spaces to waste. But is it true for your hard drive?

[Nico8583]

Ok thank you for these informations.
So a low value increase file size but don't affect quality ?
I'll made a test to compare file size between 240 and 24 keyint, I'm curious :-D

[birdie]

Hi,

I have a movies collection, all encoded by me from Blu ray to x264 CRF 18 and I would like to try to convert 1 or 2 movies into x265 in order to know if there is an interest for me to convert all my movies.

Are there importants parameters to use to convert x264 to x265 ?

You won't gain anything by using x265 if you want the same picture quality as x264 at CRF 18. None. Just forget about this altogether.

[Nico8583]

I believed x265 was more efficient in file size with the same quality, fortunelaty I've asked to you ;)

[birdie]

Believe what you want but there are hundreds of screenshots posted at these forums which show that at least for high-quality high-bitrate encodes x265 is actually worse than x264.

I didn't mean to laugh and I don't understand your stance.

[foxyshadis]

It's more efficient (but much slower) at lower bitrates, the lower the better. It requires a lot of argument tweaking at high bitrates just to match x264 and can't really exceed it (because fine film grain is impossible to compress much better). If you're looking for small files without much grain, you're its target market.

x265 --preset medium or --preset slow is probably all you need, but if you can live with slower, that's fine. Note, it's --tune grain not --tune film; x265 doesn't exactly match x264. Don't bother with --keyint, the only reason to reduce it is for faster random seeking (at a cost of a few % of size) or bluray compat (obviously impossible right now), otherwise x265 will place keyframes optimally as it is. Do NOT set --profile high unless you know why; main and main10 are equal to AVC's high and high10. Likewise, do NOT set level or open-gop. x265 will figure out the minimum level for you, probably 4 instead of 4.1, so you'd be unnecessarily restricting playback.

You can denoise, encode, and then use your player to create random noise, to save even more bitrate.

Sometimes I feel like I'm one of the few people at Doom9 who doesn't want perfect reconstruction of grainy movies. There's a place for that, but a lot of people here are unnecessary down on something that wasn't really made for their needs, and actively try to dissuade people with other needs from using it.

[ARRYMatie]

I don't like grainy movies either but with x265 unless you really up the grain, there'll be noticeable banding in certain areas (mainly darkish ones).

[Nico8583]

I give up my idea, I didn't know all this, thank you for the informations and advices ;)

[Nico8583]

Just an information for x264.

I have made a test with keyint 24 and keyint 240, same movie, same source, CRF 18.

File size with keyint 24 : 12.1 GB
File size with keyint 240 : 11.5 GB

So for this movie, difference is 600 MB so about 5%.

I'll made a test with an other movie to see.

[littlepox]

Should you are interested, you can set keyint=0. 0 means unlimited distance and x264 will insert IDR frames purely based on scene change.

[Slitheen]

I did what the OP wanted to do. Reencoded some x264 encodes into x265.

The result was about half the size or less of the x264 file and the quality of the x265 file was about the same, certainly good enough.

There you go...

[Metaphor]

^^ Its hard to make such generalizations about quality, because all of our environments are different.

For you it may seem that viewing x265 on a 24" TN LCD might seem like you get comparable quality, while others here are comparing the most minute detail degradation because they are concerned about vieing on a 160" projection screen or having archival quality or are talking about the academics of compression.

For many casual users who like to tinker with compression, x265 is starting to gain traction (slowly). For the hard core and pedantic compression guru's you will still often hear of how far x265 has to go.

Neither are incorrect, mind you.

I'm using x265 myself and willing to accept the compromise that matches my needs. I want good quality, 10bpc, and am willing to use a higher CRF and dont really care than I'm not getting "some promised 50% bitrate savings" and even if in still frame analysis there is an advantage in x264 (sharpness, Edge detail, etc) I dont see it in enough to dissuade its usage my real world environment (from Monitors to 75" Displays).

So I'm happy enough to use it for my library, as well. We just cant say that its good enough for everyone yet, as it will only be good enough for everyone, once everyone decides that for themselves.

[blublub]

Hi, just a quick question if I am understanding thuys correctly:

If I used to do high quality encodes with CRF 17 under x264 there is no reason to switch to x265 (v 1.8) and use CRF 18-20 even if the resulting file size is a little smaller because x265 looses on detail in most film content on usual bluray movies.

Correct?

[Sharc]

Maybe it has been said already:
If you re-encode an x264 file with x265 you will always introduce additional losses whatever you select the settings of x265. You re-encode a lossy source with another lossy encode, so in very best case you get "almost same" quality as the x264 "original".

[blublub]

Maybe it has been said already:
If you re-encode an x264 file with x265 you will always introduce additional losses whatever you select the settings of x265. You re-encode a lossy source with another lossy encode, so in very best case you get "almost same" quality as the x264 "original".
Form reading this Thread I thought the title was picked wrong and the author was talking about original content to x264 and x265 in comparison which is better - so latter that was my question.

[blublub]

Ok found a more suitable thread for my question thx

[movmasty]

When you encode an IDR frame, it's bit-rate expensive: Having zero information from other frames is a penalty at encoding, while allowing longer distance lets the encoder enjoy the benefit by setting more frames to be non-IDR, and those frames can be encoded in higher efficiency.
You forget that the more a P-B frame is near to an I frame, the less new blocks have to be encoded, because more block come from the near I frame, and blocks from Keyf are of higher quality,
So raising the I frames doesnt necessarly bring up size...sometime there could be a size reduction, certainly a quality increase.
I have made a test with keyint 24 and keyint 240, same movie, same source, CRF 18.

File size with keyint 24 : 12.1 GB
File size with keyint 240 : 11.5 GB

So for this movie, difference is 600 MB so about 5%.
...And that difference goes in higher quality, it isnt wasted, more I blocks, remember that I frames have lower quantizer.

From an extreme to another, you should test what happens in between, maybe size goes down lowering from 240 to 200 and then rises again from 200 to 24,

IMO the best Keyint is around 150 (that is only 0,66% of frames!), 6 seconds, that permit that only few new blocks have to be encoded in P_B,
and to have even more I frames without to bloat the movie, raise the scenecut to 50/60 or even more(after a short test), so every change will have its KF and inter frames will take less time/size to encode,
This is efficiency.

Then there is the seekabily advantage, not a small one for big screen movies
I am happy when my encodes have a Key every 60/80 frames(with keyint 150)

[movmasty]

Maybe it has been said already:
If you re-encode an x264 file with x265 you will always introduce additional losses whatever you select the settings of x265. You re-encode a lossy source with another lossy encode, so in very best case you get "almost same" quality as the x264 "original".
x264 is pretty smart at encoding(Xvid almost as, not like mpeg1-2), so the quality loss for a recode is very small, while size goes down, an x264 encode act like a smart smooth filter.

[movmasty]

It's(h265) more efficient (but much slower) at lower bitrates, the lower the better. It requires a lot of argument tweaking at high bitrates just to match x264 and can't really exceed it (because fine film grain is impossible to compress much better). If you're looking for small files without much grain, you're its target market.HEVC won't gain you much at all at that resolution though; it barely even gains much at 1080p. It's tremendously better than x264 at 4K and up, but that's worlds away from 480p.
Now, this seems a contradiction to me, would you please explain?

HEVC looks better at low(er the better) bitrates and very high bitrate,

What happens in the middle :confused:

[Asmodian]

There is no contradiction, the second quote says nothing about bit-rate, only resolution. At very high bit-rates I still like H.264 better, both look good but HEVC smooths a bit more.

Low or high bit-rate is relative to resolution. 1 Mbps is a high bit-rate for 240p but a low bit-rate for 1080p. Using HEVC instead of H.264 would not help at all for 240p at 1 Mbps but it would look much better for 1080p at 1 Mbps (but still not great).

HEVC smooths more than H.264 even at similar bit-rates so more fine detail and grain is lost when using HEVC at medium and high bit-rates. At higher resolutions fine detail and grain covers more pixels so this effect is perceptually less significant with high resolutions. Right now HEVC is great for 4K but is not much of an improvement over H.264 at lower resolutions unless using low bit-rates where its smoothing looks better than H.264's blocking. I would not use HEVC, as it is now, for any resolution 1080p or below unless using bit-rates so low H.264 starts blocking.

[movmasty]

Well, now 1920x1080 has grown to "low resolution" with tiny details...:eek:
Dont think that 4k will ever be a standard for home users, isnt a producers standard?
Even 1080 is too big for me, dont see any advantage over 720 or even 576.

I see much material around encoded with HEVC, i dont dislike smoothness, like low br, and a new pc is coming, so I'd like to give it a try as soon as possible,
so what is the fastest app right now? Toolnix mod?
And i see also that Doom's Guru dont like the HEVC projet?

One question, x265 hasnt ways to adjust smoothness like psy in x264?

[foxyshadis]

...And that difference goes in higher quality, it isnt wasted, more I blocks, remember that I frames have lower quantizer.

Wait, you can never say that just because it has more I-frames it has more quality. Despite the higher quantizer of P-frames, they can easily increase quality simply by allocating lots of bits to small residuals despite a higher base quantizer... or they can decrease quality if the rate-control doesn't favor them, as in DivX 3 and Indeo codecs. I-frames on their own have to shave off significant quality just to fit in a bit-budget that's assumed to be made up by the P-frames. It all has to do with the rate control of the encoder, there's nothing inherent about quality by favoring size or keyframe length; you should be able to have the exact same quality with one single keyframe at the start. You can rationalize any keyint you want, but in the end it's only about seekability or error recovery time if rate-control doesn't suck.

[foxyshadis]

One question, x265 hasnt ways to adjust smoothness like psy in x264?

It has lots of ways. psy-rd is there just like x264; you can see it's been discussed heavily throughout the last 50 pages. i64x64 is disabled to prevent over-smoothing now. You can disable 32x32 DCT entirely to force it to concentrate on noise. Alternately, you can use nr to smooth it more. It's all there in the docs.

If you're happy with less detail, then HEVC will let you reduce the size, though it gains less at smaller resolutions because there's less "fat" to trim. You can make full HD look like SD with half the bitrate with a little smoothing, versus x264 with its tiny transforms... whereas to save significant bitrate with SD, you'd have to make it look like 240p plus a bit, do you really want to watch that? If not, do you really want to spend ten times more for a negligible effect? You should figure out what detail level you actually need before you encode, then resize down to that so you don't waste your hours encoding.

[movmasty]

you should be able to have the exact same quality with one single keyframe at the start.
I knew this, but i bet that the size would be higher, i know that P frames could be as large as I, but there you will stay better with an I,
The I-P-B thing is smarter than at first sight,
the new intra blocks are moving pixels, its ok to compress them more
but to make that true you need a little bit more KF,
i found the hot spot at 150 and higher threshold.
You can make full HD look like SD with half the bitrate with a little smoothing, versus x264 with its tiny transforms... whereas to save significant bitrate with SD, you'd have to make it look like 240p plus a bit, do you really want to watch that? If not, do you really want to spend ten times more for a negligible effect? You should figure out what detail level you actually need before you encode, then resize down to that so you don't waste your hours encoding.And i see also that Doom's Guru dont like the HEVC project :devil:

After all the great improvement of x264 over Divx is not just a smooth thing.

[birdie]

No one here dislikes x265, it just hasn't matured yet.

It took XVid and x264 several years before they could beat previously existing codecs, and, even then when XVid fully matured and became more or less de-facto for the scene, it still couldn't beat MPEG2 under certain conditions.

You'll be even more surprised to learn that under certain conditions no existing codec can beat ages old MJPEG which has no notion of interframe optimizations. The problem is you cannot compress real life noise effectively.

[foxyshadis]

I knew this, but i bet that the size would be higher, i know that P frames could be as large as I, but there you will stay better with an I,
The I-P-B thing is smarter than at first sight,
the new intra blocks are moving pixels, its ok to compress them more
but to make that true you need a little bit more KF,
i found the hot spot at 150 and higher threshold.
In every case I've ever tried with xvid, x264, and x265, less keyframes only meant smaller size, never more or less quality, because their rate control works well enough. And since I like to push them to 500+ frames, I've checked several times.

And i see also that Doom's Guru dont like the HEVC project :devil:

Aside from making some Blu-rays, I haven't used anything but HEVC in over a year, and I've experimented with the codebase since the earliest jct-vc days. I just want to tell the truth, instead of marketing slogans that are going to disappoint people working with 480p instead of 2160p.

[movmasty]

In every case I've ever tried with xvid, x264, and x265, less keyframes only meant smaller size, never more or less quality, because their rate control works well enough. And since I like to push them to 500+ frames, I've checked several times.

Often one sees what he wishes.....but to lower I frames from 0,4% to 0,2% because they are non inter compressed seems a very rough argument
size could be smaller because of the automatic higher quantizer on inter frames, and you are using an high bitrate so this isnt noticeable,

but at lower bitrates and preserving the I frame quality, size goes down with more I frames,
because this lower bitrates comes from more compression of inter frames,
and this is made possible by the fact that only fast moving pixels are encoded to P-B.

[Asmodian]

Often one sees what he wishes.....but to lower I frames from 0,4% to 0,2% because they are non inter compressed seems a very rough argument
size could be smaller because of the automatic higher quantizer on inter frames, and you are using an high bitrate so this isnt noticeable,

but at lower bitrates and preserving the I frame quality, size goes down with more I frames,
because this lower bitrates comes from more compression of inter frames,
and this is made possible by the fact that only fast moving pixels are encoded to P-B.

This really depends on the content, without a lot of motion or scene changes this isn't true, in my experience. So much of this is very content dependent so tests using one type of content can lead to incorrect conclusions when encoding different types content.

And i see also that Doom's Guru dont like the HEVC projet?

I like x265 and will continue to test it for my encoding needs, right now when targeting visually lossless bluray rips I still prefer x264 but x265 is very good. I don't mind throwing a few more bits at it to get transparent encodes. Also, I only have an overclocked 5960X so x265 still feels pretty slow. :(

It was the same situation when x264 was young, if size was not a major issue Xvid could offer better quality at the same size, especially when encoding time mattered. Now that x264 is mature, and it feels pretty fast even on veryslow, I never use Xvid. I am sure x265 will get there. :)

[Nico8583]

A question about keyint (even it's not the subject :D), is there an impact to CPU if keyint=24 or keyint=240, especially on Raspberry Pi if anyone used it ?
And about x265, I think I'll try it later, when I'll get 4K but now I use only a 1080p screen...

[movmasty]

I like x265 and will continue to test it for my encoding needs, right now when targeting visually lossless bluray rips
I C that you all here have a 200/20 sight,

I have not, and like to loss all but the necessary.
If i want "transparency" i will play the bluray itself, my backups have to be easy to store, move, play, re-edit, recode. transport, give out, save battery, fit in a tablet and so on.

To get the smallest size is my challenge, and im a sort of retarded guy, used Nandub well into the Xvid era, and still Xvid when new posts in the h264 forum were rare. This time i want to be ahead :)

(i am always applying the smart smoother filter radius 5-7 at an intermediate losseless big file before to compress, and it is slow, so maybe h265 could save me some time)

[Asmodian]

x265 is not going to save you time compared to x264. ;)

[huhn]

if you want to save battery you are wrong here too. hardware HEVC decoder are still very rare.

[movmasty]

CPU load on playing has something to do with battery

[marqee]

A question about keyint (even it's not the subject :D), is there an impact to CPU if keyint=24 or keyint=240, especially on Raspberry Pi if anyone used it ?
And about x265, I think I'll try it later, when I'll get 4K but now I use only a 1080p screen...

Raspberry pi /pi2 have hardware decoding support inside GPU, using kodi , no matters how you encode it it will handle h264 easly, but is not capable to decode h265 as the CPU is not enough powerfull.

About the "main" question of the thread, i made many RE-encodes of my archivied movie/tvseries from x264 to x265 using "handbrake".
getting the "similar" quality using a RF for h265 1-2 points less than h264. There is not visual quality loss for my eyes ( and my needs ), with -40% to -60% in file size , depending on the type of video file (action movie/ still movie / animations )
The only cons is a bigger cpu power usage during playback if you don't have a HTPC brasswell based ( intel N3150 for example) that handles the hevc/avc decoding on GPU.

[bololo]

Now (March 2017) I got an Odroid O2 running Kodi beeing able to hardware-decode hevc 10b up to FullHD w/o stuttering. At very high bitrates and 4k some stuttering starts.

For some free available test movies (you can google 'em):
"Samsung_SUHD_Colorful_Food.ts" : perfect
"jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv" : heavyly stutters


But for the OP Question (even he already gave up this project in 2015):

I am currently transcoding my whole 8bit avc-based movie library to hevc 10 bit (10 bit due optimizing banding).
It takes about 1 day on my Intel I7-7700K for one movie, but the discspace savings are worth that effords for me.

Before transcoding I additionally try to optimize picture by temporal degraining, cropping and some more stuff that I forgot in first place. By doing this, I change the pic anyway so I am not able to determine a detail loss due transcoding an already compressed file, but for my old eyes the quality is better due this processing.

For transcoding I use a "high ffmpeg" binary from sourceforge. Just google for
ffmpeg.static.2016-08-12-v3.1.2.64-bit.x26x-high-bitdepth

Because I use 32bit filters and 32bit avisynth but transcode using 64 bit ffmpeg I have to pipe the whole thing.
(only 64 bit version of ffmpeg uses all the benefits of cpu commands like SSE4, SSE3 etc)


This is my command line:

avs2yuv input.avs -o - | ffmpeg -i - -c:v libx265 -preset slow -x265-params crf=23:ctu=32:max-tu-size=16:tu-intra-depth=2:tu-inter-depth=2:rdpenalty=2:me=3:subme=5:merange=44:b-intra=1:no-amp=1:ref=5:weightb=1:keyint=360:min-keyint=1:bframes=8:aq-mode=1:aq-strength=1.0:rd=5:psy-rd=1.5:psy-rdoq=5.0:rdoq-level=1:no-sao=1:no-open-gop=1:rc-lookahead=80:scenecut=40:max-merge=4:qcomp=0.8:no-strong-intra-smoothing=1:qg-size=16:pbratio=1.2 output.mp4


The setting are from somewhere in this forum recommended for movies.

hope that helps,
B

[bololo]

Edit: Its Odroid C2

[sneaker_ger]

I am currently transcoding my whole 8bit avc-based movie library to hevc 10 bit (10 bit due optimizing banding).
It takes about 1 day on my Intel I7-7700K for one movie, but the discspace savings are worth that effords for me.
Have you calculated electricity costs vs HDD costs? Where I live you can buy about 40 GB HDD space for the same price as 150W * 24h.

[bololo]

Yes I did, but I do not have a choice.
I reached the physical limits of plugging in HDDs the mainboard is at its maximum.

Running 24/7 for one year (which I doesnt due noise) would just cost about $130.

Pluging in a extra controller card and an additional drive will cost more and power consumption will also rise.

best regards,
B