Advanced feature request-- x264, x265 additional parameters

musicvid

Member
I was thinking maybe via a command line box in Advanced Options, using regular x264 syntax, and would append the GUI's encoder string. I use --vbv-maxrate and --vbv-bufsize a lot for streaming, occasionally --deblock and others for special cases.
 
Last edited:

tluxon

Member
When Constant Rate Factor is chosen, I would gladly trade the long Rate factor slider bar for something like a drop-down selection or an increase/decrease scroller to make room for an Encoder Preset speed selector.
 

Danr

Administrator
Staff member
I was thinking maybe via a command line box in Advanced Options, using regular x264 syntax, and would append the GUI's encoder string. I use --vbv-maxrate and --vbv-bufsize a lot for streaming, occasionally --deblock and others for special cases.
vbv-maxtrate is automatically set to the maximum bit rate in the output profile.
vbv-bufsize is also set to the maximum bit rate in the output profile, but only for CBR encoding and transport stream output (.ts and .m2ts).

We currently don't have a setting for deblocking and I'm not sure yet how much of the command line options we can process. What settings do you typically use for deblock?
 

Danr

Administrator
Staff member
When Constant Rate Factor is chosen, I would gladly trade the long Rate factor slider bar for something like a drop-down selection or an increase/decrease scroller to make room for an Encoder Preset speed selector.
The encoder preset is available on the advanced tab.
2801
 

musicvid

Member
vbv-maxtrate is automatically set to the maximum bit rate in the output profile.
And therein lies part of my problem with small home and wan streaming servers. Unconstrained (except by profile) peak bitrates typically cause stalls, stutters, and hiccups. Wifi is especially touchy about this. Capping vbv-maxrate is an effective prevention against this, at the expense of some high-motion detail. Also, on enterprise/school servers, media bandwidth control is essential if one is serving CQ/CRF and not converting everything to ABR/CBR, where even more source-level control is possible.
vbv-bufsize is maintained at 15-25% larger than vbv-maxrate, effectively preventing underflow.
Any x264/x265 parameters could be fed to the encoder with a cli textbox, that could simply append the preset input string. It might also eliminate the need for some lesser-used checkboxes.

My --deblock settings are typically {-1,0} or even {-2,-1}, if the source will bear it. We also sometimes turn off 8x8dct, b-pyramid, etc. for barebones CABAC encoding. Here's a really basic example of my custom parameters (a little larger files, but fast!):
Code:
level=4.1 --ref=1 --8x8dct=0 --weightp=1 --b-pyramid=none  --subme=2 --mixed-refs=0 --trellis=0 --vbv-bufsize=30000 --vbv-maxrate=25000 --rc-lookahead=10 --deblock=-1,0
If I forgot to say it, I am very pleased with V6, now that I am relearning the interface after a hiatus.
 
Last edited:

tluxon

Member
The encoder preset is available on the advanced tab.
View attachment 2801
Wow - thanks for the tip!

When I looked at the advanced options previously I saw that it was grayed out and assumed it was disabled by the selection of something like CRF. It wasn't intuitively obvious to me that checking the box would enable modification. This opens up a whole new world that I thought was locked.

I wonder if the graying out of unticked items has confused anyone else like it did me...
 

Danr

Administrator
Staff member
Currently you can set all those parameters on the advanced encoding group except for vbv-bufsize, deblocking, trellis, and 8x8dct. 8x8dict is automatically set to 0 for low and main profile and 1 for high-profile.
 

musicvid

Member
I see nothing taxing about leaving --vbv-bufsize at it's maximum.
I disable 8x8dct only in Main Profile, along with the other stuff to achieve a leaner, faster encode, so again not an issue.
Deblocking is discretionary, and it would be good to see eventually.

Where is --vbv-maxrate? I see something called "VBV size" in Advanced Options, but that doesn't sound right. Using CRF.
 

Danr

Administrator
Staff member
When using CRF, vbv_maxrate is set to 0. I thought that vbv-maxrate was only used for CBR and ABR, how does vbv-maxrate get utilized with CRF?

Turns out, the VBV size, which is specified in bytes, if used, gets loaded into vbv-bufsize.
 

musicvid

Member
maxrate.jpg
When encoding CQ / CRF, vbv-maxrate looks visually similar to soft limiting in audio production. There is no additional bitrate compression below a certain threshold level. Not precise, but it sure saves a lot of cursing at the home media or NAS server.
In this example, a typical home media server over wifi might start to drop frames at 32-35 Mbps on long-GOP streams. Obviously with 44 Mbps peaks, it means a full stall and reload. It will always stall at about the same place, contingent on other traffic.

With the bitrate capped (you can see it isn't perfect with CRF), the segment plays smoothly at around 30 Mbps peak, but without affecting Average or Minimum bitrates. Slight motion blur will result, but its a tradeoff we make for trying to stream this stuff.

I first learned about this back when Youtube was using x264, and all the metadata was exposed. Handbrake soon started following suit, and my 100TX classroom clients got a lot happier, too.
 
Last edited:

Danr

Administrator
Staff member
That makes total sense, esp. with the bitrate viewer graphs. I'll discuss with DanH (he maintains all the profile stuff) how we can still leave Max bit rate enabled when CRF is enabled.
 

musicvid

Member
Thank You!
There is probably no need to have vbv-bufsize in Advanced Settings. It is mainly for buffer control so leaving it at Profile max is probably fine.
Maybe you could just replace the line with vbv-maxrate in a future release?
 
Last edited:

tluxon

Member
This may or may not be related.

I have a short 1080p segment I recorded with a handheld (for some motion-blur) at about 27 MB/s and 59.94 frames/s. After QSF, I've recoded it at every Encoder preset speed using HandBrake 1.2.2 x265 and VRDTV6 (808) HEVC at CQ22 and CRF22, respectively. The profile I chose to tweak from HandBrake was "Vimeo YouTube HQ 1080p60" with the only changes being the H.265 Codec and Same as source Framerate. I did essentially the same thing in VRD by selecting HEVC as the Codec.

At each preset I got files with the following resulting bitrates.

Ultra Fast, HB 5145, VRD 5522
Super Fast, HB 6179, VRD 7361
Very Fast, HB 5659, VRD 7361
Faster, HB 5653, VRD 7359
Fast, HB 5794, VRD 7489
Medium, HB 6344, VRD 8315
Slow, HB 6743, VRD 7361
Slower, HB 6960, VRD 7361
Very Slow, HB 6965, VRD 7361
Placebo, HB 7086, VRD 7361

I've been re-encoding since before the turn of the century, but I never really delved into it much. I played around with a couple filters here and there without full understanding what I was doing, but noticing I could sometimes make a video more pleasing to watch. Back then my primary purpose was to cut and join video into a versatile format without losing too much apparent detail.

There are noticeable differences in the bitrates above, but watching the videos back side-by-side I usually couldn't readily spot the ones that were at higher or lower bitrates. Whatever is going on to meet the Constant Quality goal "seems" to be working well from my perspective.

What I'd like to better understand is what I might be trading off when opting for smaller files sizes, because a slower encode certainly did not consistently yield a smaller file. I'm curious to know if there is any color-remapping (compression) being utilized, because that's one of the things I'd rather not trade away for lower bitrates. If it's mostly something like a vbv-maxrate difference, that is something I would very much like to take advantage of.
 

musicvid

Member
What I'd like to better understand is what I might be trading off when opting for smaller files sizes,
"Size, Quality, Speed. Pick two."

Note that presets will give different, sometimes contradictory results for each unique source footage.
More like aiming for a zone than a precise target, they are more consistent with programs longer than yours.
Ultrafast is the fastest encoding and biggest files at a constant quality, but take less time and are larger than Medium preset.
Placebo is the slowest encoding and smallest files at the same quality, perhaps in theory only. They could have called it the "Kitchen Sink" preset.
.
 
Last edited:

tluxon

Member
"Size, Quality, Speed. Pick two."

Note that presets will give different, sometimes contradictory results for each unique source footage.
More like aiming for a zone than a precise target, they are more consistent with programs longer than yours.
Okay, I've been an engineer (for nearly 40 years) where 360 of something are considered a HUGE sample size, but I can see how with video dividing those frames up in various ways (where I-frames can be far, far apart from each other) it's not. I was just figuring it might be enough to see some trends in size and appearance without investing a ton in time and space.

What length and type of video do you recommend I use to try to ferret out some of the differences I could notice?
Ultrafast is the fastest encoding and biggest files at a constant quality, but take less time and are larger than Medium preset.
Placebo is the slowest encoding and smallest files at the same quality, perhaps in theory only. They could have called it the "Kitchen Sink" preset.
.
Most of my video clips (we're talking family videos of kids in sports and music and birthday party type stuff) are 1-2 minutes in length with some being perhaps up to 5 minutes in length. In the past I converted most of these (staying with the AVC flavor of h.264) using an average bitrate target of 6kbps (with peaks up to 15kbps) and and preset speed of very slow. Using preset speed, I was able to easily discern differences in size and visual quality.

Encoding with x265 and in particular constant quality is fairly new to me. I've known about it and the arguments for using it for a long time, but I was trying to keep bitrates in a range where clips could be joined fairly easily.

Just for grins, I ran x265 encodes of a clip about 2 minutes long at Fast preset and at Placebo preset. Sure enough, the Placebo encode took a ve-r-r-r-y lo-o-o-o-n-g time to encode and didn't look markedly better. But instead of finding the file to be at least a little smaller, it was actually more than 10 percent larger than the Fast preset recoded file. So I'm very curious as to what might really be going on "under the hood" to require/justify such long encode times?
 
Last edited:

tluxon

Member
I appreciate your insight and attempt to help without knowing exactly what I may or may not understand.

I was planning to stick with x264 and average bitrate-based "very slow" speed encoding. That is until I recoded some video that had motion blur from severe camera motion that was handled far, far better by x265 and cq. The difference was that the 6kbps x264 recoded video actually hung up VLC without even streaming and the x265 cq22 recoded video played silky smooth even when streaming over wi-fi to my Android tablet. I know it may seem silly and premature, but it would be hard to go back to x264 after that experience. Perhaps the use of advanced settings could return x264 back to the top for me if I had a better idea what I should try.

Thanks!!
 

Danr

Administrator
Staff member
musicvid, I have a couple question about encoding buffer size. I'm used to dealing with the buffer size when working with program and transport streams as it determines the size of the elementary stream buffer, but am not familiar with why it would benefit a VBR/CRF encoded stream used for streaming. Also, doesn't buffer size maintenance in the encoder imply HRD compliance? What happens if you don't specify HRD compliance during encoding?

Also, the advanced H264 parameters are shared, when possible, with all the H264 encoders so the naming needs to be somewhat generic and not X264 specific.
 

jmc

Active member
I've been re-encoding since before the turn of the century, but I never really delved into it much. I played around with a couple filters here and there without full understanding what I was doing, but noticing I could sometimes make a video more pleasing to watch. Back then my primary purpose was to cut and join video into a versatile format without losing too much apparent detail.
"noticing I could sometimes make a video more pleasing to watch"...

"Contour" filter, found that in my poking about in TMPGEnc Video Mastering Works and was amazed at the improvement
in old fuzzy/faded/off color tape mpgs. The "fuzzy" in the mpgs was mostly GONE.

Enough so that I'm redoing hundreds of hours of old mpg files.
That along with contrast and color adjustments is going to take a "little less" then that hundreds of hours.

I might be buying a Nvidia video card to test the "Turing GPU hardware encoding" -NVEnc.
If that is utilized then the time needed will be GREATLY less.
 
Last edited:
Top Bottom