HandBrake

I will do some tests now. First video I tried didn't work. Nothing happens.

Here is the test video: http://dlsecondary.gamersyde.com/secdl/ ... utpost.mp4

This is a 60 fps video. There is no fps option where I could choose 30 fps. This is currently same as source only. This is a must have option for future versions. Looks like CBR and VBR are the two encoding options. AVBR can be slightly better. CBR is also missing.


edit: my other test videos doesn't work either. I have to check, maybe there is an issue on my side. Currently I have driver version 9.18.10.3131 installed, will try 9.18.10.3071 tomorrow.

9.18.10.3071 installed and now the test video works. Compared to QStranscode Handbrake encoded the test video slightly slower and quality is worse than QSTranscode (identical settings). Could be difficult to reach QStranscode quality/speed ratio. Will do more tests tomorrow.

Definitely sligthly slower in every video. My guess is that some of the MFX options which QSTranscode disabled is enabled in the Handbrake implementation and some of these might cause a slight slowdown compared to QSTranscode. These are enabled by default in the SDK:

MFX_EXTBUFF_VPP_DENOISE
MFX_EXTBUFF_VPP_SCENE_ANALYSIS
MFX_EXTBUFF_VPP_PROCAMP
MFX_EXTBUFF_VPP_DETAIL


The good thing is that each of my test video did work without issues so far and while it is slightly slower than QTranscode it is one of the fastest overall. But there are some options missing. FPS, AVBR, CBR or numSlices option for Hawell ULV GT3 to turn off one slice for power reasons.

thanks for trying out and feedback provided!

Currently, implementation in HandBrake uses VBR as default method,
CQP method used if quality option of HandBrake is used,
CBR will be used if bitrate and vbv-maxrate are the same
(you can always see the full logic behind like from http://repo.or.cz/w/HandBrake.git/blob/ ... qsv.c#l262 )

if all options are identical, MSDK/QSV should create bit exact output

if there will be good reasons, NumSlice support can be exposed, currently it is driven as:
>If NumSlice equals zero, the encoder may choose any slice partitioning allowed by the codec standard.
MSDK documentation.

After some new comparisons I have to correct my initial statement. Quality is top notch for Quicksync compared to my reference QS encoders MediaEspresso 6.7 and QSTranscode.

gmb we target quality settings rather than best performance settings by default which might explain the difference.

CQP encoding is much better in some videos which is no surprise though. I was trying to do a comparison with QSTranscode but CQP didn't work properly. Fortunately newest MediaEspresso press version support CQP (it is called constant quality, should be the same). There is only a CQP Normal and CQP High setting. I will use CQP normal and with the bitrate from the encoded video I have try what quality factor in Handbrake matches MediaEspresso size/bitrate. Comparable video size and bitrate is a must have for a proper comparison. MediaEspresso m2ts output with better quality and in Handbrake best quality preset of course.

FWIW, CQP disables adaptive quantization - so you may get better results using ABR. Unfortunately QSV does not have anything comparable to x264's CRF.

You mean Avg Bitrate? Avatar trailer looked much worse with this setting.

gmb wrote:You mean Avg Bitrate? Avatar trailer looked much worse with this setting.

Did you use an ABR value that is equivalent to the bitrate of the CQP encode that you are comparing to? The comparison isn't fair unless the output files you are comparing are the same approximate bitrate.

Yes I did. Both identical bitrate and file size.

CQP= http://s1.directupload.net/images/130522/guh6hj9g.png
VBR= http://s1.directupload.net/images/130522/qy4cxyzx.png

Interesting. The VBR encode is missing a lot of high frequency information in that still frame. But when adaptive quantization is enabled, looking at one still frame isn't a good way to judge since it should be allocating bits to where they are "needed most" (which could be in other frames). If it really looks worse over all, then their adaptive quanitzation algorithm needs work.

I don't doubt your quality judgement. I'm just curious what it looks like in full motion. Could you post 20 second clips?

With VBR in this scene Mediaespresso does a much better job than QSTranscode or Handbrake at the same bitrate. So it is not only Intels fault but CQP would be better here nevertheless. 20 seconds from CQP and VBR?

My other test sample (link in first post) seems to be better with VBR.


I can't fully match MediaEspresso bitrate with CBR for my comparison. Handbrake allows only full QP digits and nothing in between.

I decided to use VBR bitrate to better match the same bitrate for all encoders. Encoding done. Screenshots will follow. Here the encoding times from Handbrake, MediaeEspresso, QSTranscode 1008.


Video 1
MediaEspresso= 1:24
QSTranscode= 0:58
Handbrake= 1:52 (*60 fps encoding due to missing 30 fps option)

Video 2
MediaEspresso= 0:12
QSTranscode= 0:09
Handbrake= 0:11

Video 3
MediaEspresso= 1:19
QSTranscode= 1:21
Handbrake= 1:28

Video 4
MediaEspresso= 0:29
QSTranscode= 0:30
Handbrake= 0:35

Video 5
MediaEspresso= 0:38
QSTranscode= failed
Handbrake= 0:36

Video 1
MediaEspresso= http://imageshack.us/a/img199/5699/1mediaespresso.png
QSTranscode= http://imageshack.us/a/img109/4103/1qstranscode.png
Handbrake= http://imageshack.us/a/img801/2127/1handbrake.png
My ranking: 1) Handbrake 2) QSTranscode 3) MediaEspresso

Video 2
MediaEspresso= http://imageshack.us/a/img834/7026/2mediaespresso.png
QSTranscode= http://imageshack.us/a/img849/5572/2qstranscode.png
Handbrake= http://imageshack.us/a/img259/1391/2handbrake.png
My ranking: 1) Handbrake 2) MediaEspresso 3) QSTranscode

Video 3
MediaEspresso= http://imageshack.us/a/img832/2527/3mediaespresso.png
QSTranscode= http://imageshack.us/a/img248/3800/3qstranscode.png
Handbrake= http://imageshack.us/a/img10/3553/3handbrake.png
My ranking: 1) Handbrake 2) MediaEspresso+QSTranscode

Video 4
MediaEspresso= http://imageshack.us/a/img829/364/4mediaespresso.png
QSTranscode= http://imageshack.us/a/img42/2277/4qstranscode.png
Handbrake= http://imageshack.us/a/img17/7927/4handbrake.png
My ranking: 1) MediaEspresso 2) QSTranscode 3) Handbrake

Video 5
MediaEspresso= http://imageshack.us/a/img16/1451/5mediaespresso.png
QSTranscode= failed
Handbrake= http://imageshack.us/a/img842/7936/5handbrake.png
My ranking: both comparable

I did a x264 comparison with ultrafast High Profile preset in Handbrake. Decomb disabled, variable fps same as source, avg Bitrate for all videos 6~Mbps in 1080p. Oh and important my CPU: i5-3570k


Video 1= 2:17
Video 2= 0:13
Video 3= 1:25
Video 4= 0:40
Video 5= 0:35

Handbrake Quicksync with quality preset overall slightly faster as you can see in my QS result posting. Video 1, 2, 4 win for QS Quality while a Video 3 win for x264 ultrafast. Video 5 1 second difference, no winner here. Quicksync Balanced obviously would have a bigger speed advantage. Screenshots following...

Thanks for all the feedback gmb

Here the Ultrafast x264 High profile screenshots. You can directly compare this with my Quicksync screenshots. Identical Bitrate.

Video 1= http://imageshack.us/a/img443/9449/1cpuultrafast.png
Video 2= http://imageshack.us/a/img442/600/2cpuultrafast.png
Video 3= http://imageshack.us/a/img577/5664/3cpuultrafast.png
Video 4= http://imageshack.us/a/img594/9785/4cpuultrafast.png
Video 5= http://imageshack.us/a/img23/1864/5cpuultrafast.png


First of all quality can be subjective. From my point of view the Ultrafast pictures are very noisy (especially video 1, 4, 5). I rate Handbrake QS Quality Preset higher than x264 Ultrafast High Profile in Handbrake.

Just comparing those screenshots.

x264 defiantly has more detail but is a tad blocky and has artifacts.
qsv images a very soft so your not seeing the blocky/artifacts so much as a result, but you've lost a lot of detail.

Here is some numbers I did a while ago showing the differences in the x264 presets:
Big Buck Bunney
Preset Tune RF Size (MB) Avg FPS Bitrate PSNR SSIM
ultrafast PSNR 20 954.5 135.5 13110.2 PSNR Mean Y:46.945 U:49.775 V:50.412 Avg:47.604 Global:46.167 kb/s:13109.35 SSIM Mean Y:0.9871187 (18.900db)
superfast PSNR 20 526.6 109.23 7230.1 PSNR Mean Y:47.347 U:49.861 V:50.640 Avg:47.939 Global:46.671 kb/s:7229.65 SSIM Mean Y:0.9893315 (19.719db)
veryfast PSNR 20 360.8 79.52 4953.4 PSNR Mean Y:45.600 U:48.582 V:49.490 Avg:46.319 Global:45.580 kb/s:4953.13 SSIM Mean Y:0.9868048 (18.796db)
faster PSNR 20 392.6 50.62 5390 PSNR Mean Y:46.679 U:49.258 V:50.108 Avg:47.290 Global:46.515 kb/s:5389.83 SSIM Mean Y:0.9890095 (19.590db)
fast PSNR 20 392.2 37.9 5383.9 PSNR Mean Y:46.926 U:49.530 V:50.395 Avg:47.536 Global:46.749 kb/s:5383.63 SSIM Mean Y:0.9893737 (19.736db)
medium PSNR 20 384.2 32.63 5274.4 PSNR Mean Y:47.006 U:49.599 V:50.416 Avg:47.612 Global:46.805 kb/s:5274.07 SSIM Mean Y:0.9894267 (19.758db)

I partially disagree with you. Video 1 is just horrible on x264 especially in motion. Video 2 as for sharpness and details it depends, for example the tree on the right is more detailed in the Handbrake QS screenshot. Video 3 the white rabbit more detailed in the Handbrake QS screenshot. Some image parts more details on QS and some more on x264 ultrafast. Video 4 I agree, but very noisy. Both not doing good here. Video 5 similar. 1-2 videos are debatable but overall I rate QS higher.

Try superfast as well. You'll probably find quite a significant improvement.

I already did the same with Super Fast, I should post the converting times and screenshots tomorrow. Beside converting times and quality there is another not unimportant factor for mobile at least: power consumption/power efficiency. I have an energy check device, but I think it is no surprise that 4 cores @100% load have a higher power consumption than Quicksync with a low CPU load and its iGPU with 50-100% load depending on the video. This is not a big factor for my desktop machine but surely for Ultrabooks or Tablets.

Super Fast High profile Handbrake encoding times. Screenshots following.

Video 1= 3:10
Video 2= 0:18
Video 3= 2:12
Video 4= 0:55
Video 5= 0:37

Video 1= http://imageshack.us/a/img191/7576/1cpusuperfast.png
Video 2= http://imageshack.us/a/img203/1451/2cpusuperfast.png
Video 3= http://imageshack.us/a/img607/1340/3cpusuperfast.png
Video 4= http://imageshack.us/a/img836/7840/4cpusuperfast.png
Video 5= http://imageshack.us/a/img809/6884/5cpusuperfast.png


Less artifacts than ultrafast, it lost details though. I prefer Video 1, 2, 3 on Handbrake Quicksync and Video 4, 5 super fast x264 better.