Questions about Handbrake and H.264

lagom

Offline

Jan 2009

107502

levels in h264? or you mean CRF? if so then CRF=18 is enough imho

and try using the stable versions since the nightly builds version is a work in progress and you might encounter errors from time to time, but honestly i always use the nightly builds because they have more updates like weekly to daily updates and improvements but ye at the risk of seeing some random errors from time to time

Sep 9, 2016 9:34 PM

Offline

Nov 2008

5471

Yes, I mean CRF. And yes, I'm using the stable version.

Okay, I'll stay at 10 to 15 RF because I'm obsessive. I'm impressed how many GB it's cutting off even at 10.

Sep 10, 2016 4:36 AM

Offline

Apr 2013

12542

I don't get it OP. You want quality, but you also want smaller file sizes. Might as well not encode at all.

Sep 10, 2016 8:48 AM

Offline

Dec 2009

1591

The so-called h265 is the new standard, it seems to have an even better compression.
But it's taxing the cpu & time for even more.
Also high bit standard may be used for even fewer banding artifacts.

Not encoding recently so I'm no longer too familiar.

Sep 10, 2016 10:27 AM

removed-user

Offline

Jul 2018

561864

I've always stuck with 20 for anything run-of-the-mill because I want the best size possible. At 20, even if there's very slight degradation it's not really noticeable during viewing and there are never any artifacts created by Handbrake.

If it's something on a personal "prestige" list or whatever I tend to go CRF=18.

Sep 10, 2016 12:19 PM

Offline

Nov 2008

5471

bottle said:
The so-called h265 is the new standard, it seems to have an even better compression.
But it's taxing the cpu & time for even more.
Also high bit standard may be used for even fewer banding artifacts.

Not encoding recently so I'm no longer too familiar.

I tried H.265. It took much longer and for some reason it ruined the video, even though I used the same settings. Might have overlooked something, but it doesn't seem worth the extra time.

worldeditor11 said:
I don't get it OP. You want quality, but you also want smaller file sizes. Might as well not encode at all.

I find it pretty hard to tell the following images apart. One is 35 GB and the other is 23. The sound is exactly the same.

I also like how it automatically crops your videos. I only kept the letterboxes for this movie because the Blu-ray had hard subs in the letterbox and on the picture.

This is gonna take a long time, though. Yesterday, I noticed the option to compress more slowly for better quality and smaller sizes. The three hour movie up there took four or five hours at the slow setting.

EzekielSep 10, 2016 12:26 PM

Sep 10, 2016 1:17 PM

lagom

Offline

Jan 2009

107502

h265 is only better in compression (like 50% more compression than h264) but visual quality wise h264 with the use of x264 encoder is still better

and we just have to wait until next year to see a new video codec that is said to be superior than h265, here https://en.wikipedia.org/wiki/AOMedia_Video_1

Sep 10, 2016 5:37 PM

Offline

Dec 2009

1591

j0x said:

When you say better compression, you have to set the quality to the same to compare, otherwise it does not make sense.

Alternatively, you set a fixed bitrate and compare the two. That's where h265 wins.
At low bitrate, 1Mbit per sec (1000 Kbit), it clearly out performs h264 in quality.
At higher bitrate they does not defer that much. That makes sense, at very high bit rate, both will be very similar to the lossless source.

Compare: http://wp.xin.at/archives/3465

bottleSep 10, 2016 5:51 PM

Sep 10, 2016 5:42 PM

#10

lagom

Offline

Jan 2009

107502

bottle said:

j0x said:

When you say better compression, you have to set the quality to the same to compare, otherwise it does not make sense.

That's where h265 wins.
At low bitrate, 1Mbit per sec, it clearly out performs h264 in quality.
At higher bitrate they does not defer that much. That makes sense, at very high bit rate, both will be very similar to the lossless source.

Compare: http://wp.xin.at/archives/3465

there is no such thing as lossless source though, even DVD and BluRay formats have lossy video codecs to begin with like h262/MPEG-2 and now H264/MPEG-4

and sure you have to encode the 2 videos with the same settings to compare it equally, but just do it in reasonable CRF for example, do same settings with CRF=18 on both x264 and x265 and you will notice the visual quality of x264 is still better at this point

but sure x265/h265 will win if you lower the bitrate more because of its higher compression performance no doubt about that

Sep 10, 2016 5:49 PM

#11

lagom

Offline

Jan 2009

107502

j0x said:

there is no such thing as lossless source though, even DVD and BluRay formats have lossy video codecs to begin with like h262/MPEG-2 and now H264/MPEG-4

i have to correct myself here, there are lossless video codecs but i mean even discs formats uses lossy video codecs to begin with

Sep 11, 2016 8:53 AM

#12

thepath

Offline

May 2012

6885

Use h.265 with high-profile encoding (also change H.265 profile to main10). Use something like CRF23 or CRF24

Lower CRF will result on much bigger size but slightly better quality video. For 1080p videos CRF24 is enough

Sep 11, 2016 10:55 AM

#13

OmegaSiets

Offline

Nov 2012

2102

I know the CRF meter is probably the better way to encode overall, but my lack of familiarity with it in terms of what it translates to in bitrates has kept me away from it, and I don't have the attention span to run a bunch of encodes to figure out where I like it. Maybe I'll get around to it someday when I feel like I have time to waste. Anyway, I've had pretty great results from selecting average bitrate and choosing 4800 kbps/2-pass encoding if it's a 1080p video. It's probably a bit overkill, but it puts the filesizes where I'm comfortable. Generally reduces a raw BD rip by like 85% while still retaining most of the quality. The thing you want to pay attention to is the optimization settings towards the bottom. I use the "High Profile" preset as a baseline, which usually sets these to H.264 profile High, level 4.1. Then I adjust the slider all the way to the setting just before you hit placebo. It's very slow, and on an average movie-length video, it will probably take anywhere between 7-10 hours to render, but the way I figure it, you only have to encode the video once and these settings basically give you free quality without increasing filesize, so it's worth it. Let it run overnight and it will be done when you wake up in the morning.

kingcity20 said:
Oh for the love of
-_- nvm gotta love MAL

Sep 11, 2016 11:23 AM

#14

Offline

Nov 2008

5471

OmegaSiets said:
I know the CRF meter is probably the better way to encode overall, but my lack of familiarity with it in terms of what it translates to in bitrates has kept me away from it, and I don't have the attention span to run a bunch of encodes to figure out where I like it. Maybe I'll get around to it someday when I feel like I have time to waste. Anyway, I've had pretty great results from selecting average bitrate and choosing 4800 kbps/2-pass encoding if it's a 1080p video. It's probably a bit overkill, but it puts the filesizes where I'm comfortable. Generally reduces a raw BD rip by like 85% while still retaining most of the quality. The thing you want to pay attention to is the optimization settings towards the bottom. I use the "High Profile" preset as a baseline, which usually sets these to H.264 profile High, level 4.1. Then I adjust the slider all the way to the setting just before you hit placebo. It's very slow, and on an average movie-length video, it will probably take anywhere between 7-10 hours to render, but the way I figure it, you only have to encode the video once and these settings basically give you free quality without increasing filesize, so it's worth it. Let it run overnight and it will be done when you wake up in the morning.

So, from what I'm gathering about the high profile is that it reduces the file sizes but looks the same. Is that correct? I've compressed five movies so far with 12 RF, main profile and slow optimization and it took over a day. It saved about a third of space.

39.3 GB > 27.9 GB (This took eight hours.)
33.5 GB > 19.6 GB
35 GB > 23.1 GB
31.7 GB > 18.3 GB
31.5 GB > 18.5 GB

Roughly how much would you guess high profile would would reduce them by? I'll do these movies again if the difference is dramatic. I just don't wanna throw away more than a day for nothing, since I still have dozens of other movies to encode.

EzekielSep 11, 2016 11:33 AM

Sep 11, 2016 11:50 AM

#15

OmegaSiets

Offline

Nov 2012

2102

Honestly with as high of bitrates as you're probably encoding at, the differences in quality for adjusting the optimization settings are probably negligible.

The high profile preset is just a package of settings that it automatically sets everything to if you're looking to do a high quality encode and don't particularly care how much time it takes to render. Then from there you can tweak it to your liking. Your bitrate is always going to be the largest determinant of file size and quality, and decreasing the RF slider will increase your bitrates and vice versa. If you right-click on one of your videos and go to properties, it will often tell you what the video bitrate is as well as the total bitrate with video and audio combined. Comparing these with what you see as the resulting quality when you watch the video can help you figure out what bitrates you find acceptable and what you find to be too low. What adjusting the optimization settings can do for you is generally increase the quality of the video at the cost of extra rendering time, however it won't impact file size. You're only going to see real benefits from it when you're really trying to balance quality with file size. Since your bitrates and filesizes are already so high, you're probably not going to notice much of a difference from adjusting these settings.

You can always of course just continue going down your list of movies that you're encoding, but adjusting the settings for the new ones, and decide for yourself whether you think there is a noticeable improvement in quality that warrants going back and doing the others that way. But my guess is, it's not worth it with the filesizes you're dealing with.

kingcity20 said:
Oh for the love of
-_- nvm gotta love MAL

Sep 11, 2016 1:33 PM

#16

Offline

Dec 2009

1591

crf 12 is rather crazy but it depends on the video itself, such as the complexity of movements and dark transitions etc.

Considering the cost, buying a new HDD may be cheaper than buying a fast CPU and the electricity bill, and this saves your time.
But if you are going to upload and share the video, then it's another matter.

Sep 11, 2016 1:43 PM

#17

Offline

Apr 2013

12542

Yeah, having crf 12 is downright pointless when you are striving for smaller file sizes without any perceivable visual loss.

I usually set it to crf 16 but mine is with a few tweaks here and there rather than just adjusting the crf slider. Those tweaks manage to shaved off a significant amount of bits without sacrificing too much visual quality in my anime encodes. But they do take a lot of time and dedication though.

Sep 11, 2016 1:55 PM

#18

Offline

Nov 2008

5471

bottle said:
crf 12 is rather crazy but it depends on the video itself, such as the complexity of movements and dark transitions etc.

Considering the cost, buying a new HDD may be cheaper than buying a fast CPU and the electricity bill, and this saves your time.
But if you are going to upload and share the video, then it's another matter.

I did two other compressions with that 39.3 GB file. One was at 15 RF and 27.7 GB, and the other was at 10 RF and 300 MB bigger. Not a huge difference. I can still see the difference between the 12 RF files and the raws, although it's not easy. 24 RF, as suggested by thepath, seems crazy to me. My 30,000 kbps movie already lost texture quality and grain rather noticeably at 20 RF.

I've had my i5-4670k (4 GHz) over two years. I'm wondering if an i7 would do this kind of stuff much faster, but I'm not planning to get a new CPU anytime soon. I bought a 6 TB hard drive two months ago just for movies and I'm ready to buy another when this one is eventually full. It's not even close, though.

EzekielSep 11, 2016 3:20 PM

Sep 11, 2016 2:18 PM

#19

Offline

Dec 2009

1591

Regarding CPU, if you search in Google, you can find encoders' comparison.
CPU benchmark tests often include h264 encoding as well.

The 300MB out of 27.7GB - the small difference between 15 and 10 surprises me. I thought it should be more.

RF of 22 - 24 is more for streaming. Not really for archive.

Sep 11, 2016 3:06 PM

#20

lagom

Offline

Jan 2009

107502

OmegaSiets said:
I know the CRF meter is probably the better way to encode overall

average file size or multi-pass (like 2-pass) encoding is for targeting a certain file size but the visual quality varies on each encodes

average quality or CRF encoding is for targeting a certain visual quality but the file size varies on each encodes

if you are going for archiving its better to use CRF always imho, the only reason to use file size if you are gonna upload it on a streaming site where bandwidth cap is a requirement to reduce your bills there

and you cannot determine the bitrate between CRF values because of this thing called video complexity that says video compressibility varies from episode to episode, scene to scene, and video to video, not all videos have the same amount of video complexity like some videos has more explosions and fast pace scenes (that needs higher bitrate overall) while other videos has more low motion scenes and static scenes (that needs lower bitrate overall), so CRF can be efficient imho because of this because on an anime show for example only few episodes are really action pack (that needs higher bitrate/filesize)

CRF's file size output varies between resolution output too of course higher resolution will output higher file size

but if you are one of those people that usually use different CRF values for each encodes then ye better stick to 2-pass encoding since Dark Shikari (x264 main developer) said that 2-pass (multi-pass) encoding just look for the CRF value that will output the target file size anyway while disregarding the visual quality output

Sep 11, 2016 9:13 PM

#21

Offline

Nov 2008

5471

worldeditor11 said:
Yeah, having crf 12 is downright pointless when you are striving for smaller file sizes without any perceivable visual loss.

But it is perceivable even at 12.

http://i.imgur.com/TsqPWM6.jpg
http://i.imgur.com/3JmBA4v.jpg

http://i.imgur.com/DxGaRRN.jpg
http://i.imgur.com/99Csqb7.jpg

Still a huge difference in terms of file size.

Sep 12, 2016 12:10 AM

#22

Offline

Apr 2013

12542

You mean the grain retention? You can keep the grain by reducing the deblocking values and adjust the aq settings to preserve grain without adjusting the crf slider. Grain filled videos shouldn't be pass with any deblocking or anti noise filters IF you want to preserve it.

Why do this instead of just using the crf slider you ask? From my personal experience, adjusting the aq values alone can save you a lot of MB sometimes GB of data without even cranking the crf values to oblivion. The problem is finding the sweet spot.

Oh yeah, to accurately compare between screenshots, you should save the images using lossless format such as png, not jpeg.

Sep 12, 2016 1:27 AM

#23

Offline

Nov 2008

5471

j0x says it's better to use the RF slider. His argument sounds compelling.

I'm not sure it's grain. One seems to have more detailed surfaces.

I considered capturing them as PNG, but since they're BOTH JPEG, it's an accurate, fair comparison.

Fine, same screenshots taken with FRAPS instead of MPC.

http://i.imgur.com/5P64lq0.png
http://i.imgur.com/a0n9PkA.png

http://i.imgur.com/gSNq76j.png
http://i.imgur.com/35dvLqv.png

I still see it.

The next one is taken from a file I made after switching to slow optimization.

http://i.imgur.com/G5egBDs.png

Again the original has more detail:

http://i.imgur.com/divVzqB.png

I don't get why you think it's so pointless. The two movies there went from 31.7 to 18.3 GB and 29.7 to 20.5 GB. That's huge.

EzekielSep 12, 2016 1:36 AM

Sep 12, 2016 4:01 AM

#24

Offline

Apr 2013

12542

Ezekiel said:

j0x says it's better to use the RF slider. His argument sounds compelling.

He only said why Constant Rate Factor (CRF) is preferred over other encoding methods such as Constant Bitrate (CBR) and Variable Bit Rate (VBR), not to advocate the sole use of adjusting CRF values. The CRF slider is used to target a certain a quality at any given frame. Lower values means more bits to represent a frame. Higher value of CRF means lower bits to represent a frame. CRF is an essence, is a motion estimation encoding method where it compares between frames to estimate. Hence, the existence of a parameter for you to set how many frames in advance to use as a reference for the algorithm. Higher of these theoretically means better compression but slower encoding time due to the extra frames need to be calculated.

Note that nowhere he said CRF is an absolute determination of quality. If this is the case, most of the encoders will be out of jobs by now since even a child can move a GUI slider.

Ezekiel said:

I'm not sure it's grain. One seems to have more detailed surfaces.

Either that or it is film noise. Now that I think about, I am guessing the latter since it is a film and film noise is a popular post processing filter applied to movies to achieve that "film" look.

Links on to grain/noise preservation:

http://forum.doom9.org/showthread.php?t=132893
http://forum.doom9.org/showthread.php?t=171087
http://forum.doom9.org/showthread.php?t=150005
http://forum.doom9.org/showthread.php?p=1747145#post1747145

Ezekiel said:

I considered capturing them as PNG, but since they're BOTH JPEG, it's an accurate, fair comparison.

Fine, same screenshots taken with FRAPS instead of MPC.

http://i.imgur.com/5P64lq0.png
http://i.imgur.com/a0n9PkA.png

http://i.imgur.com/gSNq76j.png
http://i.imgur.com/35dvLqv.png

I still see it.

I only mentioned you can compare frames more accurately using PNG as the image compression format. Not implying nor suggesting you were wrong in saying that the higher CRF value have a worse video quality.

Ezekiel said:

I don't get why you think it's so pointless. The two movies there went from 31.7 to 18.3 GB and 29.7 to 20.5 GB. That's huge.

Because people tend to assume that x264 is a miracle software to make smaller file sizes from larger ones with no strings attached.

To be fair, at one point, you might have thought to yourself, hmm, my current CRF value is enough with NO loss of detail. But then, after a few more tests, you noticed a tiny speck of detail lost during encoding. You are not satisfied. Therefore, you go lower. Problem solved with that single dot of detail being retained even after the encode. You say to yourself, I think I have done good for today. The next day, after another countless screenshot comparisons, you noticed not just one but two details being lost in the sea of bits. This is unacceptable! The only remedy here is to go even lower, low enough for you to not even notice the difference between the source and the resulting encode. But then you forgot one thing. The reason why you encode in the first place is to reduce the file size, NOT preserving video quality.

For archive purposes, it is always better to keep the original source. Best quality, encode kill details, waste of time and what not.
For distribution purposes, it is always better to encode while keeping the video quality as close to the video source as possible while maintaining sane file sizes.

worldeditor11Sep 12, 2016 4:05 AM

Sep 12, 2016 5:51 AM

#25

Offline

Nov 2008

5471

worldeditor11 said:
I only mentioned you can compare frames more accurately using PNG as the image compression format. Not implying nor suggesting you were wrong in saying that the higher CRF value have a worse video quality.

It's pointless to bring up, though, since you can see which one looks worse even with JPEGs. That's as accurate as it needs to be for what I'm talking about. Everybody knows PNG is more detailed. I find your statement somewhat patronizing. If I were comparing a JPEG to a PNG, I'd understand.

worldeditor11 said:
But then you forgot one thing. The reason why you encode in the first place is to reduce the file size, NOT preserving video quality.

That's your opinion. I'm encoding to reduce file size whilst losing as little quality as realistically possible. I'm satisfied with those screenshots. I only posted them because you said there isn't a perceivable difference. A third or fourth of a file size or more is a lot. It's gonna allow me to store many more movies. It's not even taking up much of my time, so I don't know what you're on about. I queue them and then continue what I'm doing. I'm even playing Dragon's Dogma. There are occasional freezes that last three seconds or so, but it's totally playable. Speak for yourself.

EzekielSep 12, 2016 5:58 AM

Sep 12, 2016 8:01 AM

#26

Offline

Apr 2013

12542

Ezekiel said:
]It's pointless to bring up, though, since you can see which one looks worse even with JPEGs. That's as accurate as it needs to be for what I'm talking about. Everybody knows PNG is more detailed. I find your statement somewhat patronizing. If I were comparing a JPEG to a PNG, I'd understand.

Uhh, and here I thought I was trying to help a fellow would be encoder. If you find my advice to be patronising, I swear by my word that I am not. And not everybody knows PNG is a lossless, I used to be one of them when I was learning how to encode. As embarrassing as this sounds. If you find my assumption of you not knowing PNG is patronising, then I am sorry. The only purpose of me posting that at all was just to inform. Pointless from your view, but proves useful down the road. At least to me.

Ezekiel said:

That's your opinion. I'm encoding to reduce file size whilst losing as little quality as realistically possible. I'm satisfied with those screenshots. I only posted them because you said there isn't a perceivable difference. A third or fourth of a file size or more is a lot. It's gonna allow me to store many more movies. It's not even taking up much of my time, so I don't know what you're on about. I queue them and then continue what I'm doing. I'm even playing Dragon's Dogma. There are occasional freezes that last three seconds or so, but it's totally playable. Speak for yourself.

I actually went back to reread my earlier posts several times because I didn't remember I posted such reply.

worldeditor11 said:
Yeah, having crf 12 is downright pointless when you are striving for smaller file sizes without any perceivable visual loss.

Apologies for my blunder here. It seems that I worded my thoughts very badly. I was confused why the hell I posted that too as smaller file size and quality just doesn't mix together.

I meant it as having crf 12 to be downright pointless when you are striving for smaller file sizes but at the same time, you want no perceivable visual loss in your encodes. To further elaborate, that value is so low, it seems that the benefits of encoding the source at all to reduce the file size, is minimal or just couldn't be utilised fully.

I actually didn't post this earlier because I am not sure how large live action movies encode sizes are. But I do think it might be useful as a benchmark on how big your file sizes can be. To put the file sizes comparison between a few anime BD sources and their respective encodes:

Hyouka (1080p)
8GB (avg. 24 mins) ---> 1.5 GB (Coalgirls)

Persona 3 #1 Movie (1080p)
40GB(1.40.00) ---> 11.39 GB (DameDesuYo)

Steamboy (1080p)
42GB (2.06.00) ---> 9.6 GB (Afro)

Kara no Kyoukai 5 (1080p with grain)
40 GB (2.00.00) ---> 23 GB (Coalgirls)

Most of the encodes managed to shaved off at least half of their original source file sizes. These groups are also known to be extremely anal about their video quality. Take this as you will.

Sep 12, 2016 12:37 PM

#27

Offline

Nov 2008

5471

worldeditor11 said:
I actually didn't post this earlier because I am not sure how large live action movies encode sizes are. But I do think it might be useful as a benchmark on how big your file sizes can be. To put the file sizes comparison between a few anime BD sources and their respective encodes:

Hyouka (1080p)
8GB (avg. 24 mins) ---> 1.5 GB (Coalgirls)

Persona 3 #1 Movie (1080p)
40GB(1.40.00) ---> 11.39 GB (DameDesuYo)

Steamboy (1080p)
42GB (2.06.00) ---> 9.6 GB (Afro)

Kara no Kyoukai 5 (1080p with grain)
40 GB (2.00.00) ---> 23 GB (Coalgirls)

Most of the encodes managed to shaved off at least half of their original source file sizes. These groups are also known to be extremely anal about their video quality. Take this as you will.

Why would I base what I'm doing off videos that are compressed for sharing purposes? Without knowing how much quality was lost?

Also, like I said, I'm not just encoding to reduce file sizes, I also want to remove the letterboxes. It leaves more room on my monitor if I need to window the video for whatever reason, and it's gonna make a big difference if I ever decide to get an ultra wide display. I won't have to fiddle with the player's zoom.

EzekielSep 12, 2016 2:49 PM

Dec 1, 2016 11:11 PM

#28