Random video degradation in different encoding options

[gelo333]

If defects randomly appear only when Finesharp is changed, then what could be the reason? I don't know.

Test 1 thing at a time and examine the result. Don't add other variables like lossy compression or scaling the result if you're examining the effect of a specific filter.

It seems to me that the video does not work so linearly, and the filters react to each other as a result during encoding.

[poisondeathray]

If defects randomly appear only when Finesharp is changed, then what could be the reason? I don't know.

If you ensure that you did this

I QP=0 simply placed P-frames everywhere. But there is no unpredictability, the changes have become logical, yes.

And didn't confuse the results with lossy compression , scaling or a dozen other factors - if you do that - then you can be sure the problem is due to the finesharp settings.

Recall that sometimes a P frame was placed, or B frame when you used lossy temporal compression . It was different each time. Not necessarily the same assignment when you changed a filter setting. Some frames had 10 or 100x the bitrate allocation. Recall that can make a difference.

So those other factors could be the reason - ie. the same mistakes you made before. Don't waste developer's time with errors in analysis

[gelo333]

Recall that sometimes a P frame was placed, or B frame when you used lossy temporal compression . It was different each time. Not necessarily the same assignment when you changed a filter setting. Some frames had 10 or 100x the bitrate allocation. Recall that can make a difference.

This is theory without practice. Why do I need this knowledge? I make the simplest settings for filters and codec, and just change the sharpness I need. But here strange defects arise.

[poisondeathray]

If defects randomly appear only when Finesharp is changed, then what could be the reason? I don't know.

Test 1 thing at a time and examine the result. Don't add other variables like lossy compression or scaling the result if you're examining the effect of a specific filter.

It seems to me that the video does not work so linearly, and the filters react to each other as a result during encoding.

Yes, filters react to each other . But you to examine the effect of 1 filter, you need to test the direct input (after KNLMeans in your script), and the direct output, without other extraneous factors . You don't necessarily have to do an encode, you can preview scripts in avspmod for example

Video is decoded to uncompressed frames before filters are applied, so video is linear in that sense

However, filters can be spatial (single frame only) or temporal (take into account multiple frames) . Finesharp (or it's mods / derivatives) is a spatial only filter . But KNLMeans with d=1 means a window of 3 total frames - so it's temporal with those settings

[poisondeathray]

Recall that sometimes a P frame was placed, or B frame when you used lossy temporal compression . It was different each time. Not necessarily the same assignment when you changed a filter setting. Some frames had 10 or 100x the bitrate allocation. Recall that can make a difference.

This is theory without practice. Why do I need this knowledge? I make the simplest settings for filters and codec, and just change the sharpness I need. But here strange defects arise.

You need this knowledge. Look at the 1st post. Please don't make those mistakes and waste everyone's time

I'm not questioning the result - it's probably correct in that 2nd example. Those changed finesharp setting improve the blocky chin . But "probably" isn't 100% for certain

eg. Can you be certain that a low bitrate frame wasn't placed that obscures artifacts in one encode ? Or perhaps higher bitrate frame that preserves blocky edges in another. Yes - if you examine it properly. No - if you do not.

Just be aware of all the other factors that could possibly be contaminating the result - that's the point . You might come to the wrong conclusions like you did before.

[gelo333]

These defects are not visible in AvsPmod. The defects appear after encoding. The QP level does not affect this. What should I do in the end? It is impossible to check every video file for these defects.

[poisondeathray]

These defects are not visible in AvsPmod. The defects appear after encoding. The QP level does not affect this.

--qp 0 should give you essentially the same result as avspmod preview.

Avspmod preview is a RGB lossless preview, but if you view a --qp 0 encoded file with the same script, and use the same RGB conversion for preview display purposes it will give 100% bit identical same results. PSNR infinity when compared to each other

ie. If there are "no defects visible" in avspmod preview of that script before encoding , there should be the same "no defects visible" with --qp 0 after encoding

What should I do in the end? It is impossible to check every video file for these defects.

If you're referring to the chin artifacts, finesharp (or finesharp derivatives) enhance those types of artifacts, and many types of other artifacts. It's not suitable for all types of sources, and the filter description warns you of that

Don't sharpen , or at least no so much, would be my advice - especially if you're trying to reduce bitrate

[gelo333]

Take a look at my Finesharp settings again:

FineSharp(mode=1, sstr=2.2, cstr=0.2, xstr=0, lstr=1.8, pstr=7, ldmp=0.1)
FineSharp(mode=1, sstr=1.9, cstr=0.1, xstr=0, lstr=1.2, pstr=6, ldmp=0.1)

What is fatal about their difference, that in one case defects appear, and in the other case the video is even better than without compression?

[poisondeathray]

Take a look at my Finesharp settings again:

FineSharp(mode=1, sstr=2.2, cstr=0.2, xstr=0, lstr=1.8, pstr=7, ldmp=0.1)
FineSharp(mode=1, sstr=1.9, cstr=0.1, xstr=0, lstr=1.2, pstr=6, ldmp=0.1)

What is fatal about their difference, that in one case defects appear, and in the other case the video is even better than without compression?

You tell me. If you've removed all the other variables, it has to be one of the settings

The most obvious one should be sstr - stronger sharpnening should result stronger artifacts. Maybe it was enough beyond a certain threshold on that frame

You can compare different settings with tabs in avspmod. Because each frame is aligned it's very easy to see differences. You can scrub to different frames, and all versions are aligned. Number keys swap versions

[gelo333]

The most obvious one should be sstr - stronger sharpnening should result stronger artifacts.

That's not how Finesharp works. The main settings are the nonlinear stabilizers "lstr" and "pstr".

However, I increased the "sstr" settings from 2.2 to 2.3. One defect disappeared, the other became smaller. I increased the setting to 2.7 and both defects almost disappeared.

I can attach screenshots. Should I make the original size into PNG or enlarge JPG as before?

[gelo333]

Don't sharpen , or at least no so much, would be my advice - especially if you're trying to reduce bitrate

This is probably true for all sharpeners.

Don't waste developer's time with errors in analysis

I don’t know why I’m asking about Finesharp in the Dogway thread, he’s not the developer of Finesharp. This is probably incorrect. Dogway made a mod called FinesharpPlus that works differently.

[poisondeathray]

The most obvious one should be sstr - stronger sharpnening should result stronger artifacts.

That's not how Finesharp works. The main settings are the nonlinear stabilizers "lstr" and "pstr".

However, I increased the "sstr" settings from 2.2 to 2.3. One defect disappeared, the other became smaller. I increased the setting to 2.7 and both defects almost disappeared.

I can attach screenshots. Should I make the original size into PNG or enlarge JPG as before?

sstr is the strength . Increasing the sharpening strength increases the sharpening effect (and artifacts)

Why don't you upload the source ?

[gelo333]

sstr is the strength . Increasing the sharpening strength increases the sharpening effect (and artifacts)

No, artifacts, on the contrary, disappear. And this has nothing to do with sharpness. These are random defects that appear on their own and disappear on their own, according to some strange logic of their own.

[gelo333]

This happens on different files. But now I have uploaded one of them.
https://dropmefiles.com/2ELhn

[poisondeathray]

sstr is the strength . Increasing the sharpening strength increases the sharpening effect (and artifacts)

No, artifacts, on the contrary, disappear. And this has nothing to do with sharpness. These are random defects that appear on their own and disappear on their own, according to some strange logic of their own.

Not for me. Nor can I reproduce your results for #2 - I see little difference in the output between those finesharp settings between #1 and #2 , the chin (and other) artifacts are present in both are similar in degree. Same script , same prefetch values. I think "auto" is Nvidia for KNLMeansCL for me (shouldn't make a difference)

When I increase sstr, with all the other settings the same (Remember, 1 variable at a time), the artifacts get worse (all the artifacts) as expected

What version of finesharp are you using?


If you examine the output of knlmeans (eg. comment out finesharp in avspmod, preview), you will see block edge artifacts on the chin already present. Finesharp enhances those (and other) artifacts. If you use just about any sharpener instead of finesharp, those artifacts still get predictably worse with increasing sharpening strength as well

[gelo333]

I'm using mod 2020.04.12 HBD Finesharp.

Are you encoding or just previewing in AvsPmod? When encoding with compression, the picture turns out different. There is no point in doing just a preview.

[poisondeathray]

When encoding with compression, the picture turns out different.

Again , if you use --qp 0, the preview is the same

There is no point in doing just a preview

Of course it's important to preview -

If you want to examine the effect of the Finesharp filter... you examine finesharp itself - not other factors, not other filters, not lossy artifacts . When you make a claim that "xyz" filter does this, or does that. You examine the thing in question , not something else.

You have to preview if you want to learn how filters and their settings work - because that's the data you are sending to the encoder.

So obviously, and logically, increasing sharpness strength increases the sharpness (and enhances artifacts as well) - that's how sharpeners work.

And then you have to apply various lossy encoding settings and preform tests if you want to understand how lossy encoding settings affect that input. If you don't even look at the input (the end effect of the script), you're not going to have a very good understanding of how lossy encoding settings affect the final lossy encode, because you don't even look at what you're starting with

Since the defect is already present before finesharp, and enhanced after finesharp, it's obviously going to be present in the encode with decent quality settings. The higher the quality settings, the higher bitrate, the better the preservation of those artifacts - because that's what you're sending to the encoder

If I add --qp 26 lossy encoding, both #1 and #2 cases smooth the chin and reduce other details . Both are assigned B frames for me on that frame. So #2 and #3 are similar to your screenshot, but #1 is different for me, it's less blocky than yours

These defects are not visible in AvsPmod. The defects appear after encoding.

Defects such as the chin problem are already present in avspmod preview at the output from KNLMeansCL, and then enhanced by finesharp. Some defects are reduced after lossy encoding if you use low quality, low bitrate settings such as some of the sharp edges, including the chin. But the lower the quality encoding settings - the other defects are introduced by lossy encoding.

The QP level does not affect this.

Changing QP definitely affects this

[gelo333]

Thank you for answering. But to be honest, I didn’t get a practical solution out of the conversation. It sounds like, in 99% of cases there are no defects, so let's leave it to chance, let the software work as it works.

[poisondeathray]

it sounds like, in 99% of cases there are no defects, so let's leave it to chance, let the software work as it works.

You must be referring to the chin "defect" only - because there are defects in basically every frame - but it's not a great source to begin with

The smooth chin is technically the encoding defect. It's an encoding artifact in your case - the bitrate and encoding settings are too poor to preserve the the blocky chin in the input (the script output) . You're relying on encoding artifacts to cover up an input problem instead of addressing the underlying problem in the script

Other strategies for lower bitrate encoding are to apply the sharpening filters on playback instead

[poisondeathray]

Another common practice - typically for lower bitrate ranges, people would increase inloop deblocking in the encoder settings for x264 . Something like --deblock 2:2 or 3:3


Also, did you consider HEVC , AV1 instead ? They excel at lower bitrates . Personally I wouldn't use x264 for lower bitrate scenarios, it's definitely not as good in 2023

SVT-AV1 is more mature and usable now, faster than before, but still very slow compared to x264 .

But GPU variants like NVEnc AV1 are fast and an option too if you have a compatible card

[gelo333]

But GPU variants like NVEnc AV1 are fast and an option too if you have a compatible card

I have an AMD video card. There is a VCE codec for it. But I abandoned it, it is not the best option for lowering the bitrate and reducing the file size. To prevent the picture from falling apart, you have to increase the bitrate.

Also, did you consider HEVC , AV1 instead ? They excel at lower bitrates . Personally I wouldn't use x264 for lower bitrate scenarios, it's definitely not as good in 2023

I'm already looking towards x265. It is preset faster, 2 times slower than x264 preset medium. I don't know how else to reduce encoding time.

[gelo333]

The smooth chin is technically the encoding defect.

I don't think any streaks from the original should remain after applying KNLmeans. And in a good version, there are still small stripes.

You're relying on encoding artifacts to cover up an input problem instead of addressing the underlying problem in the script

And most importantly, in most cases there are no stripes. You have to try really hard to create them on purpose.

[gelo333]

The smooth chin is technically the encoding defect.

If you look to the right of the chin, at the neck near the collar, you will see vertical stripes. They are almost invisible on the original.

Look at the wrist below the thumb. You will see vertical stripes. They are almost invisible on the original.

[poisondeathray]

The smooth chin is technically the encoding defect.

I don't think any streaks from the original should remain after applying KNLmeans. And in a good version, there are still small stripes.

"streaks" - if if you're referring the artifacts around the chin, yes they partially remain after those KNLMeansCL settings - and are enhanced by finesharp (or you can use any sharpener). If you increase sharpness (any sharpener) you can see the remaining artifacts better . Or if you used some other denoisers or perhaps different settings, you can see the artifacts disappear even with finesharp.

There are other more severe /annoying artifacts in the source not filtered out by those KNLMeansCL settings . eg. Look at 3737-3738 cheek line artifact. In the source it's a P->I (not a great quality source).

You're relying on encoding artifacts to cover up an input problem instead of addressing the underlying problem in the script

В любом случае, значит возникает непоследовательная случайность.

"В любом случае, значит возникает непоследовательная случайность"
google translate => "In any case, it means that there is an inconsistent randomness"

Yes, and there are some inconsistencies in the source to begin with

And yes, after lossy encoding, you will get even more inconsistencies - that was already discussed. It's the nature of lossy encoding. But no added "randomness" with --qp 0 . Less "random" behaviour with adjusted IPB ratios. Less "random" behaviour with higher bitrates. More "random" behaviour with lower bitrates

And most importantly, in most cases there are no stripes. You have to try really hard to create them on purpose.

Most people would not trying to create them, but rather try to get rid of them using something predictable like a filter. They exist in the source, and are enhanced by finesharp - you actually make them worse on purpose from using finesharp. Not really "created" because they were already there

The smooth chin is technically the encoding defect.

If you look to the right of the chin, at the neck near the collar, you will see vertical stripes. They are almost invisible on the original.

Look at the wrist below the thumb. You will see vertical stripes. They are almost invisible on the original.

Yes, but examine the input to the encoder. The script output. The artifacts around the chin are very pronounced and enhanced, even more than the original .

The encoder doesn't use the original video, it uses the script output.

A PSNR infinity encode of that script shows very pronounced and enhanced chin artifacts . It would preserve everything, all those blocky defects. That's why the smoother chin is actually the encoding defect - it's a larger deviation from the input (the script) . If it doesn't make sense or I can make a demonstration

But it doesn't matter, as long as you're happy with the results.

[gelo333]

Can it help me to abandon CQP and CRF, and encode with a manual bitrate value?

[poisondeathray]

Can it help me to abandon CQP and CRF, and encode with a manual bitrate value?

What is "it" ? I don't understand the question

You can use 1pass VBR, 2pass VBR, "n" multipass VBR, or "CBR" variants to specify a bitrate target - in addition to CRF and QP rate control methods. Each has pros/cons . You can also restrict bitrate and peaks with VBV buffer and maxrate settings for any of the rate control methods. e.g you can combine QP or CRF with --vbv-maxrate --vbv-bufsize to high a bitrate target. But VBV restrictions always have potential to reduce quality, but you might use them if target was a specific device for example.

[gelo333]

I meant, manually specifying the bitrate can help avoid those artifacts? Despite the fact that I would not want to calculate the bitrate for each file. I need to specify one setting for many videos from the same source type, for example from one phone. I know it's not professional, but "low-medium" quality is enough. The main thing is that there are no conspicuous defects.

[poisondeathray]

I meant, manually specifying the bitrate can help avoid those artifacts? Despite the fact that I would not want to calculate the bitrate for each file. I need to specify one setting for many videos from the same source type, for example from one phone. I know it's not professional, but "low-medium" quality is enough. The main thing is that there are no conspicuous defects.

In general , no - because you're sending artifacts to begin with in the script - that's the main issue - some artifacts remain that were not properly dealt with in the filters. That chin and cheek (and others) were sent already with artifacts to the encoder. It you send artifacts - it doesn't matter what rate control method or bitrate you use. In general, high bitrates are technically better - but it can make some artifacts "worse" because they actually preserve the artifacts that were sent. That's what is happening in picture #3 with qp 0 - that is essentially a script preview. Your script is sending artifacts and you're hoping the encoder deals with them appropriately. It was just "luck" that the chin got smoothed using lower bitrate #2. It could have easily gone the other way, and produced other more severe artifacts, that happens all the time in low bitrate encoding.

Many artifacts are made more severe by sharpening, some would not have been a problem if you didn't sharpen. You can check each step , each filter preview - that's why it's important to understand what each filter , each step, is actually doing and to adjust the settings accordingly.

It's a more predictable strategy to filter out the problems in the source to begin with, than to blindly "hope" that the artifacts are taken care of by the encoder. You have more control over the filtering stage to deal with artifacts, than over how the encoder deals with artifacts. But if you don't even look at the preview - you will not know if there are artifacts remaining that you didn't address. Or conversely you will not know you use too strong denoising and removed details that didn't need to be removed. But most people will agree it's better to use the correct filters for that source, instead of sending problems to the encoder and "hope" encoder deals with them correctly.

And of course low bitrate encoding adds additional problems, but that's the encoding side of the equation, another big discussion. The artifacts discussed here such as the chin and the cheek were sent with artifacts to the encoder.

Maybe you don't have time to customize script for different sources. Maybe you're not that picky. You have to decide on what is "conspicuous" or not. You decide on what tradeoffs you want to make

[gelo333]

Perhaps I found the reason for the illogical behavior of sharpness. These are SetFilterMTMode("DEFAULT_MT_MODE", 2) and Prefetch(6). Without their use, randomness seems to have disappeared. Now we have to spend a lot of time to prove or disprove this. But still, I would like to know in advance, is this hypothetically possible?

Before that, I noticed that decreasing -keyint_min from 5 to 1 improves perception, since the picture does not freeze when changing frames.

[poisondeathray]

Perhaps I found the reason for the illogical behavior of sharpness.

Not sure which illogical behaviour you're referring to, but the finesharp filter itself behaves logically and predicatably

Inconsistent behaviour is clearly from the lossy encoding . You already confirmed this yourself with qp 0

I set QP=0. It has gotten better, but not absolutely. Worse than the best variant, since I use noise reduction before the sharpener. And in this case, the frame types have already been rearranged. QP=0 simply placed P-frames everywhere. But there is no unpredictability, the changes have become logical, yes.

It's "worse" perceptually in some areas because it preserves the remaining artifacts that your script sent .

These are SetFilterMTMode("DEFAULT_MT_MODE", 2) and Prefetch(6).


Without their use, randomness seems to have disappeared. Now we have to spend a lot of time to prove or disprove this.

This has no change for me. Same output as before maybe slightly slower to process. Bit identical. Same filesize . That's what you would expect for avs+ multithreading - it shouldn't change the script output .

(Some exceptions to avs+ multithreading being bit identical might be non linear seeking (you jump all over the place on the timeline in a preview) with some filters like srestore, or non frame accurate source filters can sometimes mix up frames with seeking . "normal" linear encoding is almost never a problem. It's only with non linear editing/ random seeking.)

But still, I would like to know in advance, is this hypothetically possible?

Maybe something unstable in your setup? Bad/old source filter ? Recall I got slightly different results that you, despite using the same script, same prefetch values . There should be no different with script multithread

If I add --qp 26 lossy encoding, both #1 and #2 cases smooth the chin and reduce other details . Both are assigned B frames for me on that frame. So #2 and #3 are similar to your screenshot, but #1 is different for me, it's less blocky than yours

If I disable all the multithreading (including prefecth in the resize call) and encode again with --qp 26 I get the same results as I did before.

Note that x264 auto threading is 1.5 * logical processors. You can set --threads to 1 to disable encoding threading. In contrast to script multithreading - Encoder threading always slightly decrease quality , but the effect is marginal until you get to very high numbers.