Assistance with StaxRip

  • Throughout the month of April 2024, participate in the FileJoker Thread Contest OPEN TO EVERYONE!

    From 1st to 30th of April 2024, members can earn cash rewards by posting Filejoker-Exclusive threads in the Direct-Downloads subforums.

    There are $1000 in prizes, and the top prize is $450!

    For the full rules and how to enter, check out the thread
  • Akiba-Online is sponsored by FileJoker.

    FileJoker is a required filehost for all new posts and content replies in the Direct Downloads subforums.

    Failure to include FileJoker links for Direct Download posts will result in deletion of your posts or worse.

    For more information see
    this thread.

SamKook

Grand Wizard
Staff member
Super Moderator
Uploader
May 10, 2009
3,560
4,927
@SamKook I don't know about x265, but anime nerds encode in a special way without presets:
--limit-refs 2 --ctu 32 --max-tu-size 16 --hist-scenecut --no-cutree --no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 15 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --qcomp 0.72 --refine-mv 3 --analyze-src-pics --max-merge 5
--hist-scenecut --no-cutree --no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 15 --b-pyramid --weightp --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --refine-mv 3 --analyze-src-pics --max-merge 5
--no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --no-early-skip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --qcomp 0.72 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 16 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 4 --refine-mv 3 --analyze-src-pics --max-merge 5
--ctu 32 --rc-lookahead 80 --max-tu-size 16 --no-cutree --open-gop --no-strong-intra-smoothing --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 9 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 4 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 1 --refine-intra 4 --dynamic-refine --tu-inter-depth 1 --me 3 --wpp --subme 7 --crf 14.8 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --refine-mv 3 --analyze-src-pics --qcomp 0.76 --max-merge 5
Anime is very different from real footage so it makes sense they would change more options, but it's kind of pointless to not use a preset since it'll set quite a few of those options to the same thing which means your command isn't as long. I change about 8 options(excluding quality and color stuff) instead of having to specify every single one of them.
There's more than one option that repeats for all 4 of those option sets and there's likely a preset that includes those options so makes comparing them easier if you just keep the stuff that changes.

x265 has better handling of motion in bigger areas, which is cpu-intense. the benefit depends on the video having such elements. else it might end up with similar file size.
this time it looks as if we had cranked up the denoiser a bit, which is probably normal behavior for x265 at higher compression.

(my x264 examples, mostly salvage projects, have the denoiser set between 15-19, targeting file size as well.)
eventually, mpeg2 is completely incompatible in its artifacts, and recompression with mpeg4 that must not lose any detail, will end up with similar file size, given big size comes from motion and small detail like grass in the garden. a long but calm video may compress better.
It's true you'd likely get better results with a cleaner source, but most people that post x265 stuff compress their stuff way too much so I haven't seen many examples of it looking good at any resolution and I prefer a noisier picture vs a softer one unlike you so it's hard for x265 to impress me.
I do want to mess around with it more, especially now that I have a much better cpu, but I also need to figure out how to make that cpu work more since with x264 I get about 40% cpu usage and about 30% with x265 if I don't have any processing to do. I haven't looked into it much yet but I think the default is 12 threads and I've got 32 but x265 seemed to indicate it was using 32 for something so not sure about that.
 

Kevin_san

Member
Nov 24, 2015
55
14
You can use kernels with smaller compensation any time. However, a video that has good dithering in the first place will be always come back better.
Just that I didn't explore that direction more consciously.
One factor is how natural the skin appears to you, there are ways to boost different aspects.
 

Attachments

  • vlcsnap-2022-09-01-01h46m19s391.png
    vlcsnap-2022-09-01-01h46m19s391.png
    847.9 KB · Views: 124
  • vlcsnap-2022-09-01-01h46m44s325.png
    vlcsnap-2022-09-01-01h46m44s325.png
    796.3 KB · Views: 119
  • vlcsnap-2022-09-01-02h08m40s266.png
    vlcsnap-2022-09-01-02h08m40s266.png
    864.5 KB · Views: 115
  • vlcsnap-2022-09-01-02h37m09s389.png
    vlcsnap-2022-09-01-02h37m09s389.png
    868.1 KB · Views: 119
  • vlcsnap-2022-09-01-02h39m45s036.png
    vlcsnap-2022-09-01-02h39m45s036.png
    767.6 KB · Views: 123

Kevin_san

Member
Nov 24, 2015
55
14
Yeah, good! is it the Gekko mp4 upload? My file size from above frame is 1.51G (1 624 284 972) without audio, at 960x640, 30p.

The next scene is more troublesome, the encode will eat up a lot again, hard to defeat without losing file size benefit.
If some small detail in the original is a bit blurred already, the encoder tends to steal it completely. Oversharpening is the seduction to prevent this.
I post it to explain the different goal in color strategy, though at that time my settings were still a bit reddish. But watch also the white parts.
 

Attachments

  • vlcsnap-2022-09-01-13h28m15s246.png
    vlcsnap-2022-09-01-13h28m15s246.png
    496.8 KB · Views: 124
  • vlcsnap-2022-09-01-13h28m17s500.png
    vlcsnap-2022-09-01-13h28m17s500.png
    772.9 KB · Views: 119

Porni

Well-Known Member
Feb 29, 2012
346
321
Yeah, good! is it the Gekko mp4 upload? My file size from above frame is 1.51G (1 624 284 972) without audio, at 960x640, 30p.
It's my own
General
Unique ID : 1461455037013078276514884823568678998 (0x119774BE51F2F9204CF8547A29D0056)
Complete name : PCBE-11925.mkv
Format : Matroska
Format version : Version 4
File size : 851 MiB
Duration : 59 min 22 s
Overall bit rate : 2 003 kb/s
Encoded date : UTC 2020-05-28 09:56:56
Writing application : mkvmerge v46.0.0 ('No Deeper Escape') 64-bit
Writing library : libebml v1.3.10 + libmatroska v1.5.2

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings : CABAC / 9 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 59 min 22 s
Bit rate : 1 900 kb/s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.183
Stream size : 807 MiB (95%)
Default : Yes
Forced : No

Audio
ID : 2
Format : Opus
Codec ID : A_OPUS
Duration : 59 min 22 s
Bit rate : 101 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 50.000 FPS (960 SPF)
Compression mode : Lossy
Delay relative to video : 89 ms
Stream size : 42.8 MiB (5%)
Default : Yes
Forced : No
 

branbran726

Well-Known Member
Nov 5, 2021
554
706
Color correction is still above my paygrade, so here's what's perhaps a pretty basic question in a different direction. I'm fascinated by the file size benefits to essentially taking longer to encode a file. By giving more computer clock time to solving a problem, allowing the process to look more broadly at what might be better solutions, you might end up with 2%, 5%, 10% or more in file size reductions.

What are the drawbacks to that, other than the effort/time it takes to do it in the first place? As long as the end viewer has access to the same codec, are they going to have a tougher time viewing a file done at Slower or Placebo speeds vs. Fast or Medium? Or if someone wants to then re-encode the already encoded file to something else (like a free streaming video), are they going to get a worse result from a highly compressed file than they would if the file had been produced more quickly to start with?

Some of the stuff I am getting ready to post turned out to take a ~8gb ISO and only shrink it to 5gb. At that size you might as well go for the ISO. If I were to go back over that with slower processing, maybe I could get it down to 4.5gb or even 4gb... though at this point I've spent enough time uploading everything that I don't particularly care to to that... but it makes me wonder.
 

SamKook

Grand Wizard
Staff member
Super Moderator
Uploader
May 10, 2009
3,560
4,927
Staxrip probably handles using the right color for you according to the video resolution so as long as you don't do upscales/downscales, you shouldn't have to worry about it.

For the encoder itself, it's literally only the encoding time that's the drawback. Using a slower preset for x264/x265 just takes more time and produce a smaller file(if using crf) or producing a better quality video(if using fixed bitrate).

For QTGMC, the quality will be better when using a slower preset and it might even help the video to compress better so again, time is the only drawback.

That's why I always use the preset before placebo. It's better not to use placebo(unless you know what you're doing) since it often just cranks all the options to the max, even if it's a bad thing so you might not get the best quality.

The codec is the same in the end so the viewer will be able to play or not play them regardless of what you do. The only thing that does cause problems for compatibility is using 10bit color instead of 8 which helps with banding and possibly reduce the size a tiny bit more, but nowaday, most player can handle that in software, but some can't use hardware acceleration to play them.
 
Last edited:

Porni

Well-Known Member
Feb 29, 2012
346
321
What are the drawbacks to that, other than the effort/time it takes to do it in the first place? As long as the end viewer has access to the same codec, are they going to have a tougher time viewing a file done at Slower or Placebo speeds vs. Fast or Medium? Or if someone wants to then re-encode the already encoded file to something else (like a free streaming video), are they going to get a worse result from a highly compressed file than they would if the file had been produced more quickly to start with?
Playback is affected by the device, number of reframes and bframes, profile and level
For example, PlayStation 3 can't play more than 4.1 level or I used a smartphone from 2012 a couple of years ago, it couldn't hardware accelerate more than 9 reframes even for 720x480 24 fps. But with Baseline h264 video can be played back by some 17 year old handheld computer that doesn't even know anything about h264. There is also no hardware acceleration for h264 10 bit.
A streaming will definitely ruin a video.
Some of the stuff I am getting ready to post turned out to take a ~8gb ISO and only shrink it to 5gb. At that size you might as well go for the ISO. If I were to go back over that with slower processing, maybe I could get it down to 4.5gb or even 4gb... though at this point I've spent enough time uploading everything that I don't particularly care to to that... but it makes me wonder.
This may be ok, but not sure if you are doing it right, are you sure that you using "very slow" preset for QTGMC and not "medium"?
Also there are crappy dvd5s with 4 hour videos, looks bad and compresses badly.
 
Last edited:

Kevin_san

Member
Nov 24, 2015
55
14
my suggestion nonetheless can concern uploading, if someone who uploads has a clear target about who will watch it, and here comes the HQ tablet and the notebook. those who are used to 4k dolby suites watching the most recent stuff, will not watch a DVD anyway, unless it is some "cult" content. so, there are gazillions of mp4 files of lowest quality, that we can easily beat with filesizes between 1.5G and 3G depending on what was told above.
porni has absolutely fantastic efficiency in filesize.

perhaps it is possible to create a genre of DVD transcodes that has developed some very nice subtle effects, modernizing the look, reducing some noise and halo, and make watching the content palpatable on smaller devices, like bedtime stories, you know..
it only matters, what the downloaders will like or not like. I believe that there will be audience for very organic, linear processing with a softer appeal, this will not be the kids.

--------------------------------------------------------------------------
I can share another hack, coming from the original question. it is a cutting function, that does all computations.
I have no clue about the language, and I DGAF. but it works.

#read video file; some processing.. .. .. global rff=30000./1001. # we use a global in a silly way, and spend no further thought vv = last pics = cut(vv, 0,20.019, 0,20.036) + cut(vv, 0,40.072, 0,40.089) # cut out two pics for front page pics = Trim(pics,0,-2) # to make sure it works, there was trouble with buggy interpretation of the avs, after win10 update and avisynth update. not always required. #this is a series of still pics or slide show vintro2=cut(last,0,20.053, 0,40.056) + cut(last,0,00.000, 0,19.087) # we can cut out artwork, intro runs, menu runs, or cut out still pics from a moving menu #this is an intro, that we need not deinterlace, or deinterlace in a different way (only to 30fps not 60 but later frame-double; or BFF/TFF conflict) so we save it away. # here we deinterlace the whole thing # Yadif (... ...) # we want to be cheap and fast, the denoiser in the encoder will save us... #now we have to switch global rff=60000./1001. # then we can continue with the same cutting function #but we want the pics to last half a second tsl=int(2.0*rff/2.)+1 # duration of one pic n=0 /* pics = Loop(pics,tsl,n+27,n+27) pics = Loop(pics,tsl,n+26,n+26) pics = Loop(pics,tsl,n+25,n+25) pics = Loop(pics,tsl,n+24,n+24) pics = Loop(pics,tsl,n+23,n+23) pics = Loop(pics,tsl,n+22,n+22) pics = Loop(pics,tsl,n+21,n+21) pics = Loop(pics,tsl,n+20,n+20) pics = Loop(pics,tsl,n+19,n+19) pics = Loop(pics,tsl,n+18,n+18) pics = Loop(pics,tsl,n+17,n+17) pics = Loop(pics,tsl,n+16,n+16) pics = Loop(pics,tsl,n+15,n+15) pics = Loop(pics,tsl,n+14,n+14) pics = Loop(pics,tsl,n+13,n+13) pics = Loop(pics,tsl,n+12,n+12) pics = Loop(pics,tsl,n+11,n+11) pics = Loop(pics,tsl,n+10,n+10) pics = Loop(pics,tsl,n+9,n+9) pics = Loop(pics,tsl,n+8,n+8) pics = Loop(pics,tsl,n+7,n+7) pics = Loop(pics,tsl,n+6,n+6) pics = Loop(pics,tsl,n+5,n+5) pics = Loop(pics,tsl,n+4,n+4) pics = Loop(pics,tsl,n+3,n+3) pics = Loop(pics,tsl,n+2,n+2) */ pics = Loop(pics,tsl,n+1,n+1) pics = Loop(pics,tsl,n+0,n+0) # here we simply set the end-of-comment, beginning at the bottom for zero, according to the number of pics that we have. #this time we can cut out regular segments to our likening, which is what happened at the beginning of the thread. vintro=cut(last,0,00.000, 1,06.582) # and 10 more segments if needed for resizing and cutting differently vmain=cut(last,0,40.106, 80,00.000) # the end of the main video need not be exact. # at some point we have to join the stuff and add the segments. # treat vintro2 here, but we would not invest the time very often, to figure that out, just omit the segments vintro2 = Yadif(vintro2, mode=0,order=1) vintro2 = ChangeFPS(vintro2,60000,1001) last = pics + vintro +vintro2 + vmain # whatever #further processing, like convolution and chroma shifting # .... .... .... CShft(last,-0.3,-1.0) #-- let it trample into end of file #-------------------- just add the helper functions in every copy, or do an include ---- function CShft(clip In, float X, float Y) { w = In.Width() h = In.Height() Tmp = In.BlackmanResize(w, h, -X, -Y, w-X, h-Y, 5) # -- you might try different filtering functions because sometimes the color bleed becomes worse. # -- you can be diligent, scrap the shift, and figure out the exact chroma position and enter it in the conversion functions, if there are any. In = MergeChroma(In, Tmp) return In} function cut(clip In, int Mins, float secs, int Mins2, float secs2) { # parameters = clip, start_minutes, seconds.milliseconds, end_minutes, seconds.milliseconds tpos = 60.*Mins + secs te = 60.*Mins2 + secs2 Outclp=Trim(In, int(rff*tpos)+1, -int(rff*(te-tpos))-1) return Outclp} # there is a delivery issue with dgdecode, therefor if the pic to extract is within the first few frames, we change the "+1" seen above into "+0" as a place holder. it might be different every time.
 
Last edited:

SamKook

Grand Wizard
Staff member
Super Moderator
Uploader
May 10, 2009
3,560
4,927
  • Like
Reactions: Porni

SamKook

Grand Wizard
Staff member
Super Moderator
Uploader
May 10, 2009
3,560
4,927
I haven't done any grain/noise modifications to my rips thus far, mostly because I don't know what I'm doing. Adding in various noise filters seems to cut between 8% and 15% of file size, but I don't know what I'm losing to get that, and I don't have a good way to judge which results look better.

Usually when you remove grain, you end up with a blurrier picture. In moderation it can be a good thing but it's easy to make things worse. I rarely mess with that unless the grain/noise in the source is pretty bad since I like a sharp picture and most of the time I end up preferring the original over the filter result. Kevin_san is a big fan of the convolution filter for denoising and he likes the result to be fairly soft which isn't to my liking.
I've used TemporalDegrain2(grainLevel=0) on a very grainy tv show episode a few days back and it did a nice job without overdoing it. I basically just read the filter description on avisynth.nl and do trial and error to figure it out.

To compare, I use the go to... function in the navigate menu of mpchc, copy the time of the frame I want to compare(so I can pick out the exact same frame for the next test rip) and save the frame as a png(you end up with a bunch of similar picture like this for example: https://www.akiba-online.com/thread...shinoaki-felony-sentence.2093181/post-4566074). Then I open the pictures in xnview(it loads picture fast without flickering so make it easy to compare, but I'm sure many picture viewer are just as good) and use page up/down to alternate between the pictures while I examine what changed. Repeat until you're happy with the result. Then make sure it also looks good while the video is playing since there might be stuff that you can only see when there's movement.
 

Kevin_san

Member
Nov 24, 2015
55
14
Oh Aki, that's good, I am dealing with similar videos.
Allow me to be more specific about the grain issue.
Here we have RisaYoshiki_LCDV-40492 https://www.akiba-online.com/threads/assistance-with-staxrip.2092824/post-4563508
- the girl with the white jacket.
Please examine the edges. In the original there is massive halo and outlining, and I was researching about pretty radical settings in the kernel. This had seduced the encoder to blur out a lot of periphery.

It starts with the studio, oversharpening during post-production with whatever reason, perhaps camera lense not well focused.
In the digital domain, you end up with grain between adjacent pixels plus outlining etc. and on small devices it looks sharper.
Furthermore, sharpening interlaced videos is a can of worms. A frequent artifact is dark horizontal bars above white edges, 2px wide.

Convolution is a bit of a wave/particle approach. You can target particular distances and directions, but you create also a different frequency spectrum i.e. tampering with resolution. Especially, asymmetric kernels 5x5 with alternating coefficients work more like a 5-band audio graphic equalizer.
The grain has its own narrow spectrum, most of it would sit on the second highest slider in a simulated EQ device.

In consequence, canceling the outlining also removes a lot of grain, so I'm pointing out, that grain removal is a secondary effect in my use of convolution. It works different from the usual anti-grain filters.
 

SamKook

Grand Wizard
Staff member
Super Moderator
Uploader
May 10, 2009
3,560
4,927
BTW Porni, do you set the --sar when encoding a DVD with x264? I've noticed the thumbnails from your FTBD-036 rip had the wrong aspect ratio and the most likely reason is that the software used ignored the DAR from the container and you left the h264 stream(which is where the sar option sets the ratio) as the original DVD aspect ratio.

If you set the SAR(Sample Aspect Ratio), which is the original width : the desired width as a ratio, then it won't get ignored by poorly designed players/softwares.
So for 16:9 you'd use -- sar 853:720 and for 4:3 it'd be 8:9(720:640 divided by 80 each, which is not necessary to do), assuming there's no cropping involved.
You can also set both the SAR and DAR without issue, which is what I do.
 
  • Like
Reactions: CoolKevin

Porni

Well-Known Member
Feb 29, 2012
346
321
I set the aspect ratio in MKVToolNix and don't do anything else, I don't see the point and know how to do it.
 

SamKook

Grand Wizard
Staff member
Super Moderator
Uploader
May 10, 2009
3,560
4,927
Broader compatibility is pretty much it, but most player will read the DAR from the mkv so not a big deal, just the occasional annoyance from a thumbnailer or something like that.
 
  • Like
Reactions: CoolKevin

Kevin_san

Member
Nov 24, 2015
55
14
thx Porni and SamKook for your uploads in high quality, it helps me to improve.
Aki, beginning of scene #10, vlcsnaps from ISO and my processing. This snapshotting is fast, but real screen shots are a bit better.
Certain vertical tight structures produce ringing, I will try to mitigate that, but mathematically it is inevitable when we sharpen and filter, and the input signal is already steep. The post production should have filtered that. It happens much less with newer DVDs, because the makers do this since some time.
Plz note that all my work is done without using QTGMC at all. This means less equalizing and less compression, some chances for stronger dynamics in the composition of the picture, depending on the skills of the camera operator.
It seems though, that QTGMC reduces file size remarkably, due to that kind of leveling processing and denoising.
 

Attachments

  • vlcsnap-2022-09-06-19h33m49s438.png
    vlcsnap-2022-09-06-19h33m49s438.png
    948.4 KB · Views: 126
  • vlcsnap-2022-09-06-19h45m21s329.png
    vlcsnap-2022-09-06-19h45m21s329.png
    605.6 KB · Views: 118
  • vlcsnap-2022-09-06-19h34m26s352.png
    vlcsnap-2022-09-06-19h34m26s352.png
    930.1 KB · Views: 118
  • vlcsnap-2022-09-07-03h57m41s421.png
    vlcsnap-2022-09-07-03h57m41s421.png
    878.7 KB · Views: 117
  • vlcsnap-2022-09-07-04h01m20s542.png
    vlcsnap-2022-09-07-04h01m20s542.png
    799.2 KB · Views: 109

Porni

Well-Known Member
Feb 29, 2012
346
321
Why don't you use QTGMC? If you like a blurry picture, just set sharpness to 0 + FineDehalo (or something similar)
 

Kevin_san

Member
Nov 24, 2015
55
14
on my system it takes too long, also I would have to put together an entirely new / recent avisynth with all those libraries and multithreading.
you might otherwise consider to process within minutes. it's more about the sparkle and crisp in the sharp parts of the picture.
QTGMC in frequently used settings seems to attempt to give all sectors and corners of the picture the same sharpness.
I don't consider the kitchen pic blurred. it mainly represents what the camera did, and is more crispy than the iso.
(also removes staircase artifacts on the knobs, but you see this only on a screen shot, I may be back with such some time later.)
 
Last edited:

SamKook

Grand Wizard
Staff member
Super Moderator
Uploader
May 10, 2009
3,560
4,927
You have to adjust QTGMC settings for the output you want, you don't have to use all of its features like the denoising one and other stuff.

QTGMC isn't technically a deinterlacer, it makes use of other deinterlacers and its main purpose is to reduce bob flicker(lines and stuff that shifts or shrink/expand by 1 pixel due to the interlaced frames constantly alternating by that 1 pixel) so it has to do some temporal smoothing and motion analysis to fix that. How much or how little it does is controlled by you with the settings and there's an option to adjust how much grain gets restored.
Most settings use nnedi3 as the deinterlacer internally which is pretty slow but you can tell it to use others like yadifmod2.
That bob flicker will also hurt compression since instead of a static image, you have something there that's constantly changing so require more bits.

If you're fine with its limitations, you can also use staxrip instead of having to set up a whole avisynth installation, it does all that for you and you can put any avisynth commands in there you want like I demonstrated near the beginning of the thread.


BTW, the sides of your upscaled pictures are messed up. It's especially visible on the left side where you clearly see there's a 1 pixel line that's paler than it should be. All sides have something similar but not always very obvious.
 
Last edited: