Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
12th October 2021, 02:47 | #19282 | Link |
Registered User
Join Date: Nov 2019
Posts: 72
|
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.) Last edited by Ripmann; 14th October 2021 at 23:59. Reason: Eureka |
12th October 2021, 10:42 | #19283 | Link | |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
Quote:
I was interested in this link, but it wouldn't open for me... |
|
12th October 2021, 11:12 | #19284 | Link |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
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) ?? |
12th October 2021, 17:09 | #19285 | Link |
Registered User
Join Date: Nov 2019
Posts: 72
|
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.
|
13th October 2021, 00:38 | #19286 | Link | ||
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
Quote:
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 :- Quote:
|
||
13th October 2021, 04:58 | #19287 | Link | ||
Registered User
Join Date: Nov 2019
Posts: 72
|
Quote:
Quote:
|
||
13th October 2021, 06:40 | #19288 | Link | |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
Quote:
|
|
13th October 2021, 09:25 | #19289 | Link | |
Registered User
Join Date: Nov 2019
Posts: 72
|
Quote:
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. |
|
13th October 2021, 10:34 | #19290 | Link | |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
Quote:
So what is that footage from ?? BTW, I sent you a PM... |
|
13th October 2021, 12:40 | #19291 | Link |
Registered User
Join Date: Nov 2019
Posts: 72
|
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. |
13th October 2021, 13:37 | #19292 | Link | |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
Quote:
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.. |
|
14th October 2021, 08:16 | #19293 | Link | |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
Quote:
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. |
|
15th October 2021, 00:26 | #19294 | Link |
Registered User
Join Date: Nov 2019
Posts: 72
|
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 |
15th October 2021, 02:01 | #19295 | Link |
Registered User
Join Date: Nov 2019
Posts: 72
|
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. Last edited by Ripmann; 16th October 2021 at 04:30. |
15th October 2021, 17:03 | #19296 | Link | |
Registered User
Join Date: Mar 2011
Posts: 433
|
Quote:
|
|
22nd October 2021, 11:24 | #19297 | Link |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
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... Last edited by TDS; 22nd October 2021 at 11:27. |
24th October 2021, 15:11 | #19298 | Link |
Registered User
Join Date: Apr 2019
Posts: 49
|
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. |
25th October 2021, 12:22 | #19299 | Link | |
Formally known as .......
Join Date: Sep 2021
Location: Down Under.
Posts: 1,003
|
Quote:
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.... |
|
25th October 2021, 20:34 | #19300 | Link | |
Registered User
Join Date: Apr 2019
Posts: 49
|
Quote:
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. |
|
Tags |
264, 265, appletv, avchd, bluray, gui, iphone, ipod, ps3, psp, ripbot264, x264 2-pass, x264 gui, x264_64, x265, xbox360 |
|
|