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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 1st October 2021, 22:58   #19281  |  Link
phred1
Registered User
 
Join Date: Aug 2011
Posts: 5
Quote:
Originally Posted by Atak_Snajpera View Post
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? =)
phred1 is offline   Reply With Quote
Old 7th October 2021, 03:23   #19282  |  Link
sapphiresky83
Registered User
 
Join Date: Oct 2021
Posts: 2
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
sapphiresky83 is offline   Reply With Quote
Old 10th October 2021, 13:58   #19283  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Is there some way of adapting this "call" so that RipBot can use it ?

Quote:
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
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 10th October 2021, 15:28   #19284  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,625
Quote:
Originally Posted by TDS View Post
Is there some way of adapting this "call" so that RipBot can use it ?



TIA
Code:
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)
Atak_Snajpera is offline   Reply With Quote
Old 11th October 2021, 01:25   #19285  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Quote:
Originally Posted by Atak_Snajpera View Post
Code:
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.
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 12th October 2021, 02:47   #19286  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 64
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
Ripmann is offline   Reply With Quote
Old 12th October 2021, 10:42   #19287  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Quote:
Originally Posted by Ripmann View Post
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...
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 12th October 2021, 11:12   #19288  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
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) ??
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 12th October 2021, 17:09   #19289  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 64
Quote:
Originally Posted by TDS View Post
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.
Ripmann is offline   Reply With Quote
Old 13th October 2021, 00:38   #19290  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Quote:
Originally Posted by Ripmann View Post
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 :-
Quote:
(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.
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 13th October 2021, 04:58   #19291  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 64
Quote:
Originally Posted by TDS View Post
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.

Quote:
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.
Ripmann is offline   Reply With Quote
Old 13th October 2021, 06:40   #19292  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Quote:
Originally Posted by Ripmann View Post
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.
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 13th October 2021, 09:25   #19293  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 64
Quote:
Originally Posted by TDS View Post
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.
Ripmann is offline   Reply With Quote
Old 13th October 2021, 10:34   #19294  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Quote:
Originally Posted by Ripmann View Post
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...
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 13th October 2021, 12:40   #19295  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 64
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.
Ripmann is offline   Reply With Quote
Old 13th October 2021, 13:37   #19296  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Quote:
Originally Posted by Ripmann View Post
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..
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 14th October 2021, 08:16   #19297  |  Link
TDS
Formally known as .......
 
TDS's Avatar
 
Join Date: Sep 2021
Location: On a need to know basis.
Posts: 53
Quote:
Originally Posted by TDS View Post
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.
__________________
We all need to get a life, before it's over.
TDS is offline   Reply With Quote
Old 15th October 2021, 00:26   #19298  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 64
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 is offline   Reply With Quote
Old 15th October 2021, 02:01   #19299  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 64
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.
Ripmann is offline   Reply With Quote
Old 15th October 2021, 17:03   #19300  |  Link
Ryushin
Registered User
 
Join Date: Mar 2011
Posts: 322
Quote:
Originally Posted by Ripmann View Post
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.
Ryushin is offline   Reply With Quote
Reply

Tags
264, 265, appletv, avchd, bluray, gui, iphone, ipod, ps3, psp, ripbot264, x264 2-pass, x264 gui, x264_64, x265, xbox360

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.