meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)

[Vitreous]

Boost is comparable to LossLess = 2

Yes. Lossless=2 will be renamed Boost in future QuickTGMC because Lossless=2 isn't actually lossless - it is smoothed by the final temporal step (see below)

How to completely disable the setting "Smoothing"?

Smoothing is just a nice name for the setting TR2. Switch if off by disabling "Auto" and setting it to 0. It is not usually a good idea to switch it off unless you have a perfect source or are going for a speed encode. It's especially important if you use source-match or boost, because both of those will honor noise from the source. It's a fairly light smooth and has enhancing properties too.

PS: For the parameter "Noise Processing" Remove (-) / Retain (+)", would it be possible to increase by a factor of +1 two and not as at present.

Do you mean: by a factor of '0.1' rather than '0.2'?

 

[no__One]

Absolutely, by a factor of '0.1' rather than '0.2'.

PS: I really need a good sleep cure ...:snooze:
Thank you for your quick and clear answers.
Regards.

 

[hofct]

Hi Vitreous,

I have the x264 encoding error using 1.00beta3, such error seems randomly happened in my machine.
View attachment 443335

Source file is a .mpg directly trimmed from an [IV] DVD.

I remembered the settings are:
Preset: Slower
Source Match: 2
Boost: Enabled
Video Profile: 60fps Default [Detail]

Pls find the log file attached.
View attachment 443119

 

[Vitreous]

You unchecked "Add pre-rendering job" on the "Encoder Config" tab. That is OK for a good machine on default settings. But if you run slower settings you need to check "Add pre-rendering job" or you will run out of memory (AviSynth is a 32-bit app, so it can only use 2Gb - there is a unofficial 64-bit version but it is no longer being developed). Same applies to HD material.

 

[no__One]

Hi Mr. Vitreous,

Some info on beta3:

I continue my intensive testing and I am pleasantly surprised how easily I managed to get almost the quality of meguIVit_0.2.1 (compared to dozens and dozens of tests I have done on previous versions).

- I finally get multiple encodings from the same source strictly identical, thing I've ever had with the previous versions. k:

- Performance level: I get a little near the same FPS. k:

- I confirm that "source-match"without "Smoothing" is really undrinkable ...:dizzy:

One question: what is the default value of the parameter "Smoothing" when I left on "Auto "? uzzled:


* What I miss most is being able to save my settings and ...

I know this is really just the cosmetic but I do not have [HQ] Logo when I push the settings in x264 on placebo.

I know, I know, I really dwell on the details! :narcissist::joker:

I am unable to get an idea of the immense work that has asked you to come to such a result. But I must say that was simply magnificent.
To qualify for such a Degree of quality, just in a few clicks ... it is simply superb.
Again thank you Mr. Vitreous.:bow-pray:
Regards.

 

[Vitreous]

...almost the quality of meguIVit_0.2.1

You should be able to get the same quality, certainly at your extreme settings. Why is it only almost the same quality?

Performance level: I get a little near the same FPS.

Most standard settings should be faster (I can run the defaults, "Slow", with no pre-rendering direct to 60fps x264, at well over 40fps for 480p). The extreme settings might be slower, speed is not a consideration for them.

What is the default value of the parameter "Smoothing" when I left on "Auto "?

Depends on preset: 0 for fast presets, 1 for standard presets, 2 for "Very Slow", 3 for "Placebo". The idea is that "Very Slow" and "Placebo" take their detail down the noise bypass route so they smooth the main image more. However, temporal smoothing can lose detail in the background near moving edges so I am likely to tweak "Placebo" and "Very Slow" at some point. In particular you may wish to use Smoothing=2 for Placebo.

What I miss most is being able to save my settings

I am working on that now, although I have been distracted (I've been looking again at Super-Resolution)

I know this is really just the cosmetic but I do not have [HQ] Lego when I push the settings in x264 on placebo

I don't want to analyze x264 settings to determine HQ, I might just show "?" if I see an unrecognized x264 profile.

 

[hofct]

You unchecked "Add pre-rendering job" on the "Encoder Config" tab. That is OK for a good machine on default settings. ...

Dear Vitreous,

Is seems you are right. The job has ended with error and the last last memory allocated was 1.5GB..... (for a video with 30minutes)
My system is running 32-bit Windows XP with only 2GB physical memory.

Maybe I should upgrade it to 4GB or more.....

Thanks again.

 

[no__One]

I do not think this will solve your problem more. (Unfortunately, I did the test and it was a total fiasco) ... This must be due to the limit of 32 bit system and up to 2 GB per application. The best would be, as stated by Mr. Vitreous, changing the setting "Cache Memory" more finely for your PC.

Hope this helps.
Regards.

 

[Vitreous]

My system is running 32-bit Windows XP with only 2GB physical memory

That's not a lot for the settings you are using. You must enable "Add pre-rendering job". You could also reduce the thread count for that memory:
- Go to the One-Click "Custom Processing" tab
- Uncheck "Auto" on "Main Threads" and "Sub-Threads"
- Set "Sub-Threads" to 1
- Experiment with "Main Threads" until you get a memory usage that works on your machine. Start with the number of cores on your CPU
- You could also experiment with the "Cache Memory" setting, but it can be hard to predict what value to use there. Try 400, 300 or 600?

Do test rips with the trim settings, 2000 frames should be enough to see how memory is being used. Reducing number of threads may slow down encoding.

 

[hofct]

That's not a lot for the settings you are using. You must enable "Add pre-rendering job". You could also .....

I never touch the thread count settings as I though the "auto" is fine for my system.
I' ll spend some time to test again.

Thx

 

[no__One]

Hello Mr Vitreous,

I continued my tests and followed your advices.
I think we get such a quality that is only a matter of taste.

I am attaching the file test.7z (renamed test.7z.zip) below, a test:

PW:

Strength_&_cour@ge_without_vio1enc£

- Stock 0.3 A has been encoded with meguIVit_0.2.1.
- B1 has been encoded with meguIVit_beta3.

I used in these 2 cases, the same parameters for:
- "Source-Match".
- "Boost' (=Lossless = 2) enabled.
- "Smoothing".
- "Retain".
- "Noise-Preset".
Profil 'Placebo' (of course) No other parameters have been touched / modified in meguIVit_0.2.1/meguIVit_beta3.

and yet I can not get the same result.
So it is obvious that we can debate which one is most appropriate / best.

I made ​​tests with differents values ​​for ​​"Smoothing" (0,1,2,3). But the result remains different from meguIVit_0.2.1.
I wonder if the differences I see do not come with the setup of x264.
I also enclose two screenshots of meguIVit_0.2.1 / meguIVit_beta3.
(Left: x264-0.2.1 / Right: x264-Beta3)
With your help, I would be able to perhaps solve this mystery and with a bit of luck find a solution.

Regards.

 

[Vitreous]

and yet I can not get the same result.

You will never get the same result. MeguIVit 1.0b3 uses a recent x264 (r1924), whereas version 0.2.1 uses r1745. Some default "Quantizer" settings have changed due to this, I have not checked their purpose. I have assumed that the CRF (the "Quality" setting) doesn't need to change due to an x264 version change (that would be very annoying).

You have changed the preset in the meguIVit 0.2.1 picture. There is no "[Vit] 60fps 480p Placebo" x264 setting in 0.2.1. You must have added that setting after sliding the preset slider? So you should do the same in the new MeguIVit 1.0b3, slide the preset to Placebo for a fairer comparison. That explains many of the x264 differences you have shown.

Apart from Quantizer noted above, the x264 settings that are changed to meguIVit 1.0b3:
- Deblocking settings for default and [Detail] settings are reduced to -1, which is the x264 default for "film" tuning. This will slightly increase the retention of fine detail in fairly plain textured areas (e.g. smooth skin, plain colored clothing or walls). It does so by allocating slightly less bitrate to high detail areas. This seems to be a sensible choice for IV videos [skin!]. The [Smooth] preset leaves this setting unchanged, making plain areas tend to be more... smoothed...
- More contentious: the AQ setting is 1.3 for [Detail], 1.0 for default, and 0.8 for [Smooth]. This does what it says, allocating bitrate appropriately for the desired look. The default setting of 1.0 is the same as the version 0.2.1.
- Some minor changes to GOP sizes that should make seeking more consistent across different presets. This is a very small change for 480p 60fps so it will make little visual difference.

So to get very close to 0.2.1 defaults, just change the deblocking strength and threshold to 0, and remember to move the preset slider to "Placebo". But it will never be the same.

I do want to check the presets again though. Despite all I just wrote, I also detect a change in encoding look, which I assume is mainly due to x264 changes. It may be that other tweaks are needed.

 

[Vitreous]

I have assumed that the CRF (the "Quality" setting) doesn't need to change due to an x264 version change (that would be very annoying).

Annoying, but true.

My assumption was incorrect. The same CRF value may give different quality between versions of x264. So every time you update x264, you need to reconsider your settings. Not a big incentive to keep up to date then. I'll look into this for the next release.

 

[no__One]

Hi Mr. Vitreous,

You pull the rug from under my feet...:exhausted:

I have not completely finished my tests but after the first results, I agree with your conclusion. It's annoying.

I'd do an update, after having completed all my tests.

 

[no__One]

Hi Mr. Vitreous,

I just finished all my tests.

I asked myself: If the "problem" comes from "x264", then I just need to replace with the version of meguIVit_0.2.1.

I made ​​new tests and unfortunately the result is different.
- Yet I took the parameters for "x264" of meguIVit_0.2.1.
- made no changes to Placebo profil.

So the differences are not great and of course a matter of taste.

Had there been any change in "QuickTGMC" which would explain these differences ? uzzled:

I hope this info is of any use.
Regards.

 

[Vitreous]

Had there been any change in "QuickTGMC" which would explain these differences ? uzzled:

Of course there have been changes, if I wanted to keep things the same then I wouldn't keep increasing those version numbers... Between meguIVit 0.2.1 and 1.0b3 we have gone from QuickTGMC 2.51 to 3.32. That's almost a thousand lines of script difference (and some new plugins). I constantly add new features and tweak old ones. I try not to break things but I don't obsess about pixel identical output either. If I had to guess, it's probably changes in the noise processing you're seeing - that affects Placebo, and almost every pixel. Or maybe something to do with motion vectors. Or both. If it's a visual problem then show me an example. If it's just different, well that will happen between distant versions...

In any case, the next QuickTGMC (3.4) is nearly finished. It has new quality and speed settings. The quality settings improve the motion vectors, which means better clarity on moving detail - switched on by default in Placebo mode. So guess what? Those pixels are gonna change again...

 

[no__One]

Hi Mr. Vitreous,

Excellent, I love your answer.:rofl:

I misspoke. When I asked if there had been any change in "QuickTGMC" that could explain these differences. I meant QuickTGMC v3.31 to v3.32.

Without apologies, peace to the souls of all those poor kittens ... :innocence:

I'm sorry for the confusion. :bow-pray:

Regards.

 

[Vitreous]

I meant QuickTGMC v3.31 to v3.32.

Yes, the padding values sent to MVTools2 have changed. The MVTools2 version has changed in meguIVit 1.0b also. I'm currently working on a new plugin to manipulate MVTools2 vectors and I am beginning to believe that MVTools2 padding doesn't work as it should. I spotted the bug that led to its most recent update and that was to do with padding. Padding is supposed to remove artefacts at the edges, but I think it more often adds them. I get better results by setting padding to 0. You can do that by manually editing line 353 (or so) of QuickTGMC (where there is a comment about matching the MVTools default), set hpad and vpad to 0

Without apologies,
... ... ...
I'm sorry for the confusion.

Meow, mewl mewl, purrrrrr, meo...uck...eeeaaaggghhh..... :murder: ...silence

 

[lilgurlsrfun]

Vitreous, I was wondering if these stats were normal.



My machine isn't super mega fast.
Intel dual core 2.8 (E6300)
2gb ram
GFX card: EN9600GT 512 mb ddr3
OS: Windows 7 (32 bit)

I use the one-click with the 360p @60fps for a 4-5 minute clip.
But it takes quite some time (like 45-60 minutes 0.0), so I wonder if its just my slow pc, or if I am overdoing it with some settings that aren't needed to maintain a nice end result. Any suggestions on settings to at least keep the same quality of the original wmv's without upscaling too much? uzzled:

 

[Vitreous]

But it takes quite some time (like 45-60 minutes 0.0), so I wonder if its just my slow pc, or if I am overdoing it with some settings that aren't needed to maintain a nice end result.

I don't know what settings you are using, so hard to judge. However, that is a fairly weak machine compared to the more frequent rippers, so your result may be normal.

You can speed up the first pass by simply adjusting the "Preset" at the top of the "Custom Processing" tab. Only you can decide the best balance for quality/speed for your eyes/spare time, so experiment. All the presets are good down to Ultra Fast, so don't fret about it. Your machine should easily crunch through the faster settings.

Given your machine, I wouldn't enable any other settings, just tweak the Preset (and alter sharpness if you wish, that takes no time).

The second pass (x264 encoding) can also be sped up, but I wouldn't recommend it [if you must, it's on "Encoder Config">>"Video Profile:Config">>Slide the "Presets" slider]. It's much easier to see the weaknesses of the faster settings there.