RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY

[guest]

because there are 2 time compresion.
ripbot can handle simple color correction like satutation, contrast etc,
so, why can't use external lut?

Well, if you could upload a .cube and whatever else it needs, might be a starting point for this.

[darkio]

this is the plugin
http://www.avisynth.nl/index.php/AVSCube

and this is a zip with 54 luts freeware inside
https://www.swisstransfer.com/d/f66b03e6-2ab9-4a16-bddc-475c345f893d

Thanks in advance

Example LUT
Source NO LUT:
https://i.postimg.cc/7GpWQ8xY/Lut-OFF.png (https://postimg.cc/7GpWQ8xY)
Same Source LUT ON: (Clouseau 54.CUBE)
https://i.postimg.cc/1VGJC8CJ/Lut-ON.png (https://postimg.cc/1VGJC8CJ)

Used in Tmpgenc Mastering Works 7

[guest]

this is the plugin
http://www.avisynth.nl/index.php/AVSCube

and this is a zip with 54 luts freeware inside
https://www.swisstransfer.com/d/f66b03e6-2ab9-4a16-bddc-475c345f893d

Thanks in advance

Example LUT
Source NO LUT:
https://i.postimg.cc/7GpWQ8xY/Lut-OFF.png (https://postimg.cc/7GpWQ8xY)
Same Source LUT ON: (Clouseau 54.CUBE)
https://i.postimg.cc/1VGJC8CJ/Lut-ON.png (https://postimg.cc/1VGJC8CJ)

Used in Tmpgenc Mastering Works 7

Hi darkio,

I am happy to provide this awesome add-on for RipBot264, at your request.

It took me and a new friend of mine, kedautinh12, several hours to get it to work within RipBot.

And I think this IS a MAJOR game-changer for the app, so thankyou.

ENJOY !!!!!

[SKPN]

Is there a way to delete the files from the watch folder(s) after they are processed in automated batch mode?

[guest]

Is there a way to delete the files from the watch folder(s) after they are processed in automated batch mode?

Not ever having used Watch Folders, maybe you could create a small cmd or batch file that would "clean out" the folders, and you could run that cli using the "Run command script after finished job" on the Main tab page of RipBot.

OR, wait and see if the dev comes up with a suggestion or a revision to the app.

[legend]

I have nvidia GPU. I did not find x265 NVenc like other GUI. How do I enable this?

[guest]

I have nvidia GPU. I did not find x265 NVenc like other GUI. How do I enable this?

This has been asked about many times, and that's about as far as it goes :(

You'll have to look elsewhere to use this option.

[LigH]

NVEnc is not x265. They are different H.265 video encoders. NVEnc uses your Nvidia GPU to encode H.265 video, x265 does not. Furthermore, x265 can be controlled in many more different ways than NVEnc, so it is suited much better for segmented encoding, and also it can run in several parallel instances (your GPU encoder chip can be used only by one process at a time). If you don't need segmented encoding, possibly distributed across a network of many PCs encoding different parts of a video, then you may not really need RipBot264...

[guest]

NVEnc is not x265. They are different H.265 video encoders. NVEnc uses your Nvidia GPU to encode H.265 video, x265 does not. Furthermore, x265 can be controlled in many more different ways than NVEnc, so it is suited much better for segmented encoding, and also it can run in several parallel instances (your GPU encoder chip can be used only by one process at a time). If you don't need segmented encoding, possibly distributed across a network of many PCs encoding different parts of a video, then you may not really need RipBot264...

Very nicely explained, LigH.

So, not everyone has compatible nVidia GPU's, and also the fact that Distributed Encoding couldn't be used, then there's not really any point !!

So even if Atak took the time to implement this, only limited users would take what ever advantage GPU encoding might offer, if the spped of DE isn't there, and let's face it, DE is the most impressive function of any of the main available Encoding apps.

The same probably applies to wanting to use NV Decoding.

The only process that is probably an option would be to let RipBot do it's complete process, then before deleting the Temp files, to manually re-encode the files generated by RB, using NVEnc, so basically doubling the time taken to get the desired result.

Might be able to use the function introduced some time ago to run the "Job finished successfully.cmd" to automate some script / cli.

So just repeating what LigH said :-

If you don't need segmented encoding, possibly distributed across a network of many PCs encoding different parts of a video, then you may not really need RipBot264...

[phred1]

Hiya
Updated to latest version 1.21.6 from a much older version. Now I cant get the EncodingServer to start. Where do I start with finding what I have done wrong? All tools seems to be installed (some with green and some with black icons in the list).

[Atak_Snajpera]

Try again in SAFE MODE

[Daringbaaz]

https://i.imgur.com/C3Yxtv5.jpg

Can Anyone Tell me Why There is some segments not Started or Not Completed,

Due to this My encoding Stopped on 99.4% and I Didn't Find any option to re-start That segments,

Please Help Me,

[Atak_Snajpera]

You should check what EncodingServer (192.168.1.70:4000) is showing in both tabs.

[guest]

Can Anyone Tell me Why There is some segments not Started or Not Completed,

Due to this My encoding Stopped on 99.4% and I Didn't Find any option to re-start That segments,

Please Help Me,

I have that happen quite often...best thing is to Abort the Job.

Then restart the job, 9 times out of 10 it will remember how many chunks it has already encoded, and complete the job.

[stillempty]

@Atak - Thanks for all your hard work over the years. I have been using Ripbot264 for a long time and have always been able to tweak the things I need for excellent results. I hope you have not lost your passion for this program!

@Pauly Dunne - I truly understand the frustration of trying to improve things for strangers and not getting feedback. Sadly you probably only hear about the things that do not work. I would most definitely take a look at the builds you were putting together for the community!

I have been playing around with HDR10+ and Dovi recently and am now very close to having these things worked out in Ripbot264. I will share this info in the next few days, to hopefully save others some time.

Empty

[guest]

@Atak - Thanks for all your hard work over the years. I have been using Ripbot264 for a long time and have always been able to tweak the things I need for excellent results. I hope you have not lost your passion for this program!

@Pauly Dunne - I truly understand the frustration of trying to improve things for strangers and not getting feedback. Sadly you probably only hear about the things that do not work. I would most definitely take a look at the builds you were putting together for the community!

I have been playing around with HDR10+ and Dovi recently and am now very close to having these things worked out in Ripbot264. I will share this info in the next few days, to hopefully save others some time.

Empty

Hey Empty,

Thanks for the comment :)

I will be interested to see what you've come up with...

[userx]

Hi
After last update i'm not able to apply new jobs to the queue.
The Done-button is not clickable.
Can anybody help?

https://i.imgur.com/kCOf6Pw.png

https://i.imgur.com/85WJozb.png

[ReinerSchweinlin]

I encountered something similar in the avisynth tab: After "demo" of sharpening, the "ok" button grayed out. Selecting a crop area and switching back worked as a workaround.

[guest]

Hi Atak,

Remember way back here :-

https://forum.doom9.org/showthread.php?p=1951664#post1951664

I was able to add LUT's support to RipBot 3 weeks ago.

And then I read the "Avisynth+_Cube.txt"

Apply 3D LUT to HDR10 PQ clip obtained from DGSource():

loadplugin("...\dgdecodenv.dll")
loadplugin("...\avsresize.dll")
loadplugin("...\vscube.dll")
dgsource("THE GREAT WALL.dgi",fulldepth=true)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:f", dither_type="none")
Cube("...\test.cube")
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:f=>2020ncl:st2084:2020:l",dither_type="none")

As far as I know you can't use DGSource in RipBot... (or can you, and you've kept it to yourself)

It would be nice to use .dgi in RB.

BTW, everybody, an auto-update "snuck out" with LUT support

[userx]

I encountered something similar in the avisynth tab: After "demo" of sharpening, the "ok" button grayed out. Selecting a crop area and switching back worked as a workaround.
@ReinerSchweinlin
Thanks for the hint.
I have to open the avisynth window, click into any setting box e.g. Resize -> OFF to get the OK of avisynth window clickable, exit this window by OK. Afterwards the Done-Button is clickable again.

Edit:
When changing the output filename / path AFTER this workaround DONE gets disabled again.

[ReinerSchweinlin]

For several months now, I have made available very up to date & modified build's of RipBot264.

....

So as of date of posting this, I will no longer provide this service, and I will keep all my hard work to myself, and for my benefit only.

Sorry to hear that. In the last year, I have not had enough time to visit doom9 on a regular basis, so I didn´t even download your stuff or played with it. I can understand your frustration and - although I didn´t use your stuff - wanted to say thanx for your efforts and files...

@Atak
I am not sure if I did read correct between the lines - I got the impression you were absent a lot (but since I was absent, I am deriving that from what others wrote)... So I hope you are fine and of good health!

[guest]

Sorry to hear that. In the last year, I have not had enough time to visit doom9 on a regular basis, so I didn´t even download your stuff or played with it. I can understand your frustration and - although I didn´t use your stuff - wanted to say thanx for your efforts and files...


Hey Reiner,

I am happy to know that you would have been interested in trying my "stuff"....it doesn't mean that you can't still try it, but I doubt that I will post it again on the Forum.

Speaking of which, I don't want to sound like the Forum "detective", but you have posted no less than 31 times, so far this year, and one post was just before my post that you have quoted.....:sly:

I did have a couple of users "ask" for it, and they were very happy with all the extra filters & features, and even how much faster it seemed to be...but out of the many that downloaded it, I got nothin', hence my decision to "pull it".

Anyway, I would like to say that I will be pretty much leaving these forums, for the time being, I might post from time to time.

I will probably respond to any direct posts, but that's about it.

But when you don't seem to get the info you're seeking, and then if you sound a little frustrated, or defensive, they "warn" you, so why bother.

[videoh]

I did have a couple of users "ask" for it, and they were very happy with all the extra filters & features, and even how much faster it seemed to be...but out of the many that downloaded it, I got nothin' Sounds contradictory to me. You got requests and good feedback but then you say you got nothing.

Also, you say you added filters and such. So it should not be an issue for you to add DGSource(), or am I missing something?

[guest]

Sounds contradictory to me. You got requests and good feedback but then you say you got nothing.

Also, you say you added filters and such. So it should not be an issue for you to add DGSource(), or am I missing something?

Come on videoh,

What I meant was, I had a couple of PM requests, BUT out of the close to a hundred or so downloads, when it was "open slather", I got nothing.

No contradiction...

I might be able to get it too work, but I don't know how to incorporate it into the way RipBot scripts are written, for encoding & decoding tasks.

It just confuses my old brain.......and I need to be "spoon feed", as I've said before, I really don't know what I'm doing, but if it works, it's great.

I think I've touched on this before with you, unless I'm getting the names mixed up.

I'd say that I wouldn't use it, I think it's nVidia based, and may not work with the Distributed Encoding process.

BUT there might be users out there that would like different options, and RipBot has none, it's LSmash or nothin'.

[videoh]

We'll miss you, Pauly.

[ReinerSchweinlin]

Sherlock,



Speaking of which, I don't want to sound like the Forum "detective", but you have posted no less than 31 times, so far this year, and one post was just before my post that you have quoted.....:sly:
yes.
"having not mich time" or "being absent" doesn´t have to literally mean "no visit at all" :) Beleive me, I have been spending much less time on forums last year than I used to - I know, I was there :)

[phred1]

Try again in SAFE MODE
Hi and tnx!
Like in booting Windows 10 in Safe Mode or launching the app in like "Windows 8" mode? =)

[sapphiresky83]

Hi all! Long time Ripbot user. Just did a fresh Win 10 install with the latest version of Windows last week. I’ve done this before and have restored my RipBot setup every time without issue.

This time, however, I am having an issue where while using Distributed Encoding, where my two machines, each running two servers a piece, is encoding the same chunks over and over again rather than completing the entire list of chunks. I’ve never experienced this before.

I’ve set everything up the same exact way I did before I did the fresh install.

I’ve gone through updating/installing/reinstalling all of the support and background apps (ffmpeg/avisynth+) but still no joy.

Thanks!


Sent from my iPhone using Tapatalk

[guest]

Is there some way of adapting this "call" so that RipBot can use it ?

pre=ex_KNLMeansCL(a=2,s=2,d=1,h=7.0,wmode=0)
SMDegrain(tr=3,thSAD=300,contrasharp=30,prefilter=pre,refinemotion=true)

TIA

[Atak_Snajpera]

Is there some way of adapting this "call" so that RipBot can use it ?



TIA

pre=ex_KNLMeansCL(video,a=2,s=2,d=1,h=7.0,wmode=0)
video=SMDegrain(video,tr=3,thSAD=300,contrasharp=30,prefilter=pre,refinemotion=true)

[guest]

pre=ex_KNLMeansCL(video,a=2,s=2,d=1,h=7.0,wmode=0)
video=SMDegrain(video,tr=3,thSAD=300,contrasharp=30,prefilter=pre,refinemotion=true)

:thanks: it worked, except the contrasharp value, I had to change it to true.

[Ripmann]

EDIT: Since Akak is sadly AFK, I spent last couple of days figuring it out on my own. I finally found a solution to the problem and will post it a little bit later, after I finish my tests.

====================================
Hey guys. I finally got back into encoding my library backlog and immediately noticed this issue while experimenting with HDR sources. Using denoise filters on an HDR source seems to cause extremely buggy results in some frames. It looks like severe chroma smearing of some kind. I've noticed it before but couldn't quite identify the root cause, but now tests clearly showed that it's the degrain filters (in this case MDegrain2) that cause it. It's possible that the problem is not HDR related, but I don't remember noticing it on SDR sources. My guess is that it's the very low contrast of HDR video streams that either causes or exacerbates this.

See the screens, and I'm attaching a short video sample (under fair use), if you want to test it yourself. The link will expire in two weeks. The buggy frames are the first few frames of the scene change. In case Atak is unable to address this, does anyone know how to tweak the job's MDegrain code manually to fix this? I was forced to stop everything I was doing and can't do anything until I figure this out.

https://s9.gifyu.com/images/low_res2.gif

Source sample: https://www.mediafire.com/file/x95dz50wuoj9eks
Full-res screens: https://imgur.com/a/O4lyRiq
Related discussion: https://forum.doom9.org/showthread.php?t=177128
(It has some suggestions but I'm not proficient enough to get them into RipBot. I tried playing with SMDegrain.avsi settings , but the job seemed to ignore it altogether.)

[guest]

Related discussion: https://forum.doom9.org/showthread.php?t=177128 (Denoising HDR sources)
(It has some suggestions but I'm not proficient enough to get them into RipBot. I tried playing with SMDegrain.avsi settings , but the job seemed to ignore it altogether.)

Hey Ripmann,

I was interested in this link, but it wouldn't open for me...

[guest]

So a question about multiple video cards...

If you had say 2 or so nVidia cards, would it be beneficial to just use them individually and add a command line to each card, per port.....or SLI them, and use them as is (one unit) ??

[Ripmann]

So a question about multiple video cards...

If you had say 2 or so nVidia cards, would it be beneficial to just use them individually and add a command line to each card, per port.....or SLI them, and use them as is (one unit) ??

I fixed that link. To answer your GPU question, last I checked you cannot SLI two different graphics cards. If your cards have the same chipsets, then it makes sense to SLI only to have a smoother experience, full acceleration, and faster FPS rates for everything else. If that's something you not interested in for some atypical reason, then having two disconnected cards seems only useful for minor power saving (since the spare one will always be idle when not encoding) and full control over separation of tasks (gaming on one, encoding on another). Other than that, I seriously doubt that you'll have any noticeable benefits separating the two for encoding purposes, and manually assigning the workload for each job seems like too much work by itself.

[guest]

I fixed that link. To answer your GPU question, last I checked you cannot SLI two different graphics cards. If your cards have the same chipsets, then it makes sense to SLI only to have a smoother experience, full acceleration, and faster FPS rates for everything else. If that's something you not interested in for some atypical reason, then having two disconnected cards seems only useful for minor power saving (since the spare one will always be idle when not encoding) and full control over separation of tasks (gaming on one, encoding on another). Other than that, I seriously doubt that you'll have any noticeable benefits separating the two for encoding purposes, and manually assigning the workload for each job seems like too much work by itself.

Hi Ripmann,

Checked out the link...:thanks:

Of course I would be using identical GPU's :rolleyes:

I will try both setup's, but assigning one card to one port, and the other one to a different port is pretty straightforward (even for me), in RipBot.

As for this small print comment :-
(It has some suggestions but I'm not proficient enough to get them into RipBot. I tried playing with SMDegrain.avsi settings , but the job seemed to ignore it altogether.)

May I suggest you visit Dogway's forum, he's doing a LOT with SMDegrain, with various pre-filters, etc & more.

[Ripmann]

I will try both setup's, but assigning one card to one port, and the other one to a different port is pretty straightforward (even for me), in RipBot.

Sure, if you're having doubts, testing is definitely the way to go. It's not like you'll need a lot work to switch between the modes, and you'll have hard data to back up your decision. I predict you'll probably end up going SLI since it's hard to come up with reasons not to, but as a fan of the scientific method I'm not even going to try to dissuade you.

May I suggest you visit Dogway's forum, he's doing a LOT with SMDegrain, with various pre-filters, etc & more.

Thanks for the tip. I'll take a look, but so far my searches didn't come up with anything actionable at my skill level. I'm still largely a novice when it comes to advanced x265 params and don't know first thing about AviSynth coding. And while usually I wouldn't mind learning yet another scripting language, my COVID-derailed life is in such a backlogged chaos right now that I was kind of hoping for an easier solution than that. Like a couple of lines of code from someone who knows what he's doing. Besides, since this seems like a common and reproducible problem, it means that other people's encodes have the same issues. I'd rather see a solution that works for everyone, not just me.

[guest]

Hey guys. I finally got back into encoding my library backlog

Source sample: https://www.mediafire.com/file/x95dz50wuoj9eks


I thought I'd download this and have a look, but it's only 17Mb, and 17Mb of 4K footage is nothing!..hence I couldn't get it to play.

[Ripmann]

I thought I'd download this and have a look, but it's only 17Mb, and 17Mb of 4K footage is nothing!..hence I couldn't get it to play.

Just tried downloading and it works fine for me. The clip is only 2 seconds long, just enough to illustrate the problem without wasting time on unnecessary encoding. I don't know what player you use, but you need to pause go frame by frame to notice it. It's the first couple of frames after the scene change, which is probably the reason no one else is complaining about it. It's hard to notice on normal 24fps playback. Unless you catch it by accident, you have to focus and know exactly what to look for. There were plenty of these in the original encode (as well as in the other two before that, as I found out today), but I assume once a solution for fixing this particular segment is found, the rest will probably go away as well.

By the way, since it doesn't seem like a local problem—anyone cares to replicate?—those of you who really care about losing quality at this level may want to pause your HDR+degrain encodes and keep the originals until you make sure your jobs were not affected.

[guest]

Just tried downloading and it works fine for me. The clip is only 2 seconds long, just enough to illustrate the problem without wasting time on unnecessary encoding. I don't know what player you use, but you need to pause go frame by frame to notice it. It's the first couple of frames after the scene change, which is probably the reason no one else is complaining about it. It's hard to notice on normal 24fps playback. Unless you catch it by accident, you have to focus and know exactly what to look for. There were plenty of these in the original encode (as well as in the other two before that, as I found out today), but I assume once a solution for fixing this particular segment is found, the rest will probably go away as well.

By the way, since it doesn't seem like a local problem—anyone cares to replicate?—those of you who really care about losing quality at this level may want to pause your HDR+degrain encodes and keep the originals until you make sure your jobs were not affected.

I use either VLC or Potplayer, still can't even frame by frame it...but that doesn't matter.

So what is that footage from ??

BTW, I sent you a PM...

[Ripmann]

I never warmed to VLC for some reason, even though I've been trying it every 5 years or so since its release. If you get a "real" player like MPC-BE or MPC-HC, you can easily go frame by frame from there. I forget what the default shortcuts are, but it should be directional left/right arrows plus the combinations with SHIFT and CTRL. One of these will skip several seconds, another will jump to the next/previous keyframe, and yet another will go frame by frame. Check the keyboard shortcuts if you actually decide to use it.

Also again, the sample is the original source. If you want to test whether you can reproduce the issue, you'll have to encode it (the screens above used HEVC, CRF15, MDegrain2x400), and then compare the frames I was talking about by opening two players side by side (or rather placing one on top of another and toggling minimize/restore for one) and comparing the differences visually. If you can reproduce, chances are that any of your jobs that use similar settings will have similar issues of their own.

[guest]

I never warmed to VLC for some reason, even though I've been trying it every 5 years or so since its release. If you get a "real" player like MPC-BE or MPC-HC, you can easily go frame by frame from there. I forget what the default shortcuts are, but it should be directional left/right arrows plus the combinations with SHIFT and CTRL. One of these will skip several seconds, another will jump to the next/previous keyframe, and yet another will go frame by frame. Check the keyboard shortcuts if you actually decide to use it.

Also again, the sample is the original source. If you want to test whether you can reproduce the issue, you'll have to encode it (the screens above used HEVC, CRF15, MDegrain2x400), and then compare the frames I was talking about by opening two players side by side (or rather placing one on top of another and toggling minimize/restore for one) and comparing the differences visually. If you can reproduce, chances are that any of your jobs that use similar settings will have similar issues of their own.

The only time I use MPC-HC is within RipBot...

I might try and process the sample, and see if it even loads, @ 2 seconds, I'd be surprised.

What is the original footage ??

I haven't used MDegrain for quite some time..

[guest]

So a question about multiple video cards...

If you had say 2 or so nVidia cards, would it be beneficial to just use them individually and add a command line to each card, per port.....or SLI them, and use them as is (one unit) ??

So I tried 2 x HD 6850 AMD cards, both as singles & crossfire, and RipBot recognises them as 2 separate cards, either way.

I guess SLI would be similar.

So 1 port get's Device 0, another port gets Device 1...that's all there is to it, it seems.

[Ripmann]

I'm posting what seems to be a solution to the smearing problem I described above (post #19286 (https://forum.doom9.org/showthread.php?p=1954617#post1954617)). My first idea was to set plane=0 in MDegrain, to only process the luma (brightness) and not chroma (colors). However, I figured out that since there was a problem with colors, there may have possibly been similar problem with brightness, and I wasn't wrong. They're just harder to notice, but they are there. So I read up on the functions and played with the settings some more, and what I came up is lowering thSCD2 from its default setting of 130 to something more appropriate, like so:

video=MDegrain1(video,super,bv1,fv1,thSAD=600,thSCD2=80)

According to the wiki, thSCD2 is the threshold which sets how many blocks have to change for the frame to be considered as a scene change. It's ranged from 0 (0%) to 255(100%). The default is 130, or 51%, which was clearly a problem with the scene above. I lowered it to 65 (~25%), and the artifacts were finally gone. I still have to do few tests to come up with an optimal number, but 80 (31%) worked well so far on a less than a handful of test scenes.

In short, what happens on the default settings is that the filter compares previous and next frames and 'merges' their data. It didn't see the last frame before the scene change as a a totally unrelated scene, and therefore the artifacts I highlighted are the buggy remnants of the previous unrelated frame.

So, anyway, I typed it up almost immediately after my first rounds of testing, since the results look very promising and I don't want anyone waste time on this the way I did. If I find any issues, I'll let you know and update the post.

Relevant wiki for MVTools:
http://www.avisynth.nl/users/fizick/mvtools/mvtools2.html#functions

[Ripmann]

Probably a long shot again, but here we go:

Did somebody here try BM3D for AVS+ (https://forum.doom9.org/showthread.php?p=1951430#post1951430)? How does it compare to KNLMeansCL? I'm looking for a better GPU denoiser (CPU ones fight for the processing power with the encoder and greatly increase the processing time, but GPU ones seem to run in parallel) to replace KNLMeansCL, and this one looks promising. KNLMeansCL is just too simplistic parameter-wise, and I can't get good results with it without losing a lot of quality in some scenes. Anyway, I just tried adding BM3DCUDA to a RipBot job script and failed miserably so far. If anyone has done it already, I'd appreciate a snippet for reference.

EDIT: Also, ATAK, if you're reading this, any chance you could quickly add "Edit Job.avs" into the job submenu? Preferably to open its .avs with a default text editor, but even just opening it with the default association would be great. Would really speed things up. Thanks.

[Ryushin]

I'm posting what seems to be a solution to the smearing problem I described above (post #19286 (https://forum.doom9.org/showthread.php?p=1954617#post1954617)). My first idea was to set plane=0 in MDegrain, to only process the luma (brightness) and not chroma (colors). However, I figured out that since there was a problem with colors, there may have possibly been similar problem with brightness, and I wasn't wrong. They're just harder to notice, but they are there. So I read up on the functions and played with the settings some more, and what I came up is lowering thSCD2 from its default setting of 130 to something more appropriate, like so:

video=MDegrain1(video,super,bv1,fv1,thSAD=600,thSCD2=80)
[/I]

Thank you for digging into this and finding a solution. I've updated my MDegrain custom filters with this information.

[guest]

Just thought I'd let you guy's know that (even tho it may have been done before), I had an epiphany today, and figured out how to produce & encode DGI. (created with DGDecNV) sources thru RipBot.

It turned out to be pretty simple, a little bit of script editing, and that's that.

All you need is an nVidia GPU, and some drivers.

As for encoding using NVEnc, is a very different story...

[archiel]

I have recently migrated to Windows 11 (from Win 10 Pro 64 bit). I have noted that
(1) ripbot264 no longer closes cleanly - it continues to be visible in task manager as 'not responding'.
(2) EncodingServer no longer works, I can see it in Task Manager, but there is no gui and trying to run in distributed mode does not work - no connections are made. Trying compatibility mode did not help (tried 8 and 7, there is no Windows 10 mode). EncodingServer loads normally in safe mode.
Otherwise when run in local mode ripbot264 works as expected, other then the failure to close fully on exit.

[guest]

I have recently migrated to Windows 11 (from Win 10 Pro 64 bit). I have noted that
(1) ripbot264 no longer closes cleanly - it continues to be visible in task manager as 'not responding'.
(2) EncodingServer no longer works, I can see it in Task Manager, but there is no gui and trying to run in distributed mode does not work - no connections are made. Trying compatibility mode did not help (tried 8 and 7, there is no Windows 10 mode). EncodingServer loads normally in safe mode.
Otherwise when run in local mode ripbot264 works as expected, other then the failure to close fully on exit.

So, have you had any luck ??

I ran RipBot with a very early Beta build of W11, with no issues at all, however, W11 itself started to piss me off, so I went back to W10.

But I am about to upgrade one PC to "proper" W11 in the next day or so, so hopefully there'll be no problem's.

So, there must be something you need to re install, as your RipBot work OK with W10, so just check, are you using the latest build of RipBot ??, maybe a newer build of Avisynth, or VC_redist.x64...

Are you running nVidia GPU software....

[archiel]

So, have you had any luck ??

I ran RipBot with a very early Beta build of W11, with no issues at all, however, W11 itself started to piss me off, so I went back to W10.

But I am about to upgrade one PC to "proper" W11 in the next day or so, so hopefully there'll be no problem's.

So, there must be something you need to re install, as your RipBot work OK with W10, so just check, are you using the latest build of RipBot ??, maybe a newer build of Avisynth, or VC_redist.x64...

Are you running nVidia GPU software....

No change from above, if EncodingServer.exe tries to run then RipBot will hang. The machine is dual boot and the same problem whether I run on Win 11 current version or latest insider release (dev channel). RipBot, Windows and all other software are latest versions, as is motherboard bios (Gigabyte Aorus B550 Pro V2)

Avisynth+ is 3.7.0 and the Nvidia software is

Release Version
FrameView SDK 1.1.4923.29968894
GeForce Experience 3.23.0.74
Graphics Driver 472.12
PhysX System Software 9.21.0713

Windows Insider Dev Channel
FrameView SDK 1.1.4923.29968894
GeForce Experience 3.23.0.74
Graphics Driver 510.31
PhysX System Software 9.19.0218

Hopefully you will have a better result.