Well he certainly shouldn’t have KEPT an unwelcome guest splotch on his schnozz!
More on CRF + VBV, what I’m going to go read about next:
I saw a good description of how h264 and h265 differ: h265 is capable of producing tolerable video at significantly lower bitrates than h264 is. For somebody hunting the smallest files and willing to tolerate “some” quality loss, it’s amazingly better. For people who are trying to surf “quality/size/time” it’s harder to make any absolute statements about which is “best”.
And this exhaustive comparison was very interesting, because it shows greater differences between different h265 implementations, and how well x264 stands up against some of them. It’s also not very flattering to the x265 implementation.
I believe the x264 encoder is considered to be a leader among h264 implementations, where the x265 encoder (in Handbrake and FFmpeg) clearly … isn’t.
You can also see how h265’s lead over h264 vanishes at higher bitrates.
I also found this page with pretty graphs and pictures:
That one, most importantly, says that Juice is wrong and I’m right. At higher bitrates than we’ve been discussing, he found a scenario where CRF files score one gnat’s-hair higher in quality than an ABR file. It’s an impressively insignificant and somewhat contrived difference. But I’m going to crown myself with one Internet Point, because I’m a winner.
MKV is a container and has virtually no impact on the space the file takes up. 264 has advantages (quicker to make, easier to decode, supported natively on more clients) 265 has some advantages (mostly better quality image at any given bitrate)
So I had a movie that I had encoded at my usual 6.5 Mbps 10Bit x265, but when I played it in Plex, both the Dashboard and Tautulli were reporting that I was using 18.3 Mbps.
Now I am aware that the total bitrate does obviously include the Audio track, and yes, the movie had been on my system for some time, and therefore Plex had already done a Deep Analysis of it.
After much reading, I found out that when using ABR, there are times when a much higher bitrate may be used for scenes with a lot of motion.
So I re-ripped the original, and used Bitrate Viewer to take a look, and indeed there were a few rather large spikes.
… and now you’ve committed the ultimate sin… Starving the bit rate without a safety net.
Oh yes, I’m a bit rate torturer. An evil individual to be sure.
I don’t limit the peak bit rate and I use a 2 pass encode.
Most of my recent 265 stuff is AVB at 1250kbps and when going through Plex is reported as 12Mbps (give or take) 'cause there’s at least some scene in there that wanted that much - and got it - and that’s fine by me.
I let HB have a first pass to think about what it wants to do on the second.
Single pass is hoping HB gets it right in a drive-by-shooting and I’ve seen what happens when it doesn’t… not pretty.
Indeed. It’s not a mystery, but when you mention ‘Peaks’ - it’s a concept previously gone unnoticed by (some of) the masses.
I suddenly wonder if over-bursty video is the cause of lots of forum complaints. “My should-be-good-enough device behaves poorly on this one video…”
Are you aware of a friendlier tool for looking at h264/h265 bitrate? I’d definitely like to compare CRF/ABR/+VBV averages and spikes. Maybe I’ll try what he mentions first.
My sarcasm detector is out of order, so I’m not sure … what do you mean? Without a safety net?
I’m assuming axe DID set a target bitrate and is doing 2-pass ABR. He just added these additional parameters to whatever he already has.
I’m also assuming they’re set HIGHER than his ABR rate? Axe?
If these work the way I’m imagining, they’re like a speed governor. You can go faster and slower, but you can’t ever exceed 88mph. So even if the encoder says “I’d sure like to go 100mph here!” these stomp in and say “only 88mph, buddy”.
Edit: Yeah, he said ABR at 6500, vbv-maxrate=8500:vbv-bufsize=17000.
I assume there are some defaults for maxrate and bufsize. I wonder how much of a change this is.
they probably do exactly that. To me it sounds like a bad idea.
What happens to Axe if that 8500 isn’t high enough?
I Know what’ll happen - that scene will look like the North end of a Southbound mule.
I don’t know what pipe you have, but I only have 19Mbps upload, and so need to control it, to try to ensure that most users get the very best experience possible, which means no transcode.
We’ve already spoken on another thread about sound quality, and it is just as important for some of my users, as it is to me.
So if I can give them HD Audio, I will…
Trust me when I say, I have watched the entire film back, paying VERY close attention to the areas where there were peaks, and saw absolutely no problems! And I insist upon quality!
Then don’t limit ABR bit rates any further - 'cause the fact is you, or I don’t know what a particular scene actually requires… do we?
You could starve a LOT more - if you let HB figure it out for you.
There is a LOT in a video that can be very happy at 1250kbps and some can’t. I don’t know - and neither do you, but Handbrake does I bet. <—when it gets that first pass to take a look and devise an evil plan…lol
I don’t have to watch 'em all the way through to know it’s gonna be OK.
One of these just went out of here and Plex says it was 3.5Mbps:
General
Unique ID : 49626979565190215205324239720074850945 (0x2555CF005EF2A11533EE337A02963281)
Complete name : D:\TV-Trash\Big Dogs\Season 01\Big Dogs - S01E01 - Noricum Ripense.mkv
Format : Matroska
Format version : Version 4
File size : 544 MiB
Duration : 56 min 49 s
Overall bit rate : 1 338 kb/s
Encoded date : UTC 2020-07-17 19:24:28
Writing application : Lavf58.42.100
Writing library : Lavf58.42.100
ErrorDetectionType : Per level 1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 56 min 49 s
Bit rate : 950 kb/s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Variable
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Stream size : 377 MiB (69%)
Writing library : x264 core 157 r2935 545de2f
Encoding settings : cabac=1 / ref=1 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=2pass / mbtree=1 / bitrate=950 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : Identity
matrix_coefficients_Original : BT.709
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 56 min 49 s
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 156 MiB (29%)
Title : Surround
Writing library : Lavc58.77.101 ac3_fixed
Language : English
Service kind : Complete Main
Default : Yes
Forced : No
Well, ABR is 950kbps so somebody needed more cowbell - and got it - while there was a whole lot of it that was happy at 950kbps - cause in an hour the file only ate 544MB.
I like the idea of CRF because it means “go wild with bandwidth, just make sure you do a good job”. (I also like CRF because everybody in the Handbrake and x264 world recommends it for quality.) In my experience I do get very “peaky” files, but I’m never disappointed that it misses a quality target. I’m going to look at how bursty my files really are, and I’m going to investigate if the VBV limits could help me stream to my remote users.
I thought you liked the idea of ABR because it meant a consistent/predictable streaming bitrate. I think the idea of the VBV limits would be very attractive to you. One of the x264 developers specifically said they’re the “right” way to deliver max-bitrate-and-quality-while-controlling-for-streaming-peaks.
It seems like you’re saying CRF doesn’t delivery on quality - I disagree, but that’s OK. But the ABR+VBV seems like it’s precisely what you would want.
The idea of “ABR, but let it spike as much as it needs” doesn’t make any sense to me. That’s just … isn’t that … isn’t that CRF, with extra steps?
x264’s default is not to limit the peak bitrate at all
(With some exceptions, oh look, for the iPod … document from 2012 … hrm. It’s like being a documentation archaeologist.)
For x264 Handbrake definitely has some default --vbv-maxrate and --vbv-bufsize settings, but I think they’re just the h.264 “average” settings. They’re much larger than the bitrates we’re talking bout for ABR or what my CRF settings deliver.
I should spin up another Plex (w/ transcoding disabled, hahaha!) and invite you guys to view my resulting files.
My outgoing pipe is 50Mbps - I may have to do 4 of 'em (2 or 3 is rather common) and the most I’ve ever seen Plex report is 12 or so - that should do it - and does - so far.
12Mb is 4Mb beyond your 8500 limit you just put on yourself.
Bad idea. IMO.
IMDB says 5.6… it’s on Prime (for a reason, I think).
The problem with Prime is I can’t hear it… and I would like to see if it’s as bad as it’s being reported as…lol
It wasn’t a lot of effort to encode the entire season while I was into that last 2 hour nap BEFORE MY NOSE BLEW UP AGAIN!
Mine is 19 Mbps… So I cannot be quite so complacent!
And here is where opinion starts to become irrelevant…
I’ll say this one last time, incase you skimmed my post again…
I watched the resulting movie from beginning to end, paying particular attention to the known problem areas (which had tons of fast movement all over the screen) and it all looked perfect…
The result??? I’ve achieved my goal, with NO loss of visible quality.
