H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Description of problem or question:
Previous HandBrake 1.2.2 used x265 2.9 with aq-mode=1 by default.
New HandBrake 1.3.0 uses x265 3.2.1 with aq-mode=2 by default (since x265 v3.0).
For some reason this new default aq-mode=2 at few short tests gives me 30-60% more bitrate than aq-mode=1 or old HB 1.2.2 with default aq-mode=1.
All other settings are the same (RF/preset etc)
Any regular HandBrake user who don't know about aq-mode, after upgrading will just get much higher bitrate with all the same setiings without any good reason.
This is normal and expected?
And if this is new "normal" behavior, shouldn't recommended RF values be changed and announced? Like old RF20 = new RF21 or 22.
Operating system and version: Windows 10 x64
Previous HandBrake 1.2.2 used x265 2.9 with aq-mode=1 by default.
New HandBrake 1.3.0 uses x265 3.2.1 with aq-mode=2 by default (since x265 v3.0).
For some reason this new default aq-mode=2 at few short tests gives me 30-60% more bitrate than aq-mode=1 or old HB 1.2.2 with default aq-mode=1.
All other settings are the same (RF/preset etc)
Any regular HandBrake user who don't know about aq-mode, after upgrading will just get much higher bitrate with all the same setiings without any good reason.
This is normal and expected?
And if this is new "normal" behavior, shouldn't recommended RF values be changed and announced? Like old RF20 = new RF21 or 22.
Operating system and version: Windows 10 x64
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Logs are required to compare settings. There are multiple changes between 1.2.x and 1.3.x that would affect file size.
Post the logs from the same file being encoded in each (old logs should still be on your system for 30 days).
Post the logs from the same file being encoded in each (old logs should still be on your system for 30 days).
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
You don't even need to look at old 1.2.2
As I said, just in 1.3.0 new default aq-mode=2 versus forced old aq-mode=1 gives very different bitrate.
PS. I don't use any hardware accelerators.
As I said, just in 1.3.0 new default aq-mode=2 versus forced old aq-mode=1 gives very different bitrate.
PS. I don't use any hardware accelerators.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Yes, AQ is a major component of rate control and can result in very different bitrates for the same RF, even everything else being equal. Unfortunately this does mean users may have to adjust the RF for their custom presets (or manually specify AQ mode 1 via the advanced options text box, "aq-mode=1" without quotes).
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Yes, it is expected. The x265 team changed this here: https://bitbucket.org/multicoreware/x26 ... 3f37e767c6
Please also note, that in the newer version of x265 the way the slower and veryslow preset works has changed:
http://x265.org/revamped-veryslow-slowe ... 5-ver-3-0/
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
I made a similar thread here about encoded files in v1.3.0 being ~20% larger than those encoded with v1.2.2. I also said in that thread that I could see no change in quality - but after having more time to test, I have found that lowering the Constant Quality to 27 does indeed alter the quality for the worse.
I am very seriously considering going back to v1.2.2, as I am struggling to see what benefits v1.3.0 might offer me other than an polished GUI at first glance. This isn't enough to counter the file size increase in my opinion.
I plan to do some more tests with DVD rips, but right now feel that rolling back to v1.2.2 is looking very likely.
I am very seriously considering going back to v1.2.2, as I am struggling to see what benefits v1.3.0 might offer me other than an polished GUI at first glance. This isn't enough to counter the file size increase in my opinion.
I plan to do some more tests with DVD rips, but right now feel that rolling back to v1.2.2 is looking very likely.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
I'm aware of x265 changelog. And I also think that this is very important change which affect basic encode routine with shifting RF values and this should be reflected at HandBrake changelog and recommended values. Most users not aware of aq-mode change or aq-modes overall, they just upgraded HandBrake and now have increased bitrate for unknown reason.Nomis101 wrote: ↑Sat Nov 23, 2019 9:10 pm Yes, it is expected. The x265 team changed this here: https://bitbucket.org/multicoreware/x26 ... 3f37e767c6
Please also note, that in the newer version of x265 the way the slower and veryslow preset works has changed:
http://x265.org/revamped-veryslow-slowe ... 5-ver-3-0/
This is exactly what I would like to see at HandBrake official changelog or Release Highlights!Rodeo wrote: ↑Fri Nov 22, 2019 11:12 pm Yes, AQ is a major component of rate control and can result in very different bitrates for the same RF, even everything else being equal. Unfortunately this does mean users may have to adjust the RF for their custom presets (or manually specify AQ mode 1 via the advanced options text box, "aq-mode=1" without quotes).
If you don't do BOB deinterlace, you could just use extra settings "aq-mode=1" for forcing old behavior, like Rodeo said.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
x265 is still a WIP, and will settle in eventually, once a lot more data has been compiled. Trying to cross-reference all values between the latest two versions is something even our esteemed developers couldn't do. If patience is an issue, remember it wasn't "that" long ago when a 30 minute encode took two months to complete (no exaggeration ).
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Try adding the setting they say and nothing.
I have preferred to return to version 1.2.2
Version 1.3.0 was giving me more than twice as heavy files ...
I have preferred to return to version 1.2.2
Version 1.3.0 was giving me more than twice as heavy files ...
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Post the encoding log if you think the aq mode option isn't working as expected.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
I need to admit, that I adapted my x265 options a bit for HB 1.3.0 to use the advanced features that x265 3.2.1 brings, but for preset medium and CRF=19 I don't see such a massive increase in bitrate. I've encoded "Star Trek Into Darkness" once with 1.2.2 and once with 1.3.0:
1.2.2: size 10.3 GiB / bitrate 11.2 Mbps
1.3.0: size 9.32 GiB / bitrate 10.1 Mbps
(the only difference is, for 1.3.0 I added hme and sao.)
I will test with some more movies.
1.2.2: size 10.3 GiB / bitrate 11.2 Mbps
1.3.0: size 9.32 GiB / bitrate 10.1 Mbps
(the only difference is, for 1.3.0 I added hme and sao.)
I will test with some more movies.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
If you don't use the same settings, including defaults that changed, it's not a meaningful comparison.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
aq-mode=1 vs aq-mode=2 test
Here's my 30sec sample from neighbor topic: https://megaupload.is/f7xf09B7n6/handbrakebobtest_rar
Shared settings:
Deinterlace: yadif / default / detectionOff
Codec: H265 / framerate: SameAsSource + Variable / RF20 / preset: medium / tune: none / profile&level: auto
Results:
1.3.0 with forced old aq-mode=1: 2322 kb/s
1.3.0 by default (aq-mode=2): 3124 kb/s (+34%)
Here's my 30sec sample from neighbor topic: https://megaupload.is/f7xf09B7n6/handbrakebobtest_rar
Shared settings:
Deinterlace: yadif / default / detectionOff
Codec: H265 / framerate: SameAsSource + Variable / RF20 / preset: medium / tune: none / profile&level: auto
Results:
1.3.0 with forced old aq-mode=1: 2322 kb/s
1.3.0 by default (aq-mode=2): 3124 kb/s (+34%)
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Is it worth using x265?
Using x264 veryslow at CRF 20 yields 2,627 kbps. x265 is just 12% smaller.
Of course, some will say x265 CRF 20 is not the same as x264 CRF 20.
Full log:
Using x264 veryslow at CRF 20 yields 2,627 kbps. x265 is just 12% smaller.
Code: Select all
HandBrakeCLI --encoder x264 --encoder-preset veryslow --encopts "ref=3:bframes=5:threads=6" -q 20 --comb-detect --deinterlace --audio none --input test.mp4 --output out_deinterlace.mp4
Full log:
Code: Select all
[13:23:46] Nvenc version 8.0
[13:23:46] NVENC version not supported. Disabling feature.
[13:23:46] hb_init: starting libhb thread
[13:23:46] thread 7facd4ed1700 started ("libhb")
HandBrake 1.3.0 (2019111000) - Linux x86_64 - https://handbrake.fr
32 CPUs detected
Opening test.mp4...
[13:23:46] CPU: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
[13:23:46] - Intel microarchitecture Sandy Bridge
[13:23:46] - logical processor count: 32
[13:23:46] hb_scan: path=test.mp4, title_index=1
udfread ERROR: ECMA 167 Volume Recognition failed
disc.c:323: failed opening UDF image test.mp4
disc.c:424: error opening file BDMV/index.bdmv
disc.c:424: error opening file BDMV/BACKUP/index.bdmv
bluray.c:2585: nav_get_title_list(test.mp4/) failed
[13:23:46] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.1
libdvdread: Encrypted DVD support unavailable.
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[13:23:46] dvd: not a dvd - trying as a stream/file instead
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.20.100
Duration: 00:00:30.36, start: 0.200000, bitrate: 3006 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt470bg), 720x576 [SAR 16:11 DAR 20:11], 3003 kb/s, SAR 1:1 DAR 5:4, 25 fps, 25 tbr, 25k tbn, 50 tbc (default)
Metadata:
handler_name : VideoHandler
[13:23:46] scan: decoding previews for title 1
Scanning title 1 of 1, preview 8, 80.00 %[13:23:46] scan: 10 previews, 720x576, 25.000 fps, autocrop = 0/0/0/0, aspect 16:9, PAR 16:11
[13:23:46] Title is likely interlaced or telecined (8 out of 10 previews). You should do something about that.
[13:23:46] libhb: scan thread found 1 valid title(s)
+ Using preset: CLI Default
+ title 1:
+ stream: test.mp4
+ duration: 00:00:30
+ size: 720x576, pixel aspect: 16/11, display aspect: 1.82, 25.000 fps
+ autocrop: 0/0/0/0
+ chapters:
+ 1: duration 00:00:30
+ audio tracks:
+ subtitle tracks:
+ combing detected, may be interlaced or telecined
[13:23:46] Starting work at: Wed Nov 27 13:23:46 2019
[13:23:46] 1 job(s) to process
[13:23:46] json job:
{
"Audio": {
"AudioList": [],
"CopyMask": [],
"FallbackEncoder": 0
},
"Destination": {
"AlignAVStart": false,
"ChapterList": [
{
"Duration": {
"Hours": 0,
"Minutes": 0,
"Seconds": 30,
"Ticks": 2732400
},
"Name": ""
}
],
"ChapterMarkers": false,
"File": "out_deinterlace.mp4",
"InlineParameterSets": false,
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "m4v"
},
"Filters": {
"FilterList": [
{
"ID": 3,
"Settings": {
"block-height": "16",
"block-thresh": "40",
"block-width": "16",
"filter-mode": "2",
"mode": "3",
"motion-thresh": "1",
"spatial-metric": "2",
"spatial-thresh": "1"
}
},
{
"ID": 5,
"Settings": {
"mode": "3"
}
},
{
"ID": 6,
"Settings": {
"mode": 0
}
},
{
"ID": 12,
"Settings": {
"crop-bottom": 0,
"crop-left": 0,
"crop-right": 0,
"crop-top": 0,
"height": 576,
"width": 720
}
}
]
},
"Metadata": {},
"PAR": {
"Den": 11,
"Num": 16
},
"SequenceID": 0,
"Source": {
"Angle": 0,
"Path": "test.mp4",
"Range": {
"End": 1,
"Start": 1,
"Type": "chapter"
},
"Title": 1
},
"Subtitle": {
"Search": {
"Burn": true,
"Default": false,
"Enable": false,
"Forced": false
},
"SubtitleList": []
},
"Video": {
"ColorFormat": 0,
"ColorMatrix": 5,
"ColorPrimaries": 5,
"ColorRange": 1,
"ColorTransfer": 5,
"Encoder": "x264",
"Level": "auto",
"Options": "ref=3:bframes=5:threads=6",
"Preset": "veryslow",
"Profile": "auto",
"QSV": {
"AsyncDepth": 4,
"Decode": false
},
"Quality": 20.0,
"Tune": "",
"Turbo": false,
"TwoPass": false
}
}
[13:23:46] Starting Task: Encoding Pass
[13:23:46] Skipping vfr filter
[13:23:46] Skipping crop/scale filter
[13:23:47] job configuration:
[13:23:47] * source
[13:23:47] + test.mp4
[13:23:47] + title 1, chapter(s) 1 to 1
[13:23:47] + container: mov,mp4,m4a,3gp,3g2,mj2
[13:23:47] + data rate: 3006 kbps
[13:23:47] * destination
[13:23:47] + out_deinterlace.mp4
[13:23:47] + container: MPEG-4 (libavformat)
[13:23:47] * video track
[13:23:47] + decoder: h264
[13:23:47] + bitrate 3003 kbps
[13:23:47] + filters
[13:23:47] + Comb Detect (mode=3:spatial-metric=2:motion-thresh=1:spatial-thresh=1:filter-mode=2:block-thresh=40:block-width=16:block-height=16)
[13:23:47] + Deinterlace (mode=35)
[13:23:47] + Output geometry
[13:23:47] + storage dimensions: 720 x 576
[13:23:47] + pixel aspect ratio: 16 : 11
[13:23:47] + display dimensions: 1047 x 576
[13:23:47] + encoder: H.264 (libx264)
[13:23:47] + preset: veryslow
[13:23:47] + options: ref=3:bframes=5:threads=6
[13:23:47] + profile: auto
[13:23:47] + level: auto
[13:23:47] + quality: 20.00 (RF)
[13:23:47] + color profile: 5-5-5
[13:23:47] sync: expecting 759 video frames
[13:23:47] encx264: encoding at constant RF 20.000000
[13:23:47] encx264: unparsed options: direct=auto:subme=10:bframes=5:threads=6:me=umh:b-adapt=2:analyse=all:merange=24:trellis=2:rc-lookahead=60
x264 [info]: using SAR=16/11
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 3.0
[13:23:47] sync: first pts video is 0
[13:23:47] sync: Chapter 1 at frame 1 time 0
[13:24:08] reader: done. 1 scr changes
[13:24:14] work: average encoding speed for job is 31.996778 fps
[13:24:15] comb detect: heavy 754 | light 1 | uncombed 1 | total 756
[13:24:15] h264-decoder done: 756 frames, 0 decoder errors
[13:24:15] sync: got 756 frames, 759 expected
[13:24:15] sync: framerate min 25.000 fps, max 25.000 fps, avg 25.000 fps
x264 [info]: frame I:4 Avg QP:19.81 size: 68802
x264 [info]: frame P:189 Avg QP:22.29 size: 30199
x264 [info]: frame B:563 Avg QP:27.85 size: 7011
x264 [info]: consecutive B-frames: 0.7% 1.3% 1.2% 89.9% 5.3% 1.6%
x264 [info]: mb I I16..4: 2.3% 56.3% 41.4%
x264 [info]: mb P I16..4: 1.2% 9.6% 3.8% P16..4: 39.4% 25.8% 15.6% 1.6% 0.4% skip: 2.6%
x264 [info]: mb B I16..4: 0.1% 0.6% 0.2% B16..8: 42.1% 12.8% 3.5% direct: 6.0% skip:34.6% L0:37.5% L1:42.8% BI:19.7%
x264 [info]: 8x8 transform intra:64.0% inter:42.2%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: coded y,uvDC,uvAC intra: 81.0% 75.3% 34.7% inter: 27.0% 16.7% 2.4%
x264 [info]: i16 v,h,dc,p: 20% 32% 12% 36%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 10% 9% 8% 11% 13% 9% 13% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 9% 5% 9% 13% 15% 11% 13% 12%
x264 [info]: i8c dc,h,v,p: 33% 23% 28% 15%
x264 [info]: Weighted P-Frames: Y:3.2% UV:1.1%
x264 [info]: ref P L0: 56.6% 16.0% 20.4% 6.7% 0.2%
x264 [info]: ref B L0: 88.9% 9.0% 2.0%
x264 [info]: ref B L1: 95.8% 4.2%
x264 [info]: kb/s:2627.02
[13:24:15] mux: track 0, 756 frames, 9929964 bytes, 2623.50 kbps, fifo 1024
[13:24:15] Finished work at: Wed Nov 27 13:24:15 2019
[13:24:15] libhb: work result = 0
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
There are two cases where it's worth using x265: very large frame sizes (4K and above) or encodes targeting very low bitrates (the kinds you see around RF 30+). If you're not one of those two cases, x265 is not worth using.
Of course, since it literally is not.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Some will say even using the same encoder, CRF 20 @ veryfast is not the same as CRF 20 @ veryslow.
Whether that is true or not, you have to think what CRF does.
(Note: using the same CRF doesn't mean the quality will be the same.)
Back to CRF on x264 and x265. I came across Introduction to x265 Rate Control Algorithm where the author claimed, "The rate control in x265 is the same as x264's implementation, which is mostly empirical".
But someone has wondered about it and has done some testing: Video Compression Testing: x264 vs x265 CRF in Handbrake 0.10.5.
I'm just going to cherry-pick a line from there: "It seems on the whole, both PSNR and SSIM metrics achieved similar values for corresponding x264 and x265 CRF values. As a result, at least from a synthetic quality standpoint, the quality of x264 and x265 encodes at the same CRF are nearly identical, ... ."
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Using an ancient version of HB, with an equally ancient version of the rapidly developing x265.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
I forgot to update this thread with my findings.
I did indeed find some time to encode using exactly the same settings as I did in v1.2.2, with the sole exception of adding :aq-mode=1 to Advanced Options in the Video tab, as advised earlier.
I do definitely feel the image quality is worse. Not so bad that you might notice immediately notice, but bad enough that I certainly will not be re-encoding my collection with v1.3.0. In my own opinion, To achieve similar quality to what I had before without aq-mode=1, my file sizes would need to increase by 25%. I thought that things might improve with each newer version of HandBrake, sadly it would seem that I could be mistaken.
On a similar note, file sizes still increase by almost 2%. I can accept that 2% is only a small increase, however it is not acceptable when the files are of inferior quality.
Something I am noticing is that some frames can be have images which seem blocky on lines. I never had this with v1.2.2 and I wonder if some setting isn't being acknowledged. This would also explain why the image quality is inferior.
Below are copped images to help compare - I hope this is allowed.
https://ibb.co/Yt10n5s - taken directly from the DVD, no processing performed. Look at the collar on the suit, you can see a dark line which is blocky.
https://ibb.co/ccPx93P - encoded with HandBrake v1.2.2. The dark line on the collar is not blocky.
https://ibb.co/BCY7XRq - encoded with HandBrake v1.3.0 with aq-mode=1 you can see the collar is blocky, like the DVD source image.
I did indeed find some time to encode using exactly the same settings as I did in v1.2.2, with the sole exception of adding :aq-mode=1 to Advanced Options in the Video tab, as advised earlier.
I do definitely feel the image quality is worse. Not so bad that you might notice immediately notice, but bad enough that I certainly will not be re-encoding my collection with v1.3.0. In my own opinion, To achieve similar quality to what I had before without aq-mode=1, my file sizes would need to increase by 25%. I thought that things might improve with each newer version of HandBrake, sadly it would seem that I could be mistaken.
On a similar note, file sizes still increase by almost 2%. I can accept that 2% is only a small increase, however it is not acceptable when the files are of inferior quality.
Something I am noticing is that some frames can be have images which seem blocky on lines. I never had this with v1.2.2 and I wonder if some setting isn't being acknowledged. This would also explain why the image quality is inferior.
Below are copped images to help compare - I hope this is allowed.
https://ibb.co/Yt10n5s - taken directly from the DVD, no processing performed. Look at the collar on the suit, you can see a dark line which is blocky.
https://ibb.co/ccPx93P - encoded with HandBrake v1.2.2. The dark line on the collar is not blocky.
https://ibb.co/BCY7XRq - encoded with HandBrake v1.3.0 with aq-mode=1 you can see the collar is blocky, like the DVD source image.
Code: Select all
HandBrake 1.3.0 (2019110900)
OS: Microsoft Windows NT 10.0.18363.0
CPU: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Ram: 16326 MB,
GPU Information:
NVIDIA GeForce GTX 1050 Ti - 26.21.14.4120
Screen: 1680x1050
Temp Dir: C:\Users\xyz\AppData\Local\Temp\
Install Dir: C:\Program Files\HandBrake
Data Dir: C:\Users\xyz\AppData\Roaming\HandBrake
-------------------------------------------
# Starting Encode ...
[11:33:42] base preset: AQ Mode 1 added
[23:33:42] hb_init: starting libhb thread
[23:33:42] Starting work at: Fri Dec 06 23:33:42 2019
[23:33:42] 1 job(s) to process
[23:33:42] json job:
{
"Audio": {
"AudioList": [
{
"Bitrate": 192,
"DRC": 0.0,
"Encoder": "av_aac",
"Gain": 0.0,
"Mixdown": 4,
"NormalizeMixLevel": false,
"Samplerate": 0,
"Track": 0,
"DitherMethod": 0
}
],
"CopyMask": [
"copy:aac",
"copy:ac3",
"copy:dtshd",
"copy:dts",
"copy:eac3",
"copy:flac",
"copy:mp3",
"copy:truehd"
],
"FallbackEncoder": "ac3"
},
"Destination": {
"ChapterList": [
{
"Name": "Chapter 1"
}
],
"ChapterMarkers": true,
"AlignAVStart": false,
"File": "E:\\dvd\\Are You Being Served - s01e01 - Dear Sexy Knickers.mp4",
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "mp4"
},
"Filters": {
"FilterList": [
{
"ID": 4,
"Settings": {
"mode": "7"
}
},
{
"ID": 9,
"Settings": {
"cb-frame-count": 2,
"cb-origin-tune": 0.9,
"cb-patch-size": 7,
"cb-prefilter": 0,
"cb-range": 3,
"cb-strength": 2.4,
"y-frame-count": 2,
"y-origin-tune": 0.9,
"y-patch-size": 7,
"y-prefilter": 0,
"y-range": 3,
"y-strength": 1.5
}
},
{
"ID": 13,
"Settings": {
"cb-kernel": "isolap",
"cb-strength": 0.06,
"y-kernel": "isolap",
"y-strength": 0.1
}
},
{
"ID": 12,
"Settings": {
"crop-bottom": "2",
"crop-left": "12",
"crop-right": "8",
"crop-top": "0",
"height": "574",
"width": "700"
}
},
{
"ID": 6,
"Settings": {
"mode": "1"
}
}
]
},
"PAR": {
"Num": 1,
"Den": 1
},
"Metadata": {},
"SequenceID": 0,
"Source": {
"Angle": 1,
"Range": {
"Type": "chapter",
"Start": 1,
"End": 1
},
"Title": 2,
"Path": "E:\\dvd\\Are You Being Served - s01e01 - Dear Sexy Knickers\\VTS_01_PGC_02_1.VOB"
},
"Subtitle": {
"Search": {
"Burn": false,
"Default": false,
"Enable": false,
"Forced": false
},
"SubtitleList": []
},
"Video": {
"Encoder": "x265",
"Level": "auto",
"TwoPass": false,
"Turbo": false,
"ColorMatrixCode": 0,
"Options": "strong-intra-smoothing=0:rect=0:aq-mode=1",
"Preset": "fast",
"Profile": "main",
"Quality": 25.0,
"QSV": {
"Decode": false,
"AsyncDepth": 0
}
}
}
[23:33:42] CPU: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
[23:33:42] - Intel microarchitecture Kaby Lake
[23:33:42] - logical processor count: 4
[23:33:42] Intel Quick Sync Video support: no
[23:33:42] hb_scan: path=E:\dvd\Are You Being Served - s01e01 - Dear Sexy Knickers\VTS_01_PGC_02_1.VOB, title_index=2
udfread ERROR: ECMA 167 Volume Recognition failed
src/libbluray/disc/disc.c:323: failed opening UDF image E:\dvd\Are You Being Served - s01e01 - Dear Sexy Knickers\VTS_01_PGC_02_1.VOB
src/libbluray/disc/disc.c:424: error opening file BDMV\index.bdmv
src/libbluray/disc/disc.c:424: error opening file BDMV\BACKUP\index.bdmv
src/libbluray/bluray.c:2585: nav_get_title_list(E:\dvd\Are You Being Served - s01e01 - Dear Sexy Knickers\VTS_01_PGC_02_1.VOB\) failed
[23:33:42] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.1
libdvdread: Encrypted DVD support unavailable.
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[23:33:42] dvd: not a dvd - trying as a stream/file instead
[23:33:42] file is MPEG Program Stream
[23:33:42] Probing 1 unknown stream
[23:33:42] Probe: Found stream mpegvideo. stream id 0xe0-0x0
[23:33:42] Found the following streams
[23:33:42] Video Streams :
[23:33:42] 0xe0-0x0 type MPEG2 (0x2)
[23:33:42] Audio Streams :
[23:33:42] 0xbd-0x80 type AC3 (0x81)
[23:33:42] Subtitle Streams :
[23:33:42] 0xbd-0x20 type DVD Subtitle (0x0)
[23:33:42] Other Streams :
[23:33:42] stream id 0xbd (type 0x81 substream 0x80) audio 0x8000bd
[23:33:42] stream id 0xbd (type 0x0 substream 0x20) subtitle 0x2000bd
[23:33:42] scan: decoding previews for title 2
[23:33:42] file is MPEG Program Stream
[23:33:42] Probing 1 unknown stream
[23:33:42] Probe: Found stream mpegvideo. stream id 0xe0-0x0
[23:33:42] scan: audio 0x8000bd: ac3, rate=48000Hz, bitrate=192000 Any (AC3) (2.0 ch) (192 kbps)
[23:33:43] stream: 55 good frames, 0 errors (0%)
[23:33:43] scan: 10 previews, 720x576, 25.000 fps, autocrop = 0/2/12/8, aspect 4:3, PAR 16:15
[23:33:43] libhb: scan thread found 1 valid title(s)
[23:33:43] Starting Task: Encoding Pass
[23:33:43] NLMeans using SSE2 optimizations
[23:33:43] NLMeans using 4 threads
[23:33:43] MTFrame thread started for segment 0
[23:33:43] MTFrame thread started for segment 1
[23:33:43] MTFrame thread started for segment 2
[23:33:43] MTFrame thread started for segment 3
[23:33:43] work: only 1 chapter, disabling chapter markers
[23:33:43] job configuration:
[23:33:43] * source
[23:33:43] + E:\dvd\Are You Being Served - s01e01 - Dear Sexy Knickers\VTS_01_PGC_02_1.VOB
[23:33:43] + title 2, chapter(s) 1 to 1
[23:33:43] * destination
[23:33:43] + E:\dvd\Are You Being Served - s01e01 - Dear Sexy Knickers.mp4
[23:33:43] + container: MPEG-4 (libavformat)
[23:33:43] * video track
[23:33:43] + decoder: mpeg2video
[23:33:43] + bitrate 200 kbps
[23:33:43] + filters
[23:33:43] + Decomb (mode=7)
[23:33:43] + Framerate Shaper (mode=1)
[23:33:43] + frame rate: 25.000 fps -> constant 25.000 fps
[23:33:43] + Denoise (nlmeans) (y-strength=1.5:y-origin-tune=0.9:y-patch-size=7:y-range=3:y-frame-count=2:y-prefilter=0:cb-strength=2.4:cb-origin-tune=0.9:cb-patch-size=7:cb-range=3:cb-frame-count=2:cb-prefilter=0)
[23:33:43] + Crop and Scale (width=700:height=574:crop-top=0:crop-bottom=2:crop-left=12:crop-right=8)
[23:33:43] + source: 720 * 576, crop (0/2/12/8): 700 * 574, scale: 700 * 574
[23:33:43] + Sharpen (lapsharp) (y-strength=0.1:y-kernel=isolap:cb-strength=0.06:cb-kernel=isolap)
[23:33:43] + Output geometry
[23:33:43] + storage dimensions: 700 x 574
[23:33:43] + pixel aspect ratio: 1 : 1
[23:33:43] + display dimensions: 700 x 574
[23:33:43] + encoder: H.265 (libx265)
[23:33:43] + preset: fast
[23:33:43] + options: strong-intra-smoothing=0:rect=0:aq-mode=1
[23:33:43] + profile: main
[23:33:43] + level: auto
[23:33:43] + quality: 25.00 (RF)
[23:33:43] + color profile: 5-1-6
[23:33:43] * audio track 1
[23:33:43] + decoder: Any (AC3) (2.0 ch) (192 kbps) (track 1, id 0x8000bd)
[23:33:43] + bitrate: 192 kbps, samplerate: 48000 Hz
[23:33:43] + mixdown: Stereo
[23:33:43] + dither: none
[23:33:43] + encoder: AAC (libavcodec)
[23:33:43] + bitrate: 192 kbps, samplerate: 48000 Hz
[23:33:43] file is MPEG Program Stream
[23:33:43] Probing 1 unknown stream
[23:33:43] Probe: Found stream mpegvideo. stream id 0xe0-0x0
[23:33:43] sync: expecting 42838 video frames
x265 [info]: HEVC encoder version 3.2.1+1-b5c86a64bbbe
x265 [info]: build info [Windows][GCC 8.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(9 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-25.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 rskip signhide tmvp fast-intra deblock sao
[23:33:43] sync: first pts video is 0
[23:33:43] sync: first pts audio 0x8000bd is 0
[23:52:17] reader: done. 2 scr changes
[23:52:20] work: average encoding speed for job is 38.713402 fps
[23:52:20] decomb: deinterlaced 43216 | blended 0 | unfiltered 0 | total 43216
[23:52:20] vfr: 43216 frames output, 0 dropped and 0 duped for CFR/PFR
[23:52:20] vfr: lost time: 0 (0 frames)
[23:52:20] vfr: gained time: 0 (0 frames) (0 not accounted for)
[23:52:20] stream: 567583 good frames, 1 errors (0%)
[23:52:20] ac3-decoder done: 54018 frames, 0 decoder errors
[23:52:20] mpeg2video-decoder done: 43216 frames, 0 decoder errors
[23:52:20] sync: got 43216 frames, 42838 expected
[23:52:20] sync: framerate min 25.000 fps, max 25.000 fps, avg 25.000 fps
x265 [info]: frame I: 329, Avg QP:26.28 kb/s: 4572.55
x265 [info]: frame P: 8624, Avg QP:27.14 kb/s: 1587.69
x265 [info]: frame B: 34263, Avg QP:32.32 kb/s: 236.23
x265 [info]: Weighted P-Frames: Y:2.4% UV:1.5%
x265 [info]: consecutive B-frames: 3.5% 0.5% 0.6% 0.7% 94.7%
encoded 43216 frames in 1117.19s (38.68 fps), 538.94 kb/s, Avg QP:31.24
[23:52:20] mux: track 0, 43216 frames, 116626275 bytes, 539.72 kbps, fifo 4096
[23:52:20] mux: track 1, 81028 frames, 41610233 bytes, 192.56 kbps, fifo 8192
[23:52:20] Finished work at: Fri Dec 06 23:52:20 2019
[23:52:20] libhb: work result = 0
# Encode Completed ...
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
That looks like an deinterlacing issue.
It is deinterlaced in 1.2.2 and not in 1.3.0.
It is deinterlaced in 1.2.2 and not in 1.3.0.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
You are exactly right!
I did a lot of testing last night to try and find out what the cause.
These are the settings I use on the Filter tab:
Detelecine - Off
Interlace Detection - Off
Deinterlace - Decomb -- Preset - Default
Denoise - NLMeans -- Preset - Ultralight -- Tune - Film
Sharpen - LapSharp -- Preset - Light -- Tune - Film
Deblock - Off
Grayscale - Not ticked
Rotate - 0 -- Flip - Not ticked
These are set exactly in v1.3.0 as they are set in v1.2.2. So I am very confused about why things have changed now. Perhaps this is a bug?
The deinterlacing issue only goes away if I do not use any Deinterlacing option. Otherwise the issue is present with any of the settings.
I think I should now start a new thread about this, as this seems to be another issue. Or perhaps it is do with H.265?
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Some News about?
Same here, much bigger Files with no quality improvement.
Do i raise the CRF once, Quality will be worse and File still is a little Bigger.
Actually i dont' see any reasons to go with v1.3.0 and newer if them just produce much bigger Files without any improvements at all.
What should be the sence of this changes?
Same here, much bigger Files with no quality improvement.
Do i raise the CRF once, Quality will be worse and File still is a little Bigger.
Actually i dont' see any reasons to go with v1.3.0 and newer if them just produce much bigger Files without any improvements at all.
What should be the sence of this changes?
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Rodeo wrote: ↑Fri Nov 22, 2019 11:12 pm Yes, AQ is a major component of rate control and can result in very different bitrates for the same RF, even everything else being equal. Unfortunately this does mean users may have to adjust the RF for their custom presets (or manually specify AQ mode 1 via the advanced options text box, "aq-mode=1" without quotes).
Quoting Rodeo since he's already explained this.
RF 20 in 1.3.0 != RF20 in 1.2.0
As a result, you need to adjust to compensate for the changes or set the older aq-mode style.
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Constant quality is constant across different files, not across different encoder settings. RF 20 with aq-mode 1 is not the same as RF 20 with aq-mode 2.
If you can't see a difference with the larger output, your quality target is probably too high (RF value too low).
Re: H265 in new HandBrake 1.3.0 gives 30-60% higher bitrate
Also did several HEVC Encodes to try, settings almost default 1080p30 with set the 30BpS as "Same as Source"
1.2.2 > comparative Encode
1.3.0 > AO 2 / same quality / often much bigger Files (especially if the source has more visible grain)
1.3.0 > AO 1 / visible worse quality / same size
In conclusion, it seems like the 1.3.0 is a step backwards in quality with nice GUI features.
Would be there a way to get 1.2.2 with the 1.3.0 GUI?
1.2.2 > comparative Encode
1.3.0 > AO 2 / same quality / often much bigger Files (especially if the source has more visible grain)
1.3.0 > AO 1 / visible worse quality / same size
In conclusion, it seems like the 1.3.0 is a step backwards in quality with nice GUI features.
Would be there a way to get 1.2.2 with the 1.3.0 GUI?