Adding Keyframes & Trimming

[KanarazuKatsu]

Hello guys, I was wondering if anyone was familiar with avs4x265 as a pipeline in combination with x265. If someone knows how to do this with ffmpeg, could you provide me with the .bat code to run this? I'm inexperienced with ffmpeg, so I am using avs4x265 as it is more user-friendly for me.

This might sound weird or unorthodox, but I hope you hear me out and that hopefully someone knows what to do.

Okay, so basically we start off with the source. Let's say the source was your favorite television show (any episode, really). An episode typically goes in the follow orders of:

Prologue > Opening > Episode > Ending > Preview

What I basically want to do with the source is using a .avs script to trim out the Opening & Ending, and while keeping the source as it is without encoding it though. Ultimate, I'd end up with a .hvec file with the Prologue, Episode & Preview (with Opening & Ending cut out).

I know how to trim them out in a .avs script, but the problem is, I want the trimmed sections not to be encoded. Is there a setting in x265 where it will just skip the encoding process but generate the .hvec?

Thank you guys!

[Asmodian]

I am not sure what you mean, anything trimmed in Avisynth will not be encoded by definition (trimming removes those frames from the output video).

Wait, you want to trim without reencoding? That is not possible with HEVC as far as I know. It would be called "smart rendering" or similar and will still reencode some frames.

[sneaker_ger]

Instead of AviSynth use mkvtoolnix. Set splitting in output tab to "by parts based on frame/field numbers". If you hover the mouse over the field below a tool tip will show how. It's similar to AviSynth trim. E.g. in AviSynth you trimmed from 100 to 200 and 500 to 700 then in mkvtoolnix you enter "100-200,+500-700".

Note that HEVC is a very complex format and mkvtoolnix will only try to cut on I frames. It is not 100% frame-accurate and may even break in certain conditions. I haven't yet seen any "smart" cutting software for HEVC. (Doesn't necessarily mean it doesn't exist, maybe I just missed it ...)

[KanarazuKatsu]

I am not sure what you mean, anything trimmed in Avisynth will not be encoded by definition (trimming removes those frames from the output video).

Wait, you want to trim without reencoding? That is not possible with HEVC as far as I know. It would be called "smart rendering" or similar and will still reencode some frames.

Hmm, sorry about that. I'll try to make things more specific as it was confusing for you.

First, I'm going to encode the episode in parts, and reassemble them into a full episode because I will be encoding some parts at different settings compared to the other sections of the episode. This is because some scenes acquire more attention than others due to complex colours/motions/etc.

After reassembling the episode by attaching the files together with MKVToolNix, this is where my first post comes in.

I want to put the fully encoded episode now through the trimming process again. The issue is, I don't want to have to run my already encoded file through the encoding process again. It has already been encoded once. What I basically want to do with the fully encoded file is using a .avs script to trim out the Opening & Ending, and add keyframes at the end of the Prologue and Episode segment, then the output file will be Prologue + Episode + Preview in a .hvec file. Adding keyframes requires x265 and I'm not sure if you can disable the encoding process and just spit out an untouched .hvec, except just trimmed up with the keyframes added to it. As you may know, this method is sometimes known Ordered Chapters (The OP & ED are placed in the same folder as the episode section and will play the whole episode accordingly as if it was a complete episode). I suppose I could set the crf to like 1 or something or remotely close to this, but I'd rather not put it under encode processing again... due to more time and energy wasted, and as well as it not being lossless as it was already lossy from the first encode.

I hope this clears things up a bit. Also, thank you for your help. It means a lot.

Instead of AviSynth use mkvtoolnix. Set splitting in output tab to "by parts based on frame/field numbers". If you hover the mouse over the field below a tool tip will show how. It's similar to AviSynth trim. E.g. in AviSynth you trimmed from 100 to 200 and 500 to 700 then in mkvtoolnix you enter "100-200,+500-700".

Note that HEVC is a very complex format and mkvtoolnix will only try to cut on I frames. It is not 100% frame-accurate and may even break in certain conditions. I haven't yet seen any "smart" cutting software for HEVC. (Doesn't necessarily mean it doesn't exist, maybe I just missed it ...)

Yes, unfortunately I am aware that MKVToolNix isn't the best when performing precise cuts. This poses as an issue as a result.

I just hope that there better ways of trimming and just adding keyframes without having to run encoding on it in the future.

Please read my reply to Asmodian for more details regarding this matter if you'd like to make more sense in why I would like to do this.

Thank you for your input. I really appreciate it.

[sneaker_ger]

Can you explain the whole process and reasoning behind your workflow in more detail? I don't really understand (I know how ordered chapters work, that's not it).
One thing I noted: you say you want to put keyframes at the end of the prologue and episode segments but that's not how it works. You need keyframes at the beginning of the episode and preview segments. Now if you encoded each segment separately this will already be the case as every x265 encode will start on an IDR frame to begin with.

[sneaker_ger]

Can you explain the whole process and reasoning behind your workflow in more detail? I don't really understand (I know how ordered chapters work, that's not it).
One thing I noted: you say you want to put keyframes at the end of the prologue and episode segments but that's not how it works. You need keyframes at the beginning of the episode and preview segments. Now if you encoded each segment separately this will already be the case as every x265 encode will start on an IDR frame to begin with.
And you say you encode, then reassemble, then encode again. :confused: Why do you encode so often? You shouldn't encode more than once.


A sane process for creating ordered chapters:
1. Get high quality source (e.g. rip losslessly from Blu-ray using MakeMKV)
2. Open the lossless source in AviSynth
3. Trim away OP and ED in AviSynth. If you want to hard-code subtitles they belong in this script.
4. Encode the AviSynth script using x265. Use --qpfile (http://x265.readthedocs.io/en/default/cli.html#cmdoption-qpfile) option to set IDR frames at the first frames of episode and preview.
5. Encode OP and ED through a separate script with same x265 settings. If you want to hard-code subtitles they belong in this script.
6. Mux all resulting files to mkv and add ordered chapters using mkvtoolnix.
7. Add soft subtitles to mkv if wanted.

As you note there is only a single instance in which the file is encoded. Splitting only happens in AviSynth. Appending only by the player during playback with the ordered chapters.

[KanarazuKatsu]

Can you explain the whole process and reasoning behind your workflow in more detail? I don't really understand (I know how ordered chapters work, that's not it).
One thing I noted: you say you want to put keyframes at the end of the prologue and episode segments but that's not how it works. You need keyframes at the beginning of the episode and preview segments. Now if you encoded each segment separately this will already be the case as every x265 encode will start on an IDR frame to begin with.
And you say you encode, then reassemble, then encode again. :confused: Why do you encode so often? You shouldn't encode more than once.

A sane process for creating ordered chapters:
1. Get high quality source (e.g. rip losslessly from Blu-ray using MakeMKV)
2. Open the lossless source in AviSynth
3. Trim away OP and ED in AviSynth. If you want to hard-code subtitles they belong in this script.
4. Encode the AviSynth script using x265. Use --qpfile (http://x265.readthedocs.io/en/default/cli.html#cmdoption-qpfile) option to set IDR frames at the first frames of episode and preview.
5. Encode OP and ED through a separate script with same x265 settings. If you want to hard-code subtitles they belong in this script.
6. Mux all resulting files to mkv and add ordered chapters using mkvtoolnix.
7. Add soft subtitles to mkv if wanted.

As you note there is only a single instance in which the file is encoded. Splitting only happens in AviSynth. Appending only by the player during playback with the ordered chapters.

Hello, thanks for the reply! ^^

Yes, I know that this is the normal process (and I know how to do the method you mention), but what you just described means that the whole encoded file of the episode is with one full set of encoding parameters. This also means that most likely some parts of the episode may not be as good quality as in some parts (eg. dark scenes, quick motion scenes and may display pixels as a result - or called blocking). In this case, I want to split the episode up into separately encoded parts with some parts with higher quality settings (eg. lower crf values, etc), while the rest with decent settings (average crf value ranges because they look great regardless if it is slightly higher values).

The problem is, by splitting the encode up into pieces, when I append them all back with MKVToolNix, there are no keyframes from where I'd want them to be in for the episode .hevc file. So when I insert the OP and ED in the appropriate places in the episode .hvec order chapter file (.xml), it has this stutter where after it finishes playing the OP or ED, it flashes back a clip of the previous few frames before these are played.

Therefore, I want to reassemble all of the separately encoded parts, including the OP & ED to form the whole episode itself. This time, trimming them, and inserting the keyframes properly with the --qpfile and somehow not run it through x265 encoding and still produce the file with keyframes in it.

Unless ffmpeg is able to somehow take my fully encoded episode, and trim it through a .avs script along with the input of keyframes, then losslessly form the file.

I don't know anymore, lol. I just hope maybe you have a better idea on what to do because I am only coming up of ways to do this. My experience with avs4x265.exe and ffmpeg.exe is not that great - although I use avs4x265.exe more.

Thanks again! :O

[sneaker_ger]

The problem is, by splitting the encode up into pieces, when I append them all back with MKVToolNix, there are no keyframes from where I'd want them to be in for the episode .hevc file. So when I insert the OP and ED in the appropriate places in the episode .hvec order chapter file (.xml), it has this stutter where after it finishes playing the OP or ED, it flashes back a clip of the previous few frames before these are played.

Therefore, I want to reassemble all of the separately encoded parts, including the OP & ED to form the whole episode itself. This time, trimming them
But trim what? You say you already encoded the parts separately (thus having each part start on an IDR frame). What do you need to trim? Why don't you trim before/when you encode each part?


(Again: you cannot pass from AviSynth to x265 and have it not re-encode everything. Not possible. AviSynth will always output uncompressed video, x265 only accepts uncompressed video as input.)

[KanarazuKatsu]

But trim what? You say you already encoded the parts separately (thus having each part start on an IDR frame). What do you need to trim? Why don't you trim before/when you encode each part?


(Again: you cannot pass from AviSynth to x265 and have it not re-encode everything. Not possible. AviSynth will always output uncompressed video, x265 only accepts uncompressed video as input.)

Hmm, okay, for example. Let's say the trim was like this:
Trim(0, 100) ++ Trim(200, 400) ++ Trim(500, 550)

This this how the episode would look like right for the episode .hvec file normally. Prologue > Episode > Preview.

The opening would be Trim(101, 199), the ending would be Trim(401, 499).

The --qpfile would have the frames: 101 I -1, and 302 I -1 Is that correct?

Then we would normally create the .xml file to link these OP, ED & Episode .mkv files.

The only problem is say, (270, 310) of the episode had complex colours of black, red, blue, and purple. This ends up displaying visible pixels in this timespan. In order to negate these pixels, I would need to set better quality settings for it like lower crf, etc. Otherwise, Trim(0, 100) ++ Trim(200, 400) ++ Trim(500, 550) would all be encoded in the same crf the whole way through x265. The rest of the episode seems normal, but (270, 310) is terrible.

How would you go about this? If I set a lower crf, the whole episode would be affected and end up having a larger filesize, which is not that I want. In x264 it is quite possible, and people call that "zoning" - although I haven't used x264 it exists. I am fairly new to encoding, and I've been told that x265 doesn't support zoning as of yet due to it being relatively new in its development phases.

Encoding (270, 310) with a higher quality setting would be the logical thing to do, while the rest of the episode is used with standard settings, but how do I go about this? I'd like to hear if you have any thoughts on this - otherwise, that's why I'm coming up with these crazy ideas of OCing an already fully encoded episode.

Thanks again. :O

[poisondeathray]

zones work , but fewer options compared to x264. But you can use a bitrate multiplier over a range of frames, for example

http://x265.readthedocs.io/en/latest/cli.html



--zones <zone0>/<zone1>/...

Tweak the bitrate of regions of the video. Each zone takes the form:

<start frame>,<end frame>,<option> where <option> is either q=<integer> (force QP) or b=<float> (bitrate multiplier).

If zones overlap, whichever comes later in the list takes precedence. Default none

[KanarazuKatsu]

zones work , but fewer options compared to x264. But you can use a bitrate multiplier over a range of frames, for example

http://x265.readthedocs.io/en/latest/cli.html



--zones <zone0>/<zone1>/...

Tweak the bitrate of regions of the video. Each zone takes the form:

<start frame>,<end frame>,<option> where <option> is either q=<integer> (force QP) or b=<float> (bitrate multiplier).

If zones overlap, whichever comes later in the list takes precedence. Default none


Hey, thanks. I never saw this parameter setting before. I'm very unfamiliar with this. Could you please give me an example of how to use it? The document doesn't list anything other than this. If this works, it'd be great!

[poisondeathray]

Hey, thanks. I never saw this parameter setting before. I'm very unfamiliar with this. Could you please give me an example of how to use it? The document doesn't list anything other than this. If this works, it'd be great!



It's exactly what the docs say

e.g. lets say from frames 400 to 600 I want bitrate multiplier x2 , and from 900 to 1000, bitrate multiplier x4


--zones 400,600,b=2/900,1000,b=4



You just add at "/" to divide up additional frame ranges

Here is an example of a 24fps 1001 frame test; crf 18 vs. crf 18 with zones, as depicted by a bitrate graph , notice the trend is there (the frame and time ranges are correct), but the magnitude requested is not exact . eg I asked for b=4 from 900 to 1000 (4x multipler) , but it's probably closer to 2x only

(the plot scale Y-axis are not identical either, it's a bit misleading, but it's just a quick demonstration)

https://s9.postimg.org/52ii2r9m7/plot.png (https://postimages.org/)

[KanarazuKatsu]

It's exactly what the docs say

e.g. lets say from frames 400 to 600 I want bitrate multiplier x2 , and from 900 to 1000, bitrate multiplier x4


--zones 400,600,b=2/900,1000,b=4



You just add at "/" to divide up additional frame ranges

Here is an example of a 24fps 1001 frame test; crf 18 vs. crf 18 with zones, as depicted by a bitrate graph , notice the trend is there (the frame and time ranges are correct), but the magnitude requested is not exact . eg I asked for b=4 from 900 to 1000 (4x multipler) , but it's probably closer to 2x only

(the plot scale Y-axis are not identical either, it's a bit misleading, but it's just a quick demonstration)

https://s9.postimg.org/52ii2r9m7/plot.png (https://postimages.org/)

Lol, sorry to say this but, what are bitrate multipliers? I usually don't encode by entering desired bitrates. I usually just tweak crf and aq-strength as the main parameters usually - they have the largest effect.

So zones in x265 currently do not have anymore functionality other than changing bitrates? The higher the multiplier -> the more bitrates in those frame ranges -> the higher then quality encoded in those frame ranges?

I hope the x265 team works on zones more. x264 was pretty excellent at zoning. It had many functions to modify like crf levels, psy, etc.

Also, thank you for going out of your way to help me.

Thank you to everyone else who replied as well. This has been giving me a headache for so long.

[poisondeathray]

Lol, sorry to say this but, what are bitrate multipliers? I usually don't encode by entering desired bitrates. I usually just tweak crf and aq-strength as the main parameters usually - they have the largest effect.

Yes you can the same thing with crf and aq strength, the multipler just influences the quality in that section you specify. You want credits lower quality than what your normal settings give? Use a decimal multlipler like 0.7 . Or higher quality to action scene ? Use >1 . 1.0 is what your settings would normally give


So zones in x265 currently do not have anymore functionality other than changing bitrates? The higher the multiplier -> the more bitrates in those frame ranges -> the higher then quality encoded in those frame ranges?


Just the 2 listed. quantizer is not as useful, because it's less flexible (static qp means things like AQ are disabled)

Yes, higher bitrate means higher quality. If you "base" was CRF whatever, those section with b>1 would have higher quality than you normally would. Look at the graphs


I hope the x265 team works on zones more. x264 was pretty excellent at zoning. It had many functions to modify like crf levels, psy, etc.

Yes, I mentioned that earlier, x264 had more options for zones . x265 currently only has 2 (multiplier and qp).

[KanarazuKatsu]

Yes you can the same thing with crf and aq strength, the multipler just influences the quality in that section you specify. You want credits lower quality than what your normal settings give? Use a decimal multlipler like 0.7 . Or higher quality to action scene ? Use >1 . 1.0 is what your settings would normally give



Just the 2 listed. quantizer is not as useful, because it's less flexible (static qp means things like AQ are disabled)

Yes, higher bitrate means higher quality. If you "base" was CRF whatever, those section with b>1 would have higher quality than you normally would. Look at the graphs


Yes, I mentioned that earlier, x264 had more options for zones . x265 currently only has 2 (multiplier and qp).

Hmmm..., this is going to be tough. Let's say the crf was 24 and the aq-strength was 0.8 the whole way through the encode (I'm just making up number here - and obviously many more settings would be tweaked rather than just these two). If I desired a zone trim range to have a setting of around crf 19 and aq-strength of 1.5, wouldn't this be pretty difficult to even achieve with multipler alone? I wouldn't know how much times to crank the mutiplier up to even get crf to be close to 19, and even if I was able to get the quality close to crf 19, it doesn't warrant that the aq-strength with be around 1.5 after all that tuning up.

This is difficult. T_T
Do you think x265 will ever add more options to zoning? :O

Thanks for guiding me thus far. I'm learning quite a lot.

[poisondeathray]

Hmmm..., this is going to be tough. Let's say the crf was 24 and the aq-strength was 0.8 the whole way through the encode (I'm just making up number here - and obviously many more settings would be tweaked rather than just these two). If I desired a zone trim range to have a setting of around crf 19 and aq-strength of 1.5, wouldn't this be pretty difficult to even achieve with multipler alone? I wouldn't know how much times to crank the mutiplier up to even get crf to be close to 19, and even if I was able to get the quality close to crf 19, it doesn't warrant that the aq-strength with be around 1.5 after all that tuning up.


I don't know the answer. It's not that precise. Look at the graph, I asked for 4x but only got ~2x in that section . You can influence higher or lower quality and only approximately .

If you've used x264 very much, it was fairly "loose" and approximate with zones too . It's not an exact science with exact precision . e.g. if you had a crf 23 encode and entered a crf 19 zone, that zone ended up being slightly different than a full crf 19 encode for that same frame range

Run some small encode tests, evaluate the results, change zone settings, do it again - that' s how you learn how the encoder reacts to various sources and scenarios . If you do it enough you should be able to figure it out for this type of content. (Your observations might not be valid with other types of content, but for this series you should be able to figure out what you need after a few tests)

[KanarazuKatsu]

I don't know the answer. It's not that precise. Look at the graph, I asked for 4x but only got ~2x in that section . You can influence higher or lower quality and only approximately .

If you've used x264 very much, it was fairly "loose" and approximate with zones too . It's not an exact science with exact precision . e.g. if you had a crf 23 encode and entered a crf 19 zone, that zone ended up being slightly different than a full crf 19 encode for that same frame range

Run some small encode tests, evaluate the results, change zone settings, do it again - that' s how you learn how the encoder reacts to various sources and scenarios . If you do it enough you should be able to figure it out for this type of content. (Your observations might not be valid with other types of content, but for this series you should be able to figure out what you need after a few tests)

Thank you so much for being a great help. I really appreciate it. I'm going to run some more tests.

[sneaker_ger]

Hmm, okay, for example. Let's say the trim was like this:
Trim(0, 100) ++ Trim(200, 400) ++ Trim(500, 550)

This this how the episode would look like right for the episode .hvec file normally. Prologue > Episode > Preview.

The opening would be Trim(101, 199), the ending would be Trim(401, 499).

The --qpfile would have the frames: 101 I -1, and 302 I -1 Is that correct?

Then we would normally create the .xml file to link these OP, ED & Episode .mkv files.

The only problem is say, (270, 310) of the episode had complex colours of black, red, blue, and purple. This ends up displaying visible pixels in this timespan. In order to negate these pixels, I would need to set better quality settings for it like lower crf, etc. Otherwise, Trim(0, 100) ++ Trim(200, 400) ++ Trim(500, 550) would all be encoded in the same crf the whole way through x265. The rest of the episode seems normal, but (270, 310) is terrible.

How would you go about this? If I set a lower crf, the whole episode would be affected and end up having a larger filesize, which is not that I want. In x264 it is quite possible, and people call that "zoning" - although I haven't used x264 it exists. I am fairly new to encoding, and I've been told that x265 doesn't support zoning as of yet due to it being relatively new in its development phases.

Encoding (270, 310) with a higher quality setting would be the logical thing to do, while the rest of the episode is used with standard settings, but how do I go about this? I'd like to hear if you have any thoughts on this - otherwise, that's why I'm coming up with these crazy ideas of OCing an already fully encoded episode.
So you only see these problems after the encode and you only want to re-encode the problematic scenes to save time? That is indeed difficult because the trimming gets complex.
Basically what you have to do is to cut the file, e.g. using mkvtoolnix. There cut the scene away but so that the last frame you keep is a P or I frame. And the first frame you keep is an IDR frame. To make this easier you should always encode with --no-open-gop. (Mkvtoolnix will only cut at I frames so that should usually work with x265 --no-open-gop.)
Of course this is very complex, tedious, error-prone if you do it by hand. The zones solution is easier.

[KanarazuKatsu]

So you only see these problems after the encode and you only want to re-encode the problematic scenes to save time? That is indeed difficult because the trimming gets complex.
Basically what you have to do is to cut the file, e.g. using mkvtoolnix. There cut the scene away but so that the last frame you keep is a P or I frame. And the first frame you keep is an IDR frame. To make this easier you should always encode with --no-open-gop. (Mkvtoolnix will only cut at I frames so that should usually work with x265 --no-open-gop.)
Of course this is very complex, tedious, error-prone if you do it by hand. The zones solution is easier.

Yes, after quality checking the encoded episode, I see that some scenes are not as good as expected. That's why for some scenes, I want to encode at better settings while keeping the other frames/scenes at regular settings - this would only increase file size at a minimum only for that specific scene needed to be encoded better.

Yup, I know it will most likely be more error-prone doing this manually by hand. :O

Zoning would be less of a hassle. Wondering why the x265 hasn't updated more zoning features. It's so handy.

[KanarazuKatsu]

I don't know the answer. It's not that precise. Look at the graph, I asked for 4x but only got ~2x in that section . You can influence higher or lower quality and only approximately .

If you've used x264 very much, it was fairly "loose" and approximate with zones too . It's not an exact science with exact precision . e.g. if you had a crf 23 encode and entered a crf 19 zone, that zone ended up being slightly different than a full crf 19 encode for that same frame range

Run some small encode tests, evaluate the results, change zone settings, do it again - that' s how you learn how the encoder reacts to various sources and scenarios . If you do it enough you should be able to figure it out for this type of content. (Your observations might not be valid with other types of content, but for this series you should be able to figure out what you need after a few tests)

I tried entering the zone command in cli for x265, but it says x265 [error]: invalid argument: zones = 2 as an example. I put --zones 2, 5, b=7 as the parameters. Could you please take a look into this?

Also, for the selected frames, do the frames inputted into --zones command fall under the frames after the .avs script trimming, or will the frames being zones correspond to the source's total frame count time-line?

[poisondeathray]

I tried entering the zone command in cli for x265, but it says x265 [error]: invalid argument: zones = 2 as an example. I put --zones 2, 5, b=7 as the parameters. Could you please take a look into this?


Post your command line, the log file, and/or console box output


Also, for the selected frames, do the frames inputted into --zones command fall under the frames after the .avs script trimming, or will the frames being zones correspond to the source's total frame count time-line?

Yes.

x265 only "sees" whatever is the direct input

If you use avs as input and made some edits, the new timeline with all the edits and new framecount is all x265 can "see". It cannot tell what occurred before your script or what the original source was before the avs

[KanarazuKatsu]

Post your command line, the log file, and/or console box output



Yes.

x265 only "sees" whatever is the direct input

If you use avs as input and made some edits, the new timeline with all the edits and new framecount is all x265 can "see". It cannot tell what occurred before your script or what the original source was before the avs

I just placed this basic .bat file.

[poisondeathray]

Don't use spaces


--zones 2,5,b=7

[KanarazuKatsu]

Don't use spaces


--zones 2,5,b=7


Hey, thanks! I'm going to do some testing. If anything interesting happens, I'll write down some results.

[KanarazuKatsu]

@poisondeathray

Hey, I did some testing and it seems to be working relatively well. One thing I'm wondering is if this command argument has anything to do with the current settings I had already. I know it affects the magnitude bit-rate multiplier by changing the 'b' values, but does it multiply what we had off with the settings we've applied to the rest of the non-zoned sections?

Thanks!

[poisondeathray]

One thing I'm wondering is if this command argument has anything to do with the current settings I had already. I know it affects the magnitude bit-rate multiplier by changing the 'b' values, but does it multiply what we had off with the settings we've applied to the rest of the non-zoned sections?


Yes, it starts with your current settings

But I don't know if I understand entirely what you're asking ....

It takes your baseline settings (the current settings in your commandline) and just modifies the zone area, higher or lower quality if b>1 or b<1 . All the other settings are the same in that zone as if you didn't use the zone (same as the areas outside the zone)

e.g. If you used CRF23 with 5 references frames, your encode still uses CRF23 with 5 reference frames , but the zone area gets modified by that multiplier . Effectively the mb's within that zone will be have lower quantizers (or higher if b<1)

[KanarazuKatsu]

Yes, it starts with your current settings

But I don't know if I understand entirely what you're asking ....

It takes your baseline settings (the current settings in your commandline) and just modifies the zone area, higher or lower quality if b>1 or b<1 . All the other settings are the same in that zone as if you didn't use the zone (same as the areas outside the zone)

e.g. If you used CRF23 with 5 references frames, your encode still uses CRF23 with 5 reference frames , but the zone area gets modified by that multiplier . Effectively the mb's within that zone will be have lower quantizers (or higher if b<1)

Wait, if we apply zones with bitrate multiplier, b, it will have a lower quantizers? What are quantizers? I'm sorry if I am completely clueless with this setting.

Thanks for the continuing help. The zone tip really helped a lot.

[poisondeathray]

Wait, if we apply zones with bitrate multiplier, b, it will have a lower quantizers? What are quantizers? I'm sorry if I am completely clueless with this setting.


You don't adjust it directly, it's the result of applying zones with a "b" multiplier

Think of it as a quality level . Quantization is a form of lossy compression . The value and scale is arbitrarily set for each encoder (it might go from zero to 61 for encoder A, but zero to 100 for encoder B), but it's an inversely proportional relationship - higher values indicate more quality loss. When you use --crf 23 , that means average quantizer fluctuates around that level. --crf 19 yields higher quality, larger filesizes than --crf 23, right? That CRF number is an average quantizer, the values actually adjust around that value. Conversely if you use --qp 23 that's a fixed quantizer value

Each frame is divided up into tiny blocks, called macroblocks. They quantizers actually refer to the macroblocks

When you use b>1 for zones , the macroblock quantizers will be smaller than if you had not used zones. Thus larger filesizes. If you use b<1 for zones, it's the opposite, the mb's will have larger quantization, larger quantizer values and the filesize will be smaller, and yield lower quality

[KanarazuKatsu]

You don't adjust it directly, it's the result of applying zones with a "b" multiplier

Think of it as a quality level . Quantization is a form of lossy compression . The value and scale is arbitrarily set for each encoder (it might go from zero to 61 for encoder A, but zero to 100 for encoder B), but it's an inversely proportional relationship - higher values indicate more quality loss. When you use --crf 23 , that means average quantizer fluctuates around that level. --crf 19 yields higher quality, larger filesizes than --crf 23, right? That CRF number is an average quantizer, the values actually adjust around that value. Conversely if you use --qp 23 that's a fixed quantizer value

Each frame is divided up into tiny blocks, called macroblocks. They quantizers actually refer to the macroblocks

When you use b>1 for zones , the macroblock quantizers will be smaller than if you had not used zones. Thus larger filesizes. If you use b<1 for zones, it's the opposite, the mb's will have larger quantization, larger quantizer values and the filesize will be smaller, and yield lower quality

Wow, thanks for the explanation. This makes really good sense.

Also, I did some testing and whenever I try adding more than 5 zones, it crashes when I load the .bat. Do you suppose you have a fix for this?

I've tried it on different sources, and as well as different stable version releases, and it still crashes on me when I add more than 5 zones.

[poisondeathray]

Also, I did some testing and whenever I try adding more than 5 zones, it crashes when I load the .bat. Do you suppose you have a fix for this?

I've tried it on different sources, and as well as different stable version releases, and it still crashes on me when I add more than 5 zones.

What kind of "crash" ? Any error message ?


Works for me, I tried 7 zones

Try snowfag version
https://builds.x265.eu/

If it still doesn't work, post your commandline / log file / blah blah

[KanarazuKatsu]

What kind of "crash" ? Any error message ?


Works for me, I tried 7 zones

Try snowfag version
https://builds.x265.eu/

If it still doesn't work, post your commandline / log file / blah blah

Hey Poison, thanks for the reply as always. It wasn't an error on commandline, but it was more like an OS message crash displayed. No clue why adding over 5 different zones would warrant a crash.

Also, thanks. I've seen that build before, and did a scan way back. Some of the releases has a report of Win32.Trojan.WisdomEyes.16070401 Just worried.

Thanks for the help as always.