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

[TDS]

Originally Posted by Atak_Snajpera

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)

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.



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.)

[TDS]

Originally Posted by Ripmann

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.)

Hey Ripmann,

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

[TDS]

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]

Originally Posted by TDS

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.

[TDS]

Originally Posted by Ripmann

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...

Of course I would be using identical GPU's

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]

Originally Posted by TDS

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.

[TDS]

Originally Posted by Ripmann

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]

Originally Posted by TDS

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.

[TDS]

Originally Posted by Ripmann

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.

[TDS]

Originally Posted by 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.

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..

[TDS]

Originally Posted by TDS

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). 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/...html#functions

[Ripmann]

Probably a long shot again, but here we go:

Did somebody here try BM3D for AVS+? 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]

Originally Posted by Ripmann

I'm posting what seems to be a solution to the smearing problem I described above (post #19286). 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.

[TDS]

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.

[TDS]

Originally Posted by 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.

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]

Originally Posted by TDS

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.