Estimating Handbrake encoding speed (comparing other CPU benchmarks) - Page 6 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 34Likes
Reply
 
Thread Tools
post #151 of 193 Old 05-05-2015, 12:41 AM
AVS Forum Special Member
 
steelman1991's Avatar
 
Join Date: May 2008
Posts: 1,740
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 454 Post(s)
Liked: 219
Quote:
Originally Posted by jhughy2010 View Post
Edit: I've never been able to get a QuickSync film to be as good of quality as an x264 re-encoded film. I don't know if that is just me or if others have had the same experience but as a consequence I strictly re-encode to HEVC or x264. I even built up an i7-4790k overclocked rig for the duties as each film takes a few hours even with an i7. I have it water cooled and all for super silent and cool operation. It was strictly overkill though (it became a fun project/hobby).
Can't say I've noticed a great deal of difference - though I don't encode my movies - just TV Series (for space saving purposes) - some of those babies can't half eat into storage space (my backup being the physical discs). Using a QuickSync high profile, reducing the file size to ridiculous sizes (at around the 200+ fps on an i5 - time taking approx 5-6 minutes per episode), I cannot see a difference to the original (and I am hyper critical of video quality), viewing on a Panasonic 65" plasma. I was extremely sceptical of speed/quality issues previously, but having tried them I'm a convert - well for some elements of my collection, though I must admit I might just revisit my movies in the not too distant future.

That rig does sound like it was a fun project.
steelman1991 is offline  
Sponsored Links
Advertisement
 
post #152 of 193 Old 05-05-2015, 03:35 AM
Newbie
 
~smackos~'s Avatar
 
Join Date: Mar 2009
Posts: 6
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
Thank you for all your input guys. Just pulled the trigger on a little low power Haswell i3, should serve just nicely for HTPC duties as well as Quick Sync duties. Now just got to wait two days for delivery.

Last edited by ~smackos~; 05-05-2015 at 01:28 PM.
~smackos~ is offline  
post #153 of 193 Old 05-05-2015, 04:01 PM
AVS Forum Special Member
 
ilovejedd's Avatar
 
Join Date: Aug 2006
Posts: 3,764
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 76 Post(s)
Liked: 67
Quote:
Originally Posted by jhughy2010 View Post
Edit: I've never been able to get a QuickSync film to be as good of quality as an x264 re-encoded film. I don't know if that is just me or if others have had the same experience but as a consequence I strictly re-encode to HEVC or x264. I even built up an i7-4790k overclocked rig for the duties as each film takes a few hours even with an i7. I have it water cooled and all for super silent and cool operation. It was strictly overkill though (it became a fun project/hobby).
I use Intel QSV QP 20, High Profile L4.0 on Balanced (Sandy Bridge/Ivy Bridge) and honestly, I don't really notice any difference compared to x264 CRF 20, High Profile L4.0 on Medium preset watching on the iPad. Maybe if I do frame by frame comparisons I might see it but given my intended usage, I don't really see much point. We have the full quality Blu-ray rips for watching on the HTPC anyway.

I remember reading a review comparing SSIM/PSNR of QSV vs x264. On 1080p High Profile, Haswell QSV was holding its own against x264 Fast/Medium on the low end of the bitrate scale and in between Fast and Very Fast on higher bitrates.

QuickSync's goal is reasonably good encode quality at fast speed and I think it succeeds there. It's definitely a lot better compared to older NVIDIA CUDA and ATI Stream encodes I've tried. Now those were just awful. Like 10x worse than bad YouTube vids awful. Sure, QuickSync is not going to be as good as even the default x264 Slow preset but at least it's not going to take you hours to encode even if you only have a lowly Celeron/Pentium desktop or laptop. Heck, even some Bay Trail CPUs have QuickSync now.
jhughy2010 likes this.
ilovejedd is offline  
Sponsored Links
Advertisement
 
post #154 of 193 Old 05-05-2015, 05:55 PM
AVS Forum Special Member
 
jhughy2010's Avatar
 
Join Date: Jan 2014
Location: California
Posts: 1,865
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 906 Post(s)
Liked: 288
Quote:
Originally Posted by ilovejedd View Post
I use Intel QSV QP 20, High Profile L4.0 on Balanced (Sandy Bridge/Ivy Bridge) and honestly, I don't really notice any difference compared to x264 CRF 20, High Profile L4.0 on Medium preset watching on the iPad. Maybe if I do frame by frame comparisons I might see it but given my intended usage, I don't really see much point. We have the full quality Blu-ray rips for watching on the HTPC anyway.

I remember reading a review comparing SSIM/PSNR of QSV vs x264. On 1080p High Profile, Haswell QSV was holding its own against x264 Fast/Medium on the low end of the bitrate scale and in between Fast and Very Fast on higher bitrates.

QuickSync's goal is reasonably good encode quality at fast speed and I think it succeeds there. It's definitely a lot better compared to older NVIDIA CUDA and ATI Stream encodes I've tried. Now those were just awful. Like 10x worse than bad YouTube vids awful. Sure, QuickSync is not going to be as good as even the default x264 Slow preset but at least it's not going to take you hours to encode even if you only have a lowly Celeron/Pentium desktop or laptop. Heck, even some Bay Trail CPUs have QuickSync now.
True... QuickSync is great if you don't want to wait around for a few hours to re-encode just to put it on a small screen (laptop, tablet, smartphone, etc.)
jhughy2010 is offline  
post #155 of 193 Old 06-02-2015, 03:19 AM
Newbie
 
martik777's Avatar
 
Join Date: Jan 2010
Posts: 1
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 0
Will QSV work if 2 monitors are connected to the M/B's IGP, (ie:no PCIe video card)?

I'm thinking of a H81 or B85 chipset with a G3258.
martik777 is offline  
post #156 of 193 Old 06-02-2015, 05:14 AM
AVS Forum Addicted Member
 
Foxbat121's Avatar
 
Join Date: Jul 2003
Location: VA
Posts: 11,813
Mentioned: 10 Post(s)
Tagged: 0 Thread(s)
Quoted: 698 Post(s)
Liked: 482
Quote:
Originally Posted by martik777 View Post
Will QSV work if 2 monitors are connected to the M/B's IGP, (ie:no PCIe video card)?

I'm thinking of a H81 or B85 chipset with a G3258.
QSV is the function of Intel's integrated GPU. So as long as you are using the GPU inside the Intel processor, it will work regardless how many monitors arevconnected. The problem only arises when you use an external PCIe video card and disabled the embedded iGPU (automatically done when you add a PCIe video card). Even that can be worked around.
Foxbat121 is online now  
post #157 of 193 Old 07-09-2015, 03:04 AM
Newbie
 
Join Date: Jul 2015
Posts: 10
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 3
Reading through this thread really helped me quite a bit. I thank everyone who posted here, although I'm not sure how many of you will ever see it. I've learned how to use Handbrake exactly how I want to use it because of this thread and through a bit of trial and error.

I do have one question that I believe Foxbat and maybe a few others could help with, if they would be so kind. I have an "older" Sandy Bridge i7 2600 so it does have QSV, but I wonder how good it would be since it's the older version.

I've been taking my bluray rips and making them around 1.2 GB per hour of the TV shows that I don't value quite as highly as my favorites to save space. I've been using CQ 18, Very Slow, High Profile, 4.1 Level as the settings I deem the perfect level of quality for shows I'd rather save space on.

Is it possible to get the same level of quality (but much faster) with a Sandy Bridge QSV encode by tweaking the options? I see in this thread that people feel that the CQ of QSV encoding is just slightly worse than regular CPU encodes of similar settings.

I'm not sure what QSV related settings appear in Handbrake when using it with my Sandy Bridge i7 2600, but is it possible to tweak those settings and set the CQ around 4 lower to get the same results as my regular encodes? Would the size/quality ratio be the same if this was possible?

Thanks in advance for anyone who tries to help.
Rod Shaftwell is offline  
post #158 of 193 Old 07-09-2015, 05:06 AM
AVS Forum Addicted Member
 
Foxbat121's Avatar
 
Join Date: Jul 2003
Location: VA
Posts: 11,813
Mentioned: 10 Post(s)
Tagged: 0 Thread(s)
Quoted: 698 Post(s)
Liked: 482
Why don't you just try it and let us know?


I have an older 2600 system but it is using a dedicated graphics card, not iGPU. I will have to hack it around in order to use QSV. Too much trouble besides it is my kid's gaming machine. But I have to say CQ 18 is way too much. Most of my BD rips are compressed using CQ 20-22 at 1080p. The result is about 8 to 10GB per movie.
jhughy2010 likes this.
Foxbat121 is online now  
post #159 of 193 Old 07-09-2015, 05:24 AM
Newbie
 
Join Date: Jul 2015
Posts: 10
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 3
Quote:
Originally Posted by Foxbat121 View Post
Why don't you just try it and let us know?


I have an older 2600 system but it is using a dedicated graphics card, not iGPU. I will have to hack it around in order to use QSV. Too much trouble besides it is my kid's gaming machine. But I have to say CQ 18 is way too much. Most of my BD rips are compressed using CQ 20-22 at 1080p. The result is about 8 to 10GB per movie.

I guess I might just do that, and if I do, I will certainly post my results here. I have a dedicated GPU (Radeon 7900 series) as well so I would probably have to go into the BIOS, enable the Intel HD Graphics, update the drivers and set it up accordingly.

I'm sure it wouldn't take that long to set up, worse case scenario I take the time to set it up and then find out the results aren't to my liking. I guess I was just trying to avoid that if I could. I was also hoping that someone could tell me what QSV/Handbrake settings I should use to get the same quality/size ratio or better as my default CPU encode.

Maybe someone will come along and help me out, but in a month or so the curiosity to just "trial and error" it out may get the better of me.

Either way I'll be checking back in on this thread, and thanks for the reply.
Rod Shaftwell is offline  
post #160 of 193 Old 07-09-2015, 10:37 AM
Newbie
 
Join Date: Jul 2015
Posts: 10
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 3
Foxbat I tried to PM you but I can't because I have too few posts. Then I tried to edit my post but I guess I can't do that either.

About the CQ 18 being too much... I probably should have pointed out that I am not ripping from a Bluray in this case. That is to say the source is not a Bluray disc, rather it is an existing Bluray encode that is still too large for my liking. These are rips that I do not have the source for anymore.

Certain shows/movies just aren't worth as much space to me, of course I keep all my favorites at full 1080p 4-8GB Bluray rips, but for everything else I want the best quality I can fit into right around 1.2-1.5 GB per hour.

I have found that a CQ level of 18,Very Slow, High Profile, and H.264 Level 4.1 gives me exactly the file size/quality I want in this case.

If you have any advice regarding changing my settings for these types of encodes, I would listen and try anything. You're definitively more knowledgeable on this topic.
Rod Shaftwell is offline  
post #161 of 193 Old 07-09-2015, 02:39 PM
AVS Forum Addicted Member
 
Foxbat121's Avatar
 
Join Date: Jul 2003
Location: VA
Posts: 11,813
Mentioned: 10 Post(s)
Tagged: 0 Thread(s)
Quoted: 698 Post(s)
Liked: 482
Quality setting is subjective. According to Handbrake, use CQ 18-20 for SD video and 20-23 for HD video.
Foxbat121 is online now  
post #162 of 193 Old 07-09-2015, 04:04 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
The CRF mode in x264 is generally considered to reach transparency at RF 18, but it's not an exact science, since everyone has different eyes. It's also worth noting that on average, incrementing the RF by a value of 6 will change the output size by a factor of 2 (-6 = 2x bigger files, +6 = 2x smaller files), so incrementing the RF by a value of 1 will yield a size difference of ~17%.

Regarding the quality vs resolution question, the answer is actually a bit counter-intuitive. One might think that HD video would need a smaller RF (and thus a proportionally higher bitrate) than SD video to achieve the same quality, but the opposite is in fact the case. Understanding why requires a bit of explanation.

The chief compression unit of H.264 (and most other codecs) is the macroblock, which is a square comprised of 16x16 pixels. In order to compress a video, the image is divided into macroblocks, and then each macroblock is analysed to determine how to best compress it. If the bitrate is too low, adjacent macroblocks may not blend together very well, which causes portions of the image to have a visible checkerboard pattern (macroblocking). Increasing the bitrate allows for the preservation of more detail and thus makes the transition between nearby macroblocks smoother and less noticeable.

How noticeable a macroblock artifact is depends directly upon how big a macroblock is in proportion to the entire image. In SD video, (e.g. 704x480), a square of 16x16 pixels constitutes a pretty large percentage of the image, whereas since HD video has roughly twice as many pixels (1280x720) or quadruple the number of pixels (1920x1080), the size of a macroblock in proportion to the total size of the video frame is cut by a factor of 2 or 4.

In the strictest terms, video resolution has no effect on the quality produced by CRF mode: RF 18 provides the same quality at 704x480, 1280x720, and 1920x1080 resolutions; however, because macroblocks become proportionally smaller at higher resolutions, you can actually use higher CRF values without causing a noticeable reduction in quality. The quality has technically decreased if you switch from RF 18 to RF 20, but because the resolution is much higher, the artifacts become proportionally much smaller, and thus the extra artifacts introduced by switching from RF 18 to RF 20 aren't as likely to be noticeable.
ilovejedd, ajhieb, farkem and 2 others like this.
Aleron Ives is offline  
post #163 of 193 Old 07-09-2015, 08:20 PM
AVS Forum Special Member
 
jhughy2010's Avatar
 
Join Date: Jan 2014
Location: California
Posts: 1,865
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 906 Post(s)
Liked: 288
Quote:
Originally Posted by Rod Shaftwell View Post
Foxbat I tried to PM you but I can't because I have too few posts. Then I tried to edit my post but I guess I can't do that either.

About the CQ 18 being too much... I probably should have pointed out that I am not ripping from a Bluray in this case. That is to say the source is not a Bluray disc, rather it is an existing Bluray encode that is still too large for my liking. These are rips that I do not have the source for anymore.

Certain shows/movies just aren't worth as much space to me, of course I keep all my favorites at full 1080p 4-8GB Bluray rips, but for everything else I want the best quality I can fit into right around 1.2-1.5 GB per hour.

I have found that a CQ level of 18,Very Slow, High Profile, and H.264 Level 4.1 gives me exactly the file size/quality I want in this case.

If you have any advice regarding changing my settings for these types of encodes, I would listen and try anything. You're definitively more knowledgeable on this topic.
In all honesty I wouldn't waist your time with QSV. I have had the opportunity to play around with QSV on my i5-4440 and i7-4700HQ and both yield rather poor results. The settings for QSV are kind of finicky. I have had several encodes fail when trying to re-encode with main profile and several fail when setting preset to "best quality". These were a waist of time because they took several hours during a time when I needed the films for a flight etc.

When the encodes have worked for QSV the time for a 2 hour BD film was about 45 minutes. My i7-4790k at 4.5GHz can do a 2 hour film using x264 in a little over an hour (or sometimes faster). So really there is no point for QSV in my opinion. Also, the i7-4790k will do main profile with a level of 3.1 (720p) RF of 23 in about 25 minutes. It really just blazes through it. So if I need a movie on my phone in a hurry I just use those settings (kind of equivalent to the Windows Phone 8 setting).

I have recently re-encoded all of my 200+ BD rips into HEVC and wow does that take a long time. All of that hard work for my i7 and come to find out the HEVC is a little choppy on my Samsung S5. I'm sure my next phone or tablet will play HEVC re-encodes just fine. HEVC is, however, very awesome as the file size in comparison to x264 is a bit smaller.
jhughy2010 is offline  
post #164 of 193 Old 07-09-2015, 09:17 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
It'll be a while before x265 catches up, as x264 has the benefit of many years' worth of quality and speed optimisations that x265 doesn't have. Eventually x265 should reach similar speeds while cutting the filesize in half as compared to x264 while achieving the same quality, but it'll take at least a few years for that to happen (not to mention for H.265 decoding support to be implemented in hardware players).
farkem likes this.
Aleron Ives is offline  
post #165 of 193 Old 07-10-2015, 06:44 AM
Newbie
 
Join Date: Jul 2015
Posts: 10
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 3
Quote:
Originally Posted by Aleron Ives View Post
The CRF mode in x264 is generally considered to reach transparency at RF 18, but it's not an exact science, since everyone has different eyes. It's also worth noting that on average, incrementing the RF by a value of 6 will change the output size by a factor of 2 (-6 = 2x bigger files, +6 = 2x smaller files), so incrementing the RF by a value of 1 will yield a size difference of ~17%.

Regarding the quality vs resolution question, the answer is actually a bit counter-intuitive. One might think that HD video would need a smaller RF (and thus a proportionally higher bitrate) than SD video to achieve the same quality, but the opposite is in fact the case. Understanding why requires a bit of explanation.

The chief compression unit of H.264 (and most other codecs) is the macroblock, which is a square comprised of 16x16 pixels. In order to compress a video, the image is divided into macroblocks, and then each macroblock is analysed to determine how to best compress it. If the bitrate is too low, adjacent macroblocks may not blend together very well, which causes portions of the image to have a visible checkerboard pattern (macroblocking). Increasing the bitrate allows for the preservation of more detail and thus makes the transition between nearby macroblocks smoother and less noticeable.

How noticeable a macroblock artifact is depends directly upon how big a macroblock is in proportion to the entire image. In SD video, (e.g. 704x480), a square of 16x16 pixels constitutes a pretty large percentage of the image, whereas since HD video has roughly twice as many pixels (1280x720) or quadruple the number of pixels (1920x1080), the size of a macroblock in proportion to the total size of the video frame is cut by a factor of 2 or 4.

In the strictest terms, video resolution has no effect on the quality produced by CRF mode: RF 18 provides the same quality at 704x480, 1280x720, and 1920x1080 resolutions; however, because macroblocks become proportionally smaller at higher resolutions, you can actually use higher CRF values without causing a noticeable reduction in quality. The quality has technically decreased if you switch from RF 18 to RF 20, but because the resolution is much higher, the artifacts become proportionally much smaller, and thus the extra artifacts introduced by switching from RF 18 to RF 20 aren't as likely to be noticeable.
Good stuff. I calculated the difference between two encodes one done at CQ17 and the other done at CQ18 (all other settings identical) and the CQ17 encode is 17.9% larger so that math seems to hold up. Good to know.

I have done the same episodes of Boardwalk Empire in CQ20 and CQ18 @ 720p (source in this case is also a 720p Bluray Rip). I compare them on my 50" LG LED 1080p TV with two instances of VLC player running at the same time synced up to the millisecond. I can hold my mouse over each of them back and forth to compare the videos quite thoroughly.

I can definitely see the difference when I do this. Obviously this is overkill for a comparison in normal use, but I like to have my files EXACTLY the way I want them. If I watched the CQ18 first and then watched the CQ20 after, I would be hard pressed to spot the differences. Since Handbrake is so customizable, I figure I might as well cram as much quality into 1.2-1.5GB @ 720p per hour as I can.

To jhughy2010:

Through a few hours of reading up on QSV and my Sandy Bridge i7, I too get the feeling that it really might not be worth it. After all, I really don't mind setting up 4 or so encodes @ Very Slow before I go to bed, and then setting Handbrake to Shut Down my computer after its done. I wake up everything is done and my computer has had a few hours of downtime too. Easy.

I just started encoding a few days ago and I'm really pretty happy with how well Handbrake handles things. However I just realized that I have been encoding with an H.264 Level of 4.1 and thus far have only encoded @ 720p.

I think I should be using Level 3.1 for 720p/23.976fps right? Or maybe I should just use auto? Does this affect size/quality ratio?
Rod Shaftwell is offline  
post #166 of 193 Old 07-10-2015, 02:44 PM
AVS Forum Special Member
 
jhughy2010's Avatar
 
Join Date: Jan 2014
Location: California
Posts: 1,865
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 906 Post(s)
Liked: 288
^^^ I don't know the exact answer to that question but there is tons of info on the x264 Video Settings page and this wiki link.
jhughy2010 is offline  
post #167 of 193 Old 07-10-2015, 03:00 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
The level merely signals how demanding the file is going to be to play (so that weak hardware players won't try to play files that they're too slow to decode), based on the video's resolution, framerate, and the number of reference frames. To my knowledge, forcing L4.1 when you're only using L3.1 features just means any hardware device that doesn't support L4.1 could potentially refuse to play the file, even though it should technically be compatible. You shouldn't force the level unless x264 is detecting it incorrectly.
Aleron Ives is offline  
post #168 of 193 Old 07-10-2015, 03:19 PM
AVS Forum Special Member
 
jhughy2010's Avatar
 
Join Date: Jan 2014
Location: California
Posts: 1,865
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 906 Post(s)
Liked: 288
Quote:
Originally Posted by Aleron Ives View Post
The level merely signals how demanding the file is going to be to play (so that weak hardware players won't try to play files that they're too slow to decode), based on the video's resolution, framerate, and the number of reference frames. To my knowledge, forcing L4.1 when you're only using L3.1 features just means any hardware device that doesn't support L4.1 could potentially refuse to play the file, even though it should technically be compatible. You shouldn't force the level unless x264 is detecting it incorrectly.
Do you recommend leaving this set to "auto" then?
jhughy2010 is offline  
post #169 of 193 Old 07-10-2015, 04:03 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
Quote:
Originally Posted by jhughy2010 View Post
Do you recommend leaving this set to "auto" then?
Quote:
Originally Posted by Aleron Ives View Post
You shouldn't force the level unless x264 is detecting it incorrectly.
That would be the result of not forcing it.
Aleron Ives is offline  
post #170 of 193 Old 07-12-2015, 02:44 PM
Newbie
 
Join Date: Jul 2015
Posts: 10
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 3
I decided to test the effect of H.264 level by encoding the same video three times. The video was a 720p Bluray rip. The results were interesting.

All settings (CQ18, Very Slow, Film, High) were identical except for H.264 levels @ 3.1 + 4.1 + Auto. All encodes resulted in the same file size and bitrate.

The first thing I noticed was the Auto setting encode resulted in an H.264 level of 5.0, which is not good.

-5.0 works on the computer fine, but doesn't work on essentially any other device I try it on (tablet, Smart TV, etc.)
-5.0 took 178% longer to encode than 3.1 and 139% longer than 4.1


So the 3.1 and 4.1 encodes are the same size/bitrate. Theoretically they have to be the same quality right? I compared them with two simultaneous instances of VLC synced and they do appear to be the same visually upon a 5 minute inspection.

The 4.1 encode took 128% longer than the 3.1 encode and seemingly provides no added benefits comparatively. 3.1 encode is the fastest and also has the widest range of device compatibility.

It seems like I should be using level 3.1 for these 720p 23.976fps encodes definitively.

What do you guys think?
jhughy2010 likes this.
Rod Shaftwell is offline  
post #171 of 193 Old 07-12-2015, 03:58 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
I already told you what the level does in post 167. You should always use the lowest level that your file respects. As long as you're using resolution no higher than 1280x720, a framerate no higher than 30, and no more than 5 reference frames, you should declare your file to be L3.1. The fact that Handbrake is somehow either causing x264 to detect the level incorrectly or is forcing it to an incorrect value means that you'll need to force it to L3.1 yourself. The only explanation I can give for why it takes so much longer to use L4 or L5 is that Handbrake is changing another setting behind the scenes. For instance, using 9 reference frames requires you to declare at least L4, and using 9 reference frames instead of 5 would definitely reduce the encoding speed. Letting x264 automatically detect the level wouldn't change your reference frames setting by itself, but who knows what naughty things Handbrake might be doing to cause the decrease in speed.
Aleron Ives is offline  
post #172 of 193 Old 07-12-2015, 11:32 PM
AVS Forum Special Member
 
DotJun's Avatar
 
Join Date: Dec 2012
Posts: 1,679
Mentioned: 10 Post(s)
Tagged: 0 Thread(s)
Quoted: 597 Post(s)
Liked: 163
The reason gpu encoding wasn't as good as CPU encoding used to be because you couldn't call some of x264s other switches. Is that not the case now?

Another reason to go with CPU encoding is to use avisynth, which a lot of are single threaded so there's no getting around slow encode times.
DotJun is offline  
post #173 of 193 Old 07-13-2015, 07:45 AM
Newbie
 
Join Date: Jul 2015
Posts: 10
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 3
Quote:
Originally Posted by Aleron Ives View Post
I already told you what the level does in post 167. You should always use the lowest level that your file respects. As long as you're using resolution no higher than 1280x720, a framerate no higher than 30, and no more than 5 reference frames, you should declare your file to be L3.1. The fact that Handbrake is somehow either causing x264 to detect the level incorrectly or is forcing it to an incorrect value means that you'll need to force it to L3.1 yourself. The only explanation I can give for why it takes so much longer to use L4 or L5 is that Handbrake is changing another setting behind the scenes. For instance, using 9 reference frames requires you to declare at least L4, and using 9 reference frames instead of 5 would definitely reduce the encoding speed. Letting x264 automatically detect the level wouldn't change your reference frames setting by itself, but who knows what naughty things Handbrake might be doing to cause the decrease in speed.
Post 167 was greatly appreciated, as are all your posts, but it didn't really tell me anything I didn't read in the Handbrake wiki beforehand. You did say that I shouldn't force the level unless it's being detected incorrectly, and your next post indicates the Auto setting is the preferable default. Of course, I couldn't know whether it was being detected properly without encoding some videos @ Auto, so I did the test. Figured I'd post the results.

I'm not using the advanced settings, so when I choose Auto, 3.1, or 4.1 the reference frames are set by Handbrake. The log files tell me that any video I've encoded @ 3.1 uses 5 reference frames. The 4.1 videos are 9 frames, and finally, the Auto setting results in a 5.0 level and a whopping 16 frames.

Remember I'm new to this, so I assume the 3.1 and 4.1 settings are working properly by automatically setting the max allowed reference frames according to the 720p 24 fps video. But, like you said, a reference frame setting of 16 is obviously making the encode take longer.

I really don't know why its not detecting correctly (the only setting that I changed was the level), but at least I understand why it took so long now. From what I understand about reference frames, there is probably no reason to be using anything above 5 for these 720p encodes, do you agree? I suppose there's seriously diminishing returns the higher you go in reference frames depending on resolution.
jhughy2010 likes this.
Rod Shaftwell is offline  
post #174 of 193 Old 07-13-2015, 10:23 AM
AVS Forum Special Member
 
jhughy2010's Avatar
 
Join Date: Jan 2014
Location: California
Posts: 1,865
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 906 Post(s)
Liked: 288
Quote:
Originally Posted by Aleron Ives View Post
I already told you what the level does in... You should always use the lowest level that your file respects.
Actually that isn't what you said as you can see in my question and your subsequent response

Quote:
Originally Posted by Aleron Ives View Post
That would be the result of not forcing it.
It's ok though... you aren't the first nor the last to contradict yourself on these here forums.

@Rod Shaftwell thanks for your experimentation. It is good to know. I will likely be manually setting the level from now on when using x264. For some reason HEVC re-encoding doesn't have a level option. Maybe it is hidden on the advanced page. I'll check later.
jhughy2010 is offline  
post #175 of 193 Old 07-13-2015, 01:07 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
Quote:
Originally Posted by jhughy2010 View Post
It's ok though... you aren't the first nor the last to contradict yourself on these here forums.
What contradiction? I said that you shouldn't force the level unless x264 detects it incorrectly, which is true. The problem here is with Handbrake, not x264, as Handbrake's automatic level mode is apparently totally different from the automatic level detection in x264.

Quote:
Originally Posted by Rod Shaftwell View Post
I'm not using the advanced settings, so when I choose Auto, 3.1, or 4.1 the reference frames are set by Handbrake. The log files tell me that any video I've encoded @ 3.1 uses 5 reference frames. The 4.1 videos are 9 frames, and finally, the Auto setting results in a 5.0 level and a whopping 16 frames.
This is why I don't use frontends. This isn't supposed to happen and won't happen if you use x264 by itself. Handbrake is automatically changing the number of reference frames based on the level you select, even though these two settings are totally independent in x264. It's no wonder you're having trouble figuring out what's what when Handbrake is changing settings behind the scenes without your knowledge or consent!

When I said that you should use automatic detection, I was talking about the automatic level mode in x264, which will use your video's resolution, framerate, and the number of reference frames you specified to determine what the video's level should be. Handbrake's automatic level mode is apparently totally different: it's automatically changing the reference frames value based on what it feels like doing.

Quote:
Originally Posted by Rod Shaftwell View Post
I really don't know why its not detecting correctly (the only setting that I changed was the level), but at least I understand why it took so long now.
No, the level of your files is being detected correctly. The problem is that Handbrake isn't letting you control the options the way it should. You're supposed to set the resolution, frame rate, and number of reference frames yourself, and then x264 will determine the correct level to use based on those settings. Handbrake is letting you define the level and then picking the maximum number of reference frames it can use at that level, based on the resolution of your video. That approach is backwards compared to how x264 works, and Handbrake's automatic setting is totally nonsensical: selecting L5 is a terrible idea, since hardware players are always limited to L4.1. Only PC software can play L5 H.264 videos. The "auto" setting in any program should pick a sane default value for users who don't know what value to pick on their own, but Handbrake is picking the very worst value it could possibly use! This makes no sense.

Quote:
Originally Posted by Rod Shaftwell View Post
From what I understand about reference frames, there is probably no reason to be using anything above 5 for these 720p encodes, do you agree? I suppose there's seriously diminishing returns the higher you go in reference frames depending on resolution.
Yes, 5 reference frames is a good choice for live action content. One of the most important things to understand about x264 is that more doesn't mean better. When you set the number of reference frames, you're not telling x264 how many reference frames to use: you're telling it how many reference frame patterns it should check before it decides on the best one to use. Using lots of reference frames is only beneficial on highly repetitive content, such as animation, where many frames in a row are exactly the same on a regular basis. If you allow lots of reference frames on live action content, x264 will slow way down while it checks every possible pattern; e.g. if you allow 9 reference frames instead of 3, x264 will spend time checking all 9 only to decide that 3 was the best solution in most cases. As a result, the encoding process becomes much slower, but the end result is the same as if you had just used 3 reference frames.

I don't know if Handbrake will show you the encoding statistics, but x264 spits out a bunch of useful tables when an encode is finished. These tables include the number of consecutive B-frames and the number of reference frames that were used in your encode. If you allow 10 B-frames and 9 reference frames in your files but find that x264 usually picks only 6 B-frames and 5 reference frames, then you might as well set the B-frame cap to 6 and the reference frame cap to 5 in the future to speed up your encodes, as the slower settings aren't producing better results.

Frontends are supposed to make complicated programs easier to use by giving you a simple GUI to access important functions, but it doesn't help when Handbrake's menus don't serve the same functions as the options in x264 itself.
Aleron Ives is offline  
post #176 of 193 Old 07-13-2015, 04:15 PM
Newbie
 
Join Date: Jul 2015
Posts: 10
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 3
Quote:
Originally Posted by Aleron Ives View Post
The problem is that Handbrake isn't letting you control the options the way it should. You're supposed to set the resolution, frame rate, and number of reference frames yourself, and then x264 will determine the correct level to use based on those settings.
I actually am setting the resolution (Anamorphic: Strict) and frame rate (Same as source: Constant) in Handbrake, I just didn't include that when I listed my settings because I thought it would be a bit silly to list every single setting I used lol. Instead I listed what I thought were the most pertinent ones.

Now the reference frames are also easily controllable in Handbrake, but they are under the advanced settings. I decided to forgo using the advanced settings until I was comfortable with every other setting and its' effect on the video encoded.

Quote:
Originally Posted by Aleron Ives View Post
Handbrake is letting you define the level and then picking the maximum number of reference frames it can use at that level, based on the resolution of your video... selecting L5 is a terrible idea, The "auto" setting in any program should pick a sane default value for users who don't know what value to pick on their own, but Handbrake is picking the very worst value it could possibly use! This makes no sense.
Yes we seem to be in agreement here. The Auto setting in Handbrake selecting level 5.0 was what I was referring to when I said I had no idea why it wasn't detecting properly. Meaning whatever Handbrake is using to decide that the level should be 5.0 is clearly off.

Quote:
Originally Posted by Aleron Ives View Post
Yes, 5 reference frames is a good choice for live action content. One of the most important things to understand about x264 is that more doesn't mean better. When you set the number of reference frames, you're not telling x264 how many reference frames to use: you're telling it how many reference frame patterns it should check before it decides on the best one to use. Using lots of reference frames is only beneficial on highly repetitive content, such as animation, where many frames in a row are exactly the same on a regular basis. If you allow lots of reference frames on live action content, x264 will slow way down while it checks every possible pattern; e.g. if you allow 9 reference frames instead of 3, x264 will spend time checking all 9 only to decide that 3 was the best solution in most cases. As a result, the encoding process becomes much slower, but the end result is the same as if you had just used 3 reference frames.
Good explanation of reference frames. Thanks.

Quote:
Originally Posted by Aleron Ives View Post
I don't know if Handbrake will show you the encoding statistics, but x264 spits out a bunch of useful tables when an encode is finished. These tables include the number of consecutive B-frames and the number of reference frames that were used in your encode. If you allow 10 B-frames and 9 reference frames in your files but find that x264 usually picks only 6 B-frames and 5 reference frames, then you might as well set the B-frame cap to 6 and the reference frame cap to 5 in the future to speed up your encodes, as the slower settings aren't producing better results.
Yes Handbrake saves a log file for every encode with all sorts of info. That is where I got the reference frames number from all my encodes. B-frames is another setting under "advanced", so like I said I wanted to get to know all other settings before I go advanced. FYI if you didn't know, in Handbrake you have to enable the Advanced settings under, Options > Preferences to even see the menu. I suppose they do that to not confuse noobs.

I've gone through just about every single log file and here's what I can tell you about ref frames and b-frames:

-all encodes where I selected Auto resulted in level 5.0 and Handbrake setting shows 16 ref frames
-all encodes where I selected level 3.1 Handbrake setting shows 5 ref frames in log file
-all encodes where I selected level 4.1 Handbrake setting shows 9 ref frames in log file
-every single encode I've done results in Handbrake setting b-frames at 8

So since I just started video encoding 6 days ago, I had no idea that the log file could tell you how x264 is using the ref/b frames. I've run out of time today, so I'll have to look at the log files more tomorrow. Judging by your description, I'm sure it has something to do with the lines of percentages in the log. Thanks for your insight.
jhughy2010 likes this.
Rod Shaftwell is offline  
post #177 of 193 Old 07-13-2015, 07:31 PM
AVS Forum Special Member
 
DotJun's Avatar
 
Join Date: Dec 2012
Posts: 1,679
Mentioned: 10 Post(s)
Tagged: 0 Thread(s)
Quoted: 597 Post(s)
Liked: 163
Pick a crf value and a preset that falls into your comfort spot for encoding time, then choose a tune. Done. No need to do anything else more complex until later on when you've figured out what each switch does.
DotJun is offline  
post #178 of 193 Old 07-13-2015, 10:15 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
Quote:
Originally Posted by Rod Shaftwell View Post
Yes we seem to be in agreement here. The Auto setting in Handbrake selecting level 5.0 was what I was referring to when I said I had no idea why it wasn't detecting properly. Meaning whatever Handbrake is using to decide that the level should be 5.0 is clearly off.
Handbrake seems to be making a deliberate decision, so it's not a bug. Why the Handbrake developers chose to associate such a bad setting with the automatic mode is another question entirely. It isn't a matter of incorrect "detection": Handbrake is choosing to use L5 and the maximum number of reference frames allowed by L5 (16) when you select "Auto". That's why the encoding process takes so much longer.


Quote:
Originally Posted by Rod Shaftwell View Post
I've gone through just about every single log file and here's what I can tell you about ref frames and b-frames:

-all encodes where I selected Auto resulted in level 5.0 and Handbrake setting shows 16 ref frames
-all encodes where I selected level 3.1 Handbrake setting shows 5 ref frames in log file
-all encodes where I selected level 4.1 Handbrake setting shows 9 ref frames in log file
-every single encode I've done results in Handbrake setting b-frames at 8

So since I just started video encoding 6 days ago, I had no idea that the log file could tell you how x264 is using the ref/b frames. I've run out of time today, so I'll have to look at the log files more tomorrow. Judging by your description, I'm sure it has something to do with the lines of percentages in the log. Thanks for your insight.
I'll see if I can illuminate some of the interesting details. Here's an x264 log:

Code:
avs [info]: 1280x720p 0:0 @ 30000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High, level 3.1
x264 [info]: frame I:1722  Avg QP:16.33  size: 93059
x264 [info]: frame P:46773 Avg QP:19.63  size: 26558
x264 [info]: frame B:194204 Avg QP:24.39  size:  3894
x264 [info]: consecutive B-frames:  1.0%  0.8%  3.4% 17.3%  6.4% 69.5%  1.4%
x264 [info]: mb I  I16..4:  9.8% 68.8% 21.3%
x264 [info]: mb P  I16..4:  1.6%  5.8%  1.0%  P16..4: 49.2% 17.2% 16.1%  0.5%  0.2%    skip: 8.6%
x264 [info]: mb B  I16..4:  0.1%  0.3%  0.0%  B16..8: 35.6%  3.9%  0.9%  direct: 1.7%  skip:57.5%  L0:40.4% L1:50.7% BI: 8.9%
x264 [info]: 8x8 transform intra:70.0% inter:66.2%
x264 [info]: direct mvs  spatial:100.0% temporal:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 69.0% 72.9% 38.1% inter: 9.1% 10.9% 0.8%
x264 [info]: i16 v,h,dc,p: 50% 13%  7% 31%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15%  9%  8%  8% 12% 14% 11% 12% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17%  9%  4%  9% 13% 15% 12% 11% 11%
x264 [info]: i8c dc,h,v,p: 31% 22% 27% 20%
x264 [info]: Weighted P-Frames: Y:1.6% UV:1.2%
x264 [info]: ref P L0: 57.6% 11.7% 19.8%  5.7%  5.1%  0.3%  0.0%
x264 [info]: ref B L0: 89.2%  8.4%  1.9%  0.5%
x264 [info]: ref B L1: 96.0%  4.0%
x264 [info]: kb/s:2132.59

encoded 242699 frames, 2.40 fps, 2132.59 kb/s
The first line lists the resolution and framerate of my video.

The third line lists the detected level of my video, based on the resolution, framerate, and reference frames I set (5).

The next three lines:

x264 [info]: frame I:1722 Avg QP:16.33 size: 93059
x264 [info]: frame P:46773 Avg QP:19.63 size: 26558
x264 [info]: frame B:194204 Avg QP:24.39 size: 3894

list frame type statistics of the video, which I encoded at CRF 19. There were 1722 I-frames (complete frames) with an average quality of 16.33 (a bit better than QP 19, so as to boost the quality of the incomplete frames derived from the I-frames). There were 46773 P-frames (predictive frames) with an average quality of 19.63, and 194204 B-frames (bi-directional frames) with an average quality of 24.39.

The next line lists B-frame statistics:

x264 [info]: consecutive B-frames: 1.0% 0.8% 3.4% 17.3% 6.4% 69.5% 1.4%

I selected to allow up to 6 consecutive B-frames in my x264 settings. The first number is the percentage of the video where 0 B-frames were used (because x264 determined that using B-frames was a bad idea in those instances). This only happened 1.0% of the time. The second number is the percentage of the video where 1 B-frame was used (0.8%). The third number is the percentage of the video where 2 consecutive B-frames were used (3.4%), and so forth. As you can see, the vast majority of the time x264 decided to use 5 consecutive B-frames (69.5% of the time), and it almost never used 6 consecutive B-frames (1.4% of the time). I could have sped up my encoding time by only allowing 5 consecutive B-frames on this video, but I didn't know what the percentages were going to be ahead of time, so I used 6 anyway. If I found that 6 consecutive B-frames were almost never used in all of my videos, then I might want to consider just setting the cap at 5 so as to speed up my future encodes.

These 3 lines near the bottom detail reference frame statistics:

x264 [info]: ref P L0: 57.6% 11.7% 19.8% 5.7% 5.1% 0.3% 0.0%
x264 [info]: ref B L0: 89.2% 8.4% 1.9% 0.5%
x264 [info]: ref B L1: 96.0% 4.0%

I selected to allow up to 5 reference frames for this encode. The first line says that 1 reference frame was selected 57.6% of the time, 2 reference frames were selected 11.7% of the time, 3 reference frames were selected 19.8% of the time, while 4 and 5 reference frames were only used around 5% of the time each. It's probably likely that I wouldn't have gained any benefit from using more than 5 reference frames on this video, as most of my video only needed 1-3 reference frames.

The last line displays the total number of frames in the video, the average speed of the encoding process, and the average bitrate of the encoded video. You can easily calculate the encoding time by dividing the number of frames in the video by the FPS of the encoding process. Note that this encode was performed on a Core 2 Duo, which is why the speed is so low.

I hope that's helpful for reading x264's gibberish.
Aleron Ives is offline  
post #179 of 193 Old 07-13-2015, 10:33 PM
AVS Forum Special Member
 
DotJun's Avatar
 
Join Date: Dec 2012
Posts: 1,679
Mentioned: 10 Post(s)
Tagged: 0 Thread(s)
Quoted: 597 Post(s)
Liked: 163
And that's why the default is 3ref I think most people think the profiles and tunes are chosen randomly by the devs or something, as I see a lot of users tweaking things even though they have no idea what the function actually does.
DotJun is offline  
post #180 of 193 Old 07-14-2015, 01:29 PM
AVS Forum Special Member
 
Aleron Ives's Avatar
 
Join Date: Oct 2009
Posts: 5,130
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 1831 Post(s)
Liked: 1620
It's only the default on the medium preset, which provides sub-optimal settings. You can tell which settings are the most important by which ones change in each preset:

Code:
                                  - slow:
                                    --b-adapt 2 --direct auto --me umh
                                    --rc-lookahead 50 --ref 5 --subme 8
                                  - slower:
                                    --b-adapt 2 --direct auto --me umh
                                    --partitions all --rc-lookahead 60
                                    --ref 8 --subme 9 --trellis 2
                                  - veryslow:
                                    --b-adapt 2 --bframes 8 --direct auto
                                    --me umh --merange 24 --partitions all
                                    --ref 16 --subme 10 --trellis 2
                                    --rc-lookahead 60
                                  - placebo:
                                    --bframes 16 --b-adapt 2 --direct auto
                                    --slow-firstpass --no-fast-pskip
                                    --me tesa --merange 24 --partitions all
                                    --rc-lookahead 60 --ref 16 --subme 11
                                    --trellis 2
The reference frames are among the first settings to get increased when you use the slow preset. The settings start to get pretty silly by the time you reach the veryslow preset, and the name of the placebo preset says everything you need to know about how useful it is.
Aleron Ives is offline  
Sponsored Links
Advertisement
 
Reply Home Theater Computers

Tags
handbrake , Intel , Intel Core I3 4130 3 4 3 Fclga 1150 Processor Bx80646i34130 , Intel Core I5 3570 3 4 Ghz Processor , Intel Core I5 4670k 3 4ghz Lga 1150 Quad Core Desktop Processor , Intel Core I7 4770k 3 5ghz Lga 1150 Quad Core Desktop Processor , Intel Pentium G2020 2 9ghz Lga 1155 Dual Core Desktop Processor , Intel Pentium G3220 3 0ghz Lga 1150 Dual Core Desktop Processor , quicksync

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off