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

[valnar]

I downloaded the PD_Lite build which I assume has most of these settings "correct" by default, such as unchecking Limit to following filters only, etc.

I'm doing an x265 comparison with a simple light SMDegrain (SMD L MED) against an MDegrain1 and my fps results are similar. I'm not seeing a speedup with SMDegrain. This is a single computer, Intel 8 cores.

Any other suggestions?

[archiel]

Until moving to RB PD and adding SMDegrain I have not been using DE. I did when I started using SB, but for normal x265 720p and 1080p it was neither faster nor slower, did clutter up the desktop with unwanted stuff (encoding server windows) and from time to time one or more chunk commands would fail to complete. Moving to standalone mode was just as fast and far less problematic. So ideally I would like to be able to use SMDegrain in standalone, not DE.

For now I have reverted to DE and modified the 2 local servers to
encodingserver /port 1000 /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 16 /x265-threads 16
encodingserver /port 2000 /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 16 /x265-threads 16
as suggested.

Unfortunately all this did was bump usage to 30-35% and then chunk 15 steadfastly refused to complete. I had installed libfftw3f-3, but had not unchecked "Limit to following filters only", which logically I should have and may well be why SMDegrain was using such limited resources. As soon as the current job finishes, I will uncheck and retry in standalone mode.

Until now (without denoising) I had neither limited the main executable, nor added any specific script to limit 'avisynth-prefetch-threads' and the jobs all ran fine. So
1. If I am not limiting the prefetch threads to 12, what could / should be going wrong and how would this manfest?
2. If I do want to limit the prefetch threads, how / where could I do this in standalone for 4K - does adding "/affinity 3FFC3FFC" do this or does it just generally limit the total resources available, even when that is unnecessary?

UPDATE
Unchecked "Limit to following filters only" and now machine is running at 98% CPU and as fast with SMDegrain as it was without.

[archiel]

I downloaded the PD_Lite build which I assume has most of these settings "correct" by default, such as unchecking Limit to following filters only, etc.

I'm doing an x265 comparison with a simple light SMDegrain (SMD L MED) against an MDegrain1 and my fps results are similar. I'm not seeing a speedup with SMDegrain. This is a single computer, Intel 8 cores.

Any other suggestions?

Have you verified - I also downloaded lite and in my case it was checked (probably - unless I did it without thinking). What CPU utilisation are you showing.

For my setup (16 Core Ryzen) the job time has reduced from ~18-19 hours with MDegrain to about 4 hours SMDegrain, also SMD L MED.

[valnar]

Have you verified - I also downloaded lite and in my case it was checked (probably - unless I did it without thinking). What CPU utilisation are you showing.

For my setup (16 Core Ryzen) the job time has reduced from ~18-19 hours with MDegrain to about 4 hours SMDegrain, also SMD L MED.

My "Limit to following filters" is unchecked as it was when I downloaded the PD Lite version. My CPU is 100% on all CPU's as it was with MDegrain. I figured for the same CPU usage it was be faster? At least I was led to believe that.

[Guest]

My "Limit to following filters" is unchecked as it was when I downloaded the PD Lite version. My CPU is 100% on all CPU's as it was with MDegrain. I figured for the same CPU usage it was be faster? At least I was led to believe that.

Hi, so from your PM, you said that you have a 4 core (8 with HT) Intel processor.

That really doesn't bode well for anything "fast", unfortunately for you :(

About all I can suggest is maybe play around with the Prefetch setting.
Which is the "Limit" option on the right side of the Settings Main page. Maybe try 4, and upwards, see if that helps.

[valnar]

Hi, so from your PM, you said that you have a 4 core (8 with HT) Intel processor.

That really doesn't bode well for anything "fast", unfortunately for you :(

About all I can suggest is maybe play around with the Prefetch setting.
Which is the "Limit" option on the right side of the Settings Main page. Maybe try 4, and upwards, see if that helps.

What is the magic sauce that makes people have SMDegrain faster than MDegrain? Is it dedicating cores to AVS/SMDegrain that would be wasted on x265? Or is it in all cases?

[Guest]

What is the magic sauce that makes people have SMDegrain faster than MDegrain? Is it dedicating cores to AVS/SMDegrain that would be wasted on x265? Or is it in all cases?

"Magic sauce" ??

I don't want to cruel, but what can you really expect from such a small CPU ?

Most of the affective settings are when you use Distributed Encoding.

There are also some x265 commands that could improve "speed".

You just have to make the best of what you've got.

[valnar]

"Magic sauce" ??

I don't want to cruel, but what can you really expect from such a small CPU ?

Most of the affective settings are when you use Distributed Encoding.

There are also some x265 commands that could improve "speed".

You just have to make the best of what you've got.

I was under the impression than SMDegrain was faster. Take x265 out of it.

[Guest]

I was under the impression than SMDegrain was faster. Take x265 out of it.

Well, clearly the users that have commented on this, here, have fairly powerful systems, and have stated that there IS a significant improvement.

The smallest CPU is use (but not often) is an 8C/16T dual CPU system, the rest are 12C & (most are)16C systems.

I haven't used a 4C system in too long ago to remember :(

Like I said, you have to do the best with what you've got, it might be some trial & error to get the most out of your system...

[rlev11]

My SMdegrain speed comparisons were with Mdegrain3, I used to use 2 way-way back, I have never used 1 which may be why you are seeing comparable speeds as Mdegrain1 is not nearly as cpu intensive (but also I believe not nearly the quality of Smdegrain). So if Mdegrain1 and SMdegrain are similar speed, use SMdegrain for a much better encode quality. I can assure you that SMdegrain is considerably faster than Mdegrain3.

I run encodes through a farm with 7950x,7900x, i7-14700,5950x,5900x,i5-14500,i5-13500,3950x,3900x and they all run much faster with SMdegrain than Mdegrain3 by the margins I posted earlier.

[valnar]

That makes sense. thanks.

[Ryushin]

For those that are worried about MDegrain vs SMDegrain for speed, it does matter. The difference in output quality for MDegrain vs SMDegrain is drastic. For several years, I stuck with MDegrain2 because the results where quite good and I was very pleased with the results. It took me a year to try out PDs SMDegrain builds because I was resistant to changing something that worked so well, much less learn how a new degraining tool works. One week I had a few days to learn it and I never went back. You can search back in these threads with my extensive testing output and results. Once I found the trick that worked for me, I never went back and I only use SMDegrain at this point. There is no point to ever go back to MDegrain(2). As such I've been asking Atak to just replace MDegrain2 with SMDegrain.

Here is a link to my custom scripts, I just use CPU for degraining and no GPU and set memory to 16GB:
https://cloud.chrisdos.com/s/mdMb6ijE7q9BNJZ

The Blck8 in the scripts is for video that has a lot of dark scenes. In very rare circumstances, there is some weird blocking that can occur, and for the most part, no one notices it except me. Using Blck8 will result in the encoding taking 2-4 times longer to complete.

Not sure if my scripts are compatible with PD latest build or not.

Atak, please really, for the hundreds (could be thousands at this point) of videos I've encoded with SMDegrain, these scripts work wonders compared to MDegrain and RB could just add the Light, Medium, Heavy and people will be thrilled with the results.

[valnar]

For those that are worried about MDegrain vs SMDegrain for speed, it does matter. The difference in output quality for MDegrain vs SMDegrain is drastic.

It has to be pointed out that those scripts also incorporate some prefilters doing blur/sharp which may not always be desirable.

http://avisynth.nl/index.php/SMDegrain
Contrasharp bool (True/False, default False)
Contrasharp int (0-100, default -)
Contrasharpening is a technique that compares the differences between the clip before blurring (original) and after blurring (filtered), and sharpens locally with consequent strength. By default the "sharp" clip is the input, the "after" clip is the denoised clip. Alternately, a "before" clip can be specified with CClip (See Advanced).

* True: use Didée's Contrasharpening() function (ContraHD() for HD) which "Sharpens the denoised clip, but doesn't add more to any pixel than what was removed previously." In the practice you will get a slightly sharper result than the source, which is welcome.

[archiel]

I can already see that adding SMD it has minimal speed impact (16 core Ryzen 9 7950 X) but I still very unclear what to use and when for noisy input. Also how this changes for old B&W (1930s/1940s) and old Technicolor (1950s/1960s).

For instance if I have an old 1930s/1940s black & white movie these can be very grainy and 'more noise than signal' so starting with a 60GB file, running CRF 18 (x265, 10 bit) without SMD will only produce a marginal size reduction (it may actually increase) and even at CRF 24 the output can be around 35GB.

Can anyone point to any threads that give use-cases for SMDegrain as with PD's and Ryushin's I have some 15 SMD scripts to choose from, quite apart from whether I should change the tuning to Grain - should I? I am trying not to have to run each permutation to see what works.

[valnar]

@archiel

Cut one of your sample files to a few minutes using MKVToolnix and run them through a couple choices.

In my experience, sharp, modern HD film grain may benefit from solely using MDegrain; but older B&W SD film would benefit from SMDegrain a bit since the source is probably not that sharp. For x265, I think a CRF 20-21 is fine, unless your particular source is problematic (very dark, etc). YMMV

[rlev11]

So I basically am down to 3 scripts that I use, a light, medium, and strong. I just look at the original and make a determination of which one to use. of course clean source gets light, some grain gets medium , and something with a lot of grain like an old black and white movie gets strong.
For example the 4k disc of 12 angry men. That is very grainy. The original is about 54 gig. Re-encoding it to x265 10 bit with a crf of 18 with my heavy smdegrain script results in a 9.3 gig output and looks really good. These are the scripts I am basically down to:
Light:
#Custom
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\MedianBlur2\MedianBlur2.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=3,thSAD=300,thSADC=150,contrasharp=true,prefilter=1,refinemotion=true)

Medium:
#Custom
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\MedianBlur2\MedianBlur2.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=4,thSAD=400,thSADC=200,contrasharp=true,prefilter=1,refinemotion=true)

Heavy:
#Custom
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\MedianBlur2\MedianBlur2.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=6,thSAD=600,thSADC=300,contrasharp=true,prefilter=2,refinemotion=true)

[archiel]

@valnar @rlev11 Thank you both - looks like I have most of the weekend mapped out!

[Ryushin]

@valnar @rlev11 Thank you both - looks like I have most of the weekend mapped out!

I have a quite a few 4K B&W movies. I use My Heavy script on them.

I've had two 4K movies, The Apartment and Highlander than I actually ran them through RB SMDegrain Heavy twice to get a very clean results. First encode was at CQ08 with SMDegrain Hard, then CQ18 SMDegrain Hard. The second encode cleaned out most of the remaining grain and the results were excellent.

[slalom]

I haven't used a 4C system in too long ago to remember :(
That's like half impulse! :)

[archiel]

I will test over the weekend, but from your experience

Does setting blksize=8 make a material difference to the output quality (I can see that it slows everything down)?

UPDATE: just finished Heavy with blksize=8, took 3 x as long to run, with almost no improvements - next step is to follow Ryushin's advice and run Heavy twice.

For 4k does leaving Prefetch at default (over 12) make any difference to the results (or does it just waste resources on the PC)?

For each of the SMD scripts SetMemoryMax(16384). Would increasing this make any difference?

[rlev11]

I will test over the weekend, but from your experience

Does setting blksize=8 make a material difference to the output quality (I can see that it slows everything down)?
For 4k does leaving Prefetch at default (over 12) make any difference to the results (or does it just waste resources on the PC)?
For each of the SMD scripts SetMemoryMax(16384). Would increasing this make any difference?

I can answer the 4k prefetch question. If doing 4k encodes and avi-synth-prefetch is set over 12 (either by default or hard coded) performance will literally drop off a cliff, like less than half the fps than if you have it set to 12 or below depending on your CPU. Some buffer gets overloaded and just pukes with all the extra bits in the 4k stream. It was discussed a while ago and nothing really came of it as to why. It does not change the "quality" of the encode, just the speed.

Now on 1080p and below encodes it is not a problem, and it can be set to actual physical core count if over 12, and it will perform a small bit better than if set to 12 on those lower resolution encodes.

If you are trying to squeeze every little FPS performance wise, you can create a normal .bat file for the encoding server startup and use on your 7950x 16, and then also create one just for 4k encodes that you set to 12, and just switch between them

[archiel]

I can answer the 4k prefetch question. If doing 4k encodes and avi-synth-prefetch is set over 12 (either by default or hard coded) performance will literally drop off a cliff, like less than half the fps than if you have it set to 12 or below depending on your CPU. Some buffer gets overloaded and just pukes with all the extra bits in the 4k stream. It was discussed a while ago and nothing really came of it as to why. It does not change the "quality" of the encode, just the speed.

Now on 1080p and below encodes it is not a problem, and it can be set to actual physical core count if over 12, and it will perform a small bit better than if set to 12 on those lower resolution encodes.

If you are trying to squeeze every little FPS performance wise, you can create a normal .bat file for the encoding server startup and use on your 7950x 16, and then also create one just for 4k encodes that you set to 12, and just switch between them

I am going to test this overnight with a 41GB 4K animation at CQ18. As I am not using DE and have AviSynthMTPrefetchLimit=0 in Ripbot264.ini, for 4K encodes presumably I can just setup and save the Job, then go back in, open avisynth, Edit Script and in #Prefetch change
video=Prefetch(video,16)
to
video=Prefetch(video,12)

[rlev11]

I always use DE so things are setup different, but that sounds like that should do what you need when not using DE

[Ryushin]

I will test over the weekend, but from your experience

Does setting blksize=8 make a material difference to the output quality (I can see that it slows everything down)?

UPDATE: just finished Heavy with blksize=8, took 3 x as long to run, with almost no improvements - next step is to follow Ryushin's advice and run Heavy twice.

For 4k does leaving Prefetch at default (over 12) make any difference to the results (or does it just waste resources on the PC)?

For each of the SMD scripts SetMemoryMax(16384). Would increasing this make any difference?

Don't use blksize=8 unless you really need it. When I say I'm really picky, I mean it. The great majority of people wouldn't use it. I only use now for those videos that have lots of dark scenes. It was noticeable when I was doing The Untouchables in 4K with the night scene on the bridge. I think I posted videos or screen shots of the problem in this forum.

I almost have gotten to the point where I only use my Medium and Heavy now. Even with most modern films coming out, there is a bit of grain, such as Top Gun Maverick. Light remove most grain, but Medium remove the last of it and it was so clean it was amazing. I can tell how good the degraining is base on the output size. A two hour 4K film will end up being around 4-8GB with good degraining. With SMDegrain I don't seem to loose any textures. MDegrain3, you totally lost textures. Also, some films are so clean, a 2.5 hour film can be 4GB in size. You keep thinking you're loosing something, but I haven't been able to see anything.

If my memory serves me correctly, Avengers Endgame source was so clean, it shrunk down to 4.5GB for a 80GB source at CQ18. When this happens, I change to CQ17 or CQ16 just to be sure.

Then you'll hit sources that have so much detail in them, that even with CQ18, and SMDegrain Medium they will balloon out to 27GB, such as Avatar.

I've come to trust SMDegrain at this point. I zoom into my sources while playing and see the grain, so I can tell then it's gone or not. If the image is stable and no grain, I know it's perfect.

With MDegrain3, I know I'm loosing detail. With SMDegrain, even with heavy, I can't find I'm loosing any detail. If anything, because of the slight sharpness increase, everything looks far better using SMDegrain.

Now, you have those purists, videophiles, that love grain. They love the look of film. For myself, that is poppycock. Grain is a distraction taking me out of the movie instead of putting myself into it. I feel the same about 24fps vs 60fps as well. Gemini Man put you into the movie. So the cleanest the movie can be, the better.

Stop worrying about encoding time (within reason) and go for quality of output.

[Guest]

Well, there's been some interesting discussion going on about SMDegrain, and there are so many different opinions, advice, and even samples of scripts being used (which has proven to be interesting).

rlev11's scripts are quite different to Ryushin's, and mine are different again....each to their own, I guess.

The scripts that are provided in the PD Lite package are very basic, but the full PD biuld has so many, you'd never used most of them.

We have some experienced users that swear by SMDegrain, and some newbies that have yet to really benefit from it, and have very different views on what they want as an end result.

One user, is lucky enough to have a 7950X (which among us is common, I even have one), and ATPIT, another user only has an Intel 4C/8T PC (working on a DE set up), so the settings being suggested for one, will probably be no good to the other.

There are more benefits to running DE, than just being able to use multiple PC's to speed up the process, it's a lot more "tunable", and you can also view most of the different process's being used, and also see the progress of the encodes, etc, etc.

And x265 has so many commandline options, that can speed things up, add DV rpu's, bitrates, levels....the list goes on, and this can impact the process substantially.

[Guest]

I am going to test this overnight with a 41GB 4K animation at CQ18. As I am not using DE and have AviSynthMTPrefetchLimit=0 in Ripbot264.ini, for 4K encodes presumably I can just setup and save the Job, then go back in, open avisynth, Edit Script and in #Prefetch change
video=Prefetch(video,16)
to
video=Prefetch(video,12)

This might work, unless it conflicts with other Prefetch settings in the script...

What you could also do, is create some Custom scripts of your own, say one you would regularly use for 4K, and one for 1080p, and add those prefetch settings, and then all you'd need to do is call that particular script from the "list", no editing.

[archiel]

for 4K encodes presumably I can just setup and save the Job, then go back in, open avisynth, Edit Script and in #Prefetch change
video=Prefetch(video,16)
to
video=Prefetch(video,12)

It didn't work. I encoded the same file twice, with and without the edit - both took the same time and produced the same result. When I looked into the temp directory for the job with Prefetch set to 12, Job#.avs I found
#Prefetch
video=Prefetch(video,16) rather than 12

So that I assume that means either directly editing the job#.avs for 4K encodes or creating 2 sets of SMD scripts (Light, Medium, Heavy) with and without setting Prefetch.

[Guest]

It didn't work. I encoded the same file twice, with and without the edit - both took the same time and produced the same result. When I looked into the temp directory for the job with Prefetch set to 12, Job#.avs I found
#Prefetch
video=Prefetch(video,16) rather than 12

So that I assume that means either directly editing the job#.avs for 4K encodes or creating 2 sets of SMD scripts (Light, Medium, Heavy) with and without setting Prefetch.

Not too surprised, actually, due to that there's already a Prefetch "line" in the script :(

So, you can set it up the way that suits you.

Just thought of something, on the Settings Main page, on the right side, there's "Limit", you could change that from 12 or 16, click Apply, and for the encode will have the Prefetch you're after, so just swap & change as you need.

[archiel]

Don't use blksize=8 unless you really need it.

Noted, thanks

Now, you have those purists, videophiles, that love grain. They love the look of film. For myself, that is poppycock. Grain is a distraction taking me out of the movie instead of putting myself into it. I feel the same about 24fps vs 60fps as well. Gemini Man put you into the movie. So the cleanest the movie can be, the better.

Stop worrying about encoding time (within reason) and go for quality of output.

While I appreciate your perspective, mine is slightly different. I am more concerned with noise, rather than grain. By which I mean I am trying to remove that which the film (or tv) maker did not intend to be there. Sometimes grain is the result of a deliberate choice, whether in regard to the medium used to create the images or what is done in post-processing and I am quite happy with that. What I do not want is the noise introduced by poor transfers, or even good transfers of poor quality source material.

However, and regardless of our differing objectives, I greatly appreciate your input on what can be done to achieve them.

[archiel]

I am getting steadily more and more confused about the 12 thread prefetch limit for 4k.

Running RB as local (not DE)
I tested encoding the same film twice at CQ20, setting video=Prefetch(video,nn) at 12 and 16 directly in avisynth, Edit Script - the 12 setting did not take and I had two identical files almost exactly the same amount of time (within 3 minutes).
I then ran the same encodes again, though at CQ18 and editing video=Prefetch(video,nn) directly in Job#.avs. The times were again virtually identical, the files identical and checking the Job#.avs the prefetch settings were unchanged. The only change i noted was that while running with prefetch = 12 CPU usage was in the 70-75% range and with prefetch=16 this was around 80-90%, peaking at 100%. However all tests I had other stuff running in the background as well.

My next test will be after changing the Limit value in the Settings page, but I cannot set this up until the current encode batch finishes.

Finally I plan to enable DE with prefetch at 12 and see if this runs any faster. :confused:

[archiel]

Can anyone assist with how to re-encode and decomb when the interlace option is greyed-out.

From MediaInfo the file is clearly interlaced, and RB is loading with Frame Rate 50 and showing half duration (1 hour rather than 2).
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 50.275
Frame rate : 50.275 FPS
Original frame rate : 25.000
Original frame rate : 25.000 FPS
FrameRate_Original_Num : 25
FrameRate_Original_Den : 1
Frame count : 375872
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 8
Bit depth : 8 bits
Scan type : Interlaced
Scan type : Interlaced
Scan type, store method : SeparatedFields
ScanType_StoreMethod_FieldsPerBlock : 2
Scan type, store method : Separated fields (2 fields per block)
Scan order : TFF
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.203

[Ryushin]

Can anyone assist with how to re-encode and decomb when the interlace option is greyed-out.

From MediaInfo the file is clearly interlaced, and RB is loading with Frame Rate 50 and showing half duration (1 hour rather than 2).
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 50.275
Frame rate : 50.275 FPS
Original frame rate : 25.000
Original frame rate : 25.000 FPS
FrameRate_Original_Num : 25
FrameRate_Original_Den : 1
Frame count : 375872
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 8
Bit depth : 8 bits
Scan type : Interlaced
Scan type : Interlaced
Scan type, store method : SeparatedFields
ScanType_StoreMethod_FieldsPerBlock : 2
Scan type, store method : Separated fields (2 fields per block)
Scan order : TFF
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.203

I only have a few PAL DVDs at 25ps. I have some Blu-rays at 25fps (Doctor Who and some other BBC shows), dealing with these has always been tricky. Most of the times, RibBot shows the 25fps, and I upconvert to 60fps. I've use handbrake to handle these sometimes and upconvert to 60fps using BOB and under video changing to 60FPS, then using CQ08. Then I take the output and put it into RB.

When RB detects detelecine or doing the de-interlace, it has for the most part, always been superior to Handbrake for the output.

[Guest]

Can anyone assist with how to re-encode and decomb when the interlace option is greyed-out.

I would suggest creating a custom script that does what RB doesn't want to do, in situations like this.

I could send you some script's that should do what you want ?

[archiel]

I would suggest creating a custom script that does what RB doesn't want to do, in situations like this.

I could send you some script's that should do what you want ?

That would be appreciated - I was going to revert to Handbrake - but would prefer to stay with RB if I can.

[Guest]

That would be appreciated - I was going to revert to Handbrake - but would prefer to stay with RB if I can.

I have sent you a PM, and I will send another regarding this, OK.

[archiel]

Try as I might, I cannot find any problem with encoding a 4K (46GB) file running with unlimited threads on a 7950X.

So far i have tried
NO DE
unlimited threads
editing prefetch in the job#.avs file
Setting "Use multiple processing threads = 12" in Settings, Main
With DE
Setting
/port nnnn /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 32 /x265-threads 32

Each encode took (almost exactly) the same time and produced (almost exactly) the same output.

The only thing left to test is under DE what if I remove /avisynth-prefetch-threads 12.

[Guest]

Try as I might, I cannot find any problem with encoding a 4K (46GB) file running with unlimited threads on a 7950X.

So far i have tried
NO DE
unlimited threads
editing prefetch in the job#.avs file
Setting "Use multiple processing threads = 12" in Settings, Main
With DE
Setting
/port nnnn /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 32 /x265-threads 32

Each encode took (almost exactly) the same time and produced (almost exactly) the same output.

The only thing left to test is under DE what if I remove /avisynth-prefetch-threads 12.

Well, like I said, there will be some trial & error, until you find the sweet spot for your setup.

[archiel]

Try as I might, I cannot find any problem with encoding a 4K (46GB) file running with unlimited threads on a 7950X.

So far i have tried
NO DE
unlimited threads
editing prefetch in the job#.avs file
Setting "Use multiple processing threads = 12" in Settings, Main
With DE
Setting
/port nnnn /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 32 /x265-threads 32

Each encode took (almost exactly) the same time and produced (almost exactly) the same output.

I previously noted that the only thing left to test is under DE was 'what if I remove /avisynth-prefetch-threads 12'.

I did, and while initially it to looked to be running faster, it crashed and while it looked as if I could shutdown RB, the only way back in was a reboot and on reboot, both RipBot264.ini and encoder.ini were blank. Retried a couple more times (just in case) - same problem.

So, at least for my single PC setup,

local only (no DE) is just as fast as DE for all encodes.
restricting prefetch makes no difference on a local only setup
restricting prefetch is absolutely necessary for 4k on a DE setup


So until I find a compelling use-case for DE over local, I have turned it off.

In summary, I have reverted to my old setup, but at least I no longer have any 'what if I tried...'s floating around.

[valnar]

So until I find a compelling use-case for DE over local, I have turned it off.

In summary, I have reverted to my old setup, but at least I no longer have any 'what if I tried...'s floating around.

I've found that using DE isn't quite as fast as using Ripbot separately on multiple PC's if you're running through a series. Just divide up the episodes between them. If you're doing a movie and can dedicate a few computers, then yes.

[Atak_Snajpera]

So until I find a compelling use-case for DE over local, I have turned it off.
Local DE may be necessary if you have CPU with high number of cores like Xeons or Threadrippers.

[Guest]

No. I will start some coding tomorrow.

We have an update, ppl :)

v1.27.1
Added: JobWindowDefaultPosition option in ripbot264.ini. Accepted values [center,top,right,bottom,left]
Added: Subtitle file size
Added: Filter list for DEFAULT and FORCED subtitles
Fixed: Disappearing chapters in chapter.txt file
Fixed: UI issues in segments table
Fixed: Cover art not added in batch mode

[Ryushin]

Thanks for the update Atak. You keep updating and maintaining RB, I so much appreciate it.

Next time you happen to want to do some coding, can ask for a batch enhancement.

I've been encountering a big time sink dealing with multiple audio channels in batch mode.

For example, the files I've been creating for local use have two streams, AC3 first and Dolby TrueHD second.

MakeMKV creates the files with the highest quality audio channel first, and the sub (core) channel second.

After adding the files in batch mode, I have to go edit each job, set the core audio to the first channel and the higher quality to the second channel. Waiting for RB to analyze the high quality channels takes 30-90 seconds each time, at least for TrueHD audio. AC3 only takes a couple of seconds.

It would be nice to have up to 3 audio settings since RB can handle three channels. Options would first to choose which audio channel to pull from and then what to do with it.

Thanks again Atak for everything.

[Atak_Snajpera]

Thanks for the update Atak. You keep updating and maintaining RB, I so much appreciate it.

Next time you happen to want to do some coding, can ask for a batch enhancement.

I've been encountering a big time sink dealing with multiple audio channels in batch mode.

For example, the files I've been creating for local use have two streams, AC3 first and Dolby TrueHD second.

MakeMKV creates the files with the highest quality audio channel first, and the sub (core) channel second.

After adding the files in batch mode, I have to go edit each job, set the core audio to the first channel and the higher quality to the second channel. Waiting for RB to analyze the high quality channels takes 30-90 seconds each time, at least for TrueHD audio. AC3 only takes a couple of seconds.

It would be nice to have up to 3 audio settings since RB can handle three channels. Options would first to choose which audio channel to pull from and then what to do with it.

Thanks again Atak for everything.

I will add the same filtering for audio streams next time. No eta though.

[Ryushin]

Well, after the latest update my custom scripts with SMDegrain are no longer working and it won't generate a info.txt file.

https://i.postimg.cc/5YQgTMcT/Custom-Script-Error.png (https://postimg.cc/5YQgTMcT)

The Script:
#Custom
SetCacheMode(1)
SetMemoryMax(16384)
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\MedianBlur2\MedianBlur2.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SMDEGRAIN\SMDegrain.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Zs_RF_Shared\Zs_RF_Shared.avs")
Video=SMDegrain(video,tr=8,thSAD=800,thSADC=400,contrasharp=true,prefilter=2,refinemotion=true)

Not sure what was changed yet. I'm digging into it.

[Ryushin]

Well, after the latest update my custom scripts with SMDegrain are no longer working and it won't generate a info.txt file.

https://i.postimg.cc/5YQgTMcT/Custom-Script-Error.png (https://postimg.cc/5YQgTMcT)

Not sure what was changed yet. I'm digging into it.

I know what the problem is now. I was processing the new True Lies in 4K, and the auto crop set the top to 278 and the bottom to 276. This caused the error, changing both the the top and bottom to 276 removed the error.

I know I've had mismatched top and bottom crop numbers in the past. Not sure what has changed. Either way, it's working now.

[slalom]

Why are you cropping that?

[rlev11]

Anytime I have gotten that "won't generate a info.txt file" error, it is almost always related to cropping or aspect ration being just a bit off of a standard aspect ratio. Like you found, adjusting a crop a pixel or 2 usually fixes it it, doing a resize to a standard aspect ratio works as well. So if an autocrop comes up with a 1:2.394 or something similar and it fails (doesn't always), use the resize drop down and set it to the 2.40 setting and be done with it. Won't really notice a few vertical pixels difference in the output.

I have had this since I started usinf SMdegrain like 2+ years ago, so i don't think it is something new with a recent update. I think I have had 1 or 2 things that no matter how I sized it, SMdegrain would always throw that error. I just did those in Mdegrain3 and moved on.

[Ryushin]

Why are you cropping that?

I crop everything except subtitled movies, which I generate ASS subtitle files and push them into the black bars. Otherwise, I always crop.

[Ryushin]

Anytime I have gotten that "won't generate a info.txt file" error, it is almost always related to cropping or aspect ration being just a bit off of a standard aspect ratio. Like you found, adjusting a crop a pixel or 2 usually fixes it it, doing a resize to a standard aspect ratio works as well. So if an autocrop comes up with a 1:2.394 or something similar and it fails (doesn't always), use the resize drop down and set it to the 2.40 setting and be done with it. Won't really notice a few vertical pixels difference in the output.

I have had this since I started usinf SMdegrain like 2+ years ago, so i don't think it is something new with a recent update. I think I have had 1 or 2 things that no matter how I sized it, SMdegrain would always throw that error. I just did those in Mdegrain3 and moved on.

I don't ever remember having missing info.txt files with cropping. I've had them with broken custom scripts until I got all the parameters correct. Nice thing is doing a preview will usually show me the error.

Good to know it's probably a weird aspect ratio problem. I'll keep a look out for that from now on.

[00-00]

Have been using RipBot for some time with no issues, but over the last few days after using it on a new system I have had a few strange issues. The first is that some encodes complete, apparently succesfully, but when playing back/skipping through the file, the video will freeze at a seemingly random point, but the audio continues playing OK, and from that point if I try and skip forward I just get a black screen and the audio jumps back to the point where the video has frozen, so something's gone wrong with the encode. Rechecking the preview in RipBot doesn't show any apparent errors and I can skip to any point in the file preview with no problems. Also the expected filesize is smaller than I selected, ie I set the output size to 10000 mib and the output (broken) file is 8500 mib. I've checked the log and the only error I see is:

[78.9%] 138863/175933 frames, 33.74 fps, 10224.74 kbps, eta 0:18:18
x264 [warning]: specified frame type is not compatible with max B-frames
x264 [error]: slice=P but 2pass stats say B

I've no idea what this means as I'm used to Ribot just working, but running the encode again seems to fix it.

The other thing is when using the lock file size option, if I set an encode to a certain size say 3600 mib, it completes succesfully, but smaller than expected, in this case it was 3399 mib. I know it's not going to be the exact size I select, and it's not a major issue, but I've noticed that on the old system encodes seemed to be very close to the selected file size and I just wanted to understand what was happening or if something is wrong/broken with my setup.

Hopefully this makes sense! I've only had these issues since moving to a new system and haven't really had any problems before and I've gotten used to RipBot working pretty much flawlessy up till now! :thanks: