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

[rlev11]

I've always used a chunk size of 2. The problem with going larger especially with distributed encoding is inevitably your slowest server or both chunks of a server running 2 encoders will end up being the last couple chunks to finish up. Add that to the last chunk sometimes being close to double it's size. An encoding job could end up being 20-30 minutes longer depending on how those last couple of chunks line up.

And that brings up another variable in all of this is total time for an encoding job. Just looking a FPS is only half the story. One could look at 2 similar length jobs and 1 could be significantly faster running 2 encoding windows per server, and the other could be significantly faster running just 1 encoding window per server depending on how things line up and there is no way to tell ahead of time. There is no way to really get around this, it is just the nature of the beast. Eventually I guess it would all even out.

Don't get me wrong, I am really pleased with the performance of the 59 and 79 50's once I get them setup properly. Right now this whole thing of why we have to knock down the 16 core Ryzens is more of an itch I keep scratching. Even though if we do eventually figure out what is going on, I doubt the performance increase would be all that much more than what we are getting now. It's more a curiosity now.

[guest]

I've always used a chunk size of 2. The problem with going larger especially with distributed encoding is inevitably your slowest server or both chunks of a server running 2 encoders will end up being the last couple chunks to finish up. Add that to the last chunk sometimes being close to double it's size. An encoding job could end up being 20-30 minutes longer depending on how those last couple of chunks line up.

Yes, there's that problem, and that has been debated a bit over the years, that why the last chunk had to be bigger, instead of possibly very small.

But one possible advantage of less chunks is the "waiting time" between chunks, sometimes it can take a reasonable amount of time for the processing to start.

And that brings up another variable in all of this is total time for an encoding job. Just looking a FPS is only half the story. One could look at 2 similar length jobs and 1 could be significantly faster running 2 encoding windows per server, and the other could be significantly faster running just 1 encoding window per server depending on how things line up and there is no way to tell ahead of time. There is no way to really get around this, it is just the nature of the beast. Eventually I guess it would all even out.

Absolutely, you don't know what you're in for, when EVERY job.

Don't get me wrong, I am really pleased with the performance of the 59 and 79 50's once I get them setup properly. Right now this whole thing of why we have to knock down the 16 core Ryzens is more of an itch I keep scratching. Even though if we do eventually figure out what is going on, I doubt the performance increase would be all that much more than what we are getting now. It's more a curiosity now.

Unfortunately my 5950X is down, as I used some "important" items to build the 13900KF, and it won't be back online 'til at least mid to late February :(, but I do have another "little" 16 core, in the 3950X.

I wonder if there are many users out there that have Threadripper's doing RB, they would have to have interesting problems with 64 cores etc....

[Boulder]

Tried earlier with SetMemoryMax(8192) along with the cache setting and saw no difference. My only question with that is where would I see the memory being used by avisynth.

If ffmpeg is the one doing the frameserving (and possibly encoding too), its memory consumption is the one to look at. I always use the Details tab in Task Manager to see things better.

[guest]

If ffmpeg is the one doing the frameserving (and possibly encoding too), its memory consumption is the one to look at. I always use the Details tab in Task Manager to see things better.

Hi Boulder, thanks for your help...

I just checked 2 of my PC's, (that were currently encoding) and they are using between 5,200,000 & 5,450,000 K.

[Ryushin]

It's my theory that the avisynth threads is waiting on frames when using SMDegrain/MDegrain. During my testing I watched the CPU performance during each increase in threading of avisynth threads. As long as I left a bit of headroom for the CPU to bounce between 85-100% usage everything worked great. But as soon as I increased the avisynth threads to high, the CPU went to and stayed at a 100%, everything drastically slowed down. And yea, this seem more pertaining to 4K content and not 1080p as matching 16 avisynth threads to 16 x264/x265 with 1080p was humming right along. So it's a bit of a balancing act to feed two different processes that can process data at different rates that rely on each other.

[guest]

It's my theory that the avisynth threads is waiting on frames when using SMDegrain/MDegrain. During my testing I watched the CPU performance during each increase in threading of avisynth threads. As long as I left a bit of headroom for the CPU to bounce between 85-100% usage everything worked great. But as soon as I increased the avisynth threads to high, the CPU went to and stayed at a 100%, everything drastically slowed down. And yea, this seem more pertaining to 4K content and not 1080p as matching 16 avisynth threads to 16 x264/x265 with 1080p was humming right along. So it's a bit of a balancing act to feed two different processes that can process data at different rates that rely on each other.

Glad you've joined the discussion, again :)

So, interesting you say that, I did a run this afternoon, upscaling a 1080p to 4K, using a deep_size script, as well as a tr=4 strength filter, and I also changed it to 3 minute chunks, (the last chunk was only about 800 frames bigger) and ONLY 1 DE server per PC, had 4 PC's going, and the speeds were really good, and like you said, with the CPU usage bouncing between 80% & 100% or so, things were running sweet :)

The 7950X & the 13900KF were swapping fastest FPS's all the way thru, they are SO, SO close to each other.

I have changed my encoder command lines a fair bit, they are a little different on each PC, and for now, seems to be working the best.

[Atak_Snajpera]

My last idea. Have you tried changing process priority once encoding is running for ffmpeg.exe from default to for example HIGH. x265.exe keep as is. You can use Process Hacker/Explorer for that.

[guest]

My last idea. Have you tried changing process priority once encoding is running for ffmpeg.exe from default to for example HIGH. x265.exe keep as is. You can use Process Hacker/Explorer for that.

I haven't, but wouldn't you have to change this every time you start RB ??

What about the encoder "priority" setting in RB, would that make any difference ??

Also, Process Hacker has been superceded...

https://www.systeminformer.com/

UPDATE:- You CAN set this to a HIGH priority with System Informer (Process Hacker), but to set it permanently, you need to have the app set up as Administrator (install it with Admin rights)

[apol847]

Sorry for delay. I completely forgot about that.
https://www.mediafire.com/file/r2hmt95asxynruz/DetectBorders_Delphi7_Source.7z/file

No problem. I was also busy. Thank you. Let's see if I get this converted to Linux.

[guest]

Atak, I have a simple request that will make it a lot easier for us "old fart's" that have poor eyesight, and can't be bothered wearing their glasses.

Could you please change the colour of the text in most windows (Job Queue, Encoder Server, etc) from what seems to be a grey / dark grey, to just plain black, especially the Server name in Encoder Client.

[archiel]

If I use the resize option in batch, it is failing on videos with a 2:1 ratio (becoming more common on streaming platforms) and will interpret as 1.85:1. The same if I choose resize via the AviSynth options.

I know I can always run a batch file to fix after the conversion, but is there somewhere (and where do I find it) to add 2:1 as a recognised aspect ratio?

Thanks, Archiel

[guest]

If I use the resize option in batch, it is failing on videos with a 2:1 ratio (becoming more common on streaming platforms) and will interpret as 1.85:1. The same if I choose resize via the AviSynth options.

I know I can always run a batch file to fix after the conversion, but is there somewhere (and where do I find it) to add 2:1 as a recognised aspect ratio?

Thanks, Archiel

That's an odd size, what is an example of a video of that ratio ??

So, here's a suggestion, load the offending video "normally", and go into the Avisynth settings and adjust & test different ratio's using the preview, until you've got it the way you want, then copy the script to notepad, and save it as a Custom Script, then you can "call" it within batch. (If it's in the Custom folder)

#Custom
LoadPlugin("D:\RipBot264\Tools\AviSynth plugins\ColorMatrix\ColorMatrix64.dll")
LoadPlugin("D:\RipBot264\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline64ResizeMT(video,3840,2076)

[rlev11]

That's an odd size, what is an example of a video of that ratio ??

So, here's a suggestion, load the offending video "normally", and go into the Avisynth settings and adjust & test different ratio's using the preview, until you've got it the way you want, then copy the script to notepad, and save it as a Custom Script, then you can "call" it within batch. (If it's in the Custom folder)

#Custom
LoadPlugin("D:\RipBot264\Tools\AviSynth plugins\ColorMatrix\ColorMatrix64.dll")
LoadPlugin("D:\RipBot264\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline64ResizeMT(video,3840,2076)


Agree with TDS here. Anytime that I have had to batch something with with a resize, I always make a custom script for that ratio (and level of degraining). I am assuming that you are downsizing from 4k to 1080p (doesn't really matter, the process is the same).

Load the video up as a single job. go into avisynth, do an auto-crop, it will tell you the aspect ratio. for your case being a 2:1 aspect. in the resize do a custom, put in 1920x960 or 1280x640, then do whatever else you want to do to that batch. before you then hit OK, click on "show video script" and copy everything in there. go to the tools\avisynth plugins\scripts\custom folder open up notepad and paste that in. then do a file-save as, change the save as type to all files *.*. put in the filename you want with a .avs extension.

to do the batch then, add in the files you want to use that same script on, click "autocrop" then choose your new custom script in the dropdown and hit start.

I have a bunch of custom scripts I use depending on the aspect ratio and degraining for batch processing. I just load up the videos, choose the correct script and go.

[guest]

Agree with TDS here. Anytime that I have had to batch something with with a resize, I always make a custom script for that ratio (and level of degraining). I am assuming that you are downsizing from 4k to 1080p (doesn't really matter, the process is the same).

Load the video up as a single job. go into avisynth, do an auto-crop, it will tell you the aspect ratio. for your case being a 2:1 aspect. in the resize do a custom, put in 1920x960 or 1280x640, then do whatever else you want to do to that batch. before you then hit OK, click on "show video script" and copy everything in there. go to the tools\avisynth plugins\scripts\custom folder open up notepad and paste that in. then do a file-save as, change the save as type to all files *.*. put in the filename you want with a .avs extension.

to do the batch then, add in the files you want to use that same script on, click "autocrop" then choose your new custom script in the dropdown and hit start.

I have a bunch of custom scripts I use depending on the aspect ratio and degraining for batch processing. I just load up the videos, choose the correct script and go.

Thanks for the backup, "R" :cool:

Yes, once you've figured out how to create & save Custom scripts, "the skies the limit", and one VERY handy extra about that is you can now use with in batch, as batch is rather limited, unfortunately.

[archiel]

Thank you TDS and rlev11 this gives me something to work on as an interim solution.

FWIW 2:1 is also known as Univisium and has been around as a option for both movies and tv since the late 1990s.

What I would really like to understand what is causing the mistranslation from 2:1 to 1.85:1 and whether it can be fixed. Ideally I want to be able to take a mixed bag of avc videos (different sizes and ratios) and convert them to hevc with a fairly standard size (e.g Auto Height: 1280). While this works fine for more common formats, it fails on 2:1, so these need to be identified separately and either run through a custom script in advance or re-sized afterwards. I am also curious as to how the Auto Height option works and whether there could also be an Auto Width version.

[guest]

Thank you TDS and rlev11 this gives me something to work on as an interim solution.

FWIW 2:1 is also known as Univisium and has been around as a option for both movies and tv since the late 1990s.

What I would really like to understand what is causing the mistranslation from 2:1 to 1.85:1 and whether it can be fixed. Ideally I want to be able to take a mixed bag of avc videos (different sizes and ratios) and convert them to hevc with a fairly standard size (e.g Auto Height: 1280). While this works fine for more common formats, it fails on 2:1, so these need to be identified separately and either run through a custom script in advance or re-sized afterwards. I am also curious as to how the Auto Height option works and whether there could also be an Auto Width version.

Is there any chance that you could upload a sample or full episode of one of these 2:1 clips ???

I don't think I have had anything like this, some OLD DVD type TV episodes can have a fussy resizing issue.

There is a filter/script that can auto resize clips to a preset width, and auto calculates the height, called "Deep Resize", but it can't be used with standard RipBot.

You could also check this info out, and see if you can do something with it ...

http://avisynth.nl/index.php/SimpleResize

[rlev11]

Seems like some of the new streaming series are using that 2:1 aspect ratio. I know 1883,For All Mankind, and The Right Stuff used it. I saw that The Santa Clauses series used an oddball 2.2:1 aspect which I don;t remember seeing before

[guest]

Seems like some of the new streaming series are using that 2:1 aspect ratio. I know 1883,For All Mankind, and The Right Stuff used it. I saw that The Santa Clauses series used an oddball 2.2:1 aspect which I don;t remember seeing before

I'll have to see if I can find an episode or two of them, thanks for that ;)

Edit:- 1883 is 1920 x 960.....

[archiel]

While we can use custom scripts to pass the correct aspect ratio, the core question seems to be around where Ripbot264 is deriving and storing the Aspect Ratio in the first place and I am guessing that this may be a question for Atak. The Aspect Ratio is only applied once Resize is called as both the mkvinfo.txt and {filename}.lwi show the correct source dimensions. I am assuming that if this could be corrected (ideal) and/or exposed and overridden then Resize would be able use the correct ratio when calculating the inputs for Spline.

[guest]

While we can use custom scripts to pass the correct aspect ratio, the core question seems to be around where Ripbot264 is deriving and storing the Aspect Ratio in the first place and I am guessing that this may be a question for Atak. The Aspect Ratio is only applied once Resize is called as both the mkvinfo.txt and {filename}.lwi show the correct source dimensions. I am assuming that if this could be corrected (ideal) and/or exposed and overridden then Resize would be able use the correct ratio when calculating the inputs for Spline.

Yes, at it might be the only option, if you haven't noticed, Atak doesn't seem to be doing much with his creation, of late, so any fixes, may not come, but we live in hope.

Having said that, it maybe an Avisynth "thing", and Atak has NO control over that !!!!

EDIT:- I've been informed that this is NOT an Avisynth issue !!

So, I got me an episode or "1883", (which is this 2:1 ratio, 1920 x 960) and indeed, when loaded into RB, and you set it to 1280 x 720, it displays @ 1280 x 692, and setting @ 1920 x 1080, it displays @ 1920 x 1038.

And, as expected, Custom (Auto Height) in batch does the exact same thing...if there was a "manual" Custom setting in batch, then that would solve the whole problem !!!!

What to do :confused::confused::confused:

[guest]

While we can use custom scripts to pass the correct aspect ratio, the core question seems to be around where Ripbot264 is deriving and storing the Aspect Ratio in the first place and I am guessing that this may be a question for Atak. The Aspect Ratio is only applied once Resize is called as both the mkvinfo.txt and {filename}.lwi show the correct source dimensions. I am assuming that if this could be corrected (ideal) and/or exposed and overridden then Resize would be able use the correct ratio when calculating the inputs for Spline.

We've had an autoupdate today (yesterday), that has corrected this ratio issue.

So, Core (1.26.3), Encoding Client (1.18.2) & Encoding Server (1.18.1) have had an update, all are now at 11/02/23.

And it also appears that my request for darker text in Encoding Client & Encoding Server has been approved & accepted :) (my eyes thankyou)

:thanks:

[rlev11]

Yep, paused a batch encode, then restarted everything and the update showed up. The darker font color is very nice indeed, Thanks Atak!

[archiel]

We've had an autoupdate today (yesterday), that has corrected this ratio issue.

So, Core (1.26.3), Encoding Client (1.18.2) & Encoding Server (1.18.1) have had an update, all are now at 11/02/23.

And it also appears that my request for darker text in Encoding Client & Encoding Server has been approved & accepted :) (my eyes thankyou)

:thanks:

Did you test this? I ask because I have also had the update, but when running a batch (auto-height) against 2.00:1 I am still getting an 1.85:1 ratio. The same if I just load the file in Add and go to resize, I either have 1.85 or custom

In case it was something odd in my Ripbot folder, I deleted it, re-downloaded, configured and upgraded, but still1.85:1.

What should I try next - running Windows 11 Pro 22H2.

[guest]

Did you test this? I ask because I have also had the update, but when running a batch (auto-height) against 2.00:1 I am still getting an 1.85:1 ratio. The same if I just load the file in Add and go to resize, I either have 1.85 or custom

In case it was something odd in my Ripbot folder, I deleted it, re-downloaded, configured and upgraded, but still1.85:1.

What should I try next - running Windows 11 Pro 22H2.

I did test it, and it seemed to work alright for me on the clip I had.

I'm also running 22H2, but I'm happy to test it again and get back to you, later.

[guest]

As Atak has been so kind as to provide some nice little updates to his app, recently, I thought it was time for this :-

https://www.mediafire.com/file/rj8i9eycmsktxgu/RipBot264v1.26.3+(virgin+13-02-23).7z/file

For those users that want a clean install of the very latest build provided by Atak, without having to start from scratch with v1.26.0, and then update it.

ALL updates have been integrated, but this also includes a copy of ALL the current updates from v1.26.0 (in a separate folder)

All you need to do is keep your RipBot264.ini & EncodingClient.ini from your working/current version.

Enjoy :cool:

[guest]

And while I'm here, I know it's been a while since I posted any of my custom builds.

Rest assured that I have been busy updating both the Lite & full PD builds, and they are nearly ready for release...just a lot of testing of all the new filters & scripts.

Too many changes to keep track of.

I have to add, that I am shocked that in the last couple of days there has been over 40 downloads of the currently available "full" build from MediaFire :eek:

Cheers.

[guest]

Did you test this? I ask because I have also had the update, but when running a batch (auto-height) against 2.00:1 I am still getting an 1.85:1 ratio. The same if I just load the file in Add and go to resize, I either have 1.85 or custom

In case it was something odd in my Ripbot folder, I deleted it, re-downloaded, configured and upgraded, but still1.85:1.

What should I try next - running Windows 11 Pro 22H2.

Hi archiel

As I said, I was going to test for you:-

This is importing that 1920 x 960 clip of "1883" TV series:-

Below is what is displayed in the Avisynth "Show Video Script" window

Direct adding this as a job:-

#Upscale
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\ColorMatrix\ColorMatrix64.dll")
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline36ResizeMT(video,1920,960)

Direct adding this as a job:-

#Downscale
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\ColorMatrix\ColorMatrix64.dll")
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline36ResizeMT(video,1280,640)

Direct adding this as a batch job @ 1280 x 720:-

#Downscale
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\ColorMatrix\ColorMatrix64.dll")
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline36ResizeMT(video,1280,640)

Direct adding this as a batch job @ Auto height (1280):-

#Downscale
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\ColorMatrix\ColorMatrix64.dll")
LoadPlugin("C:\RipBot264_PD (01-02-23)\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline36ResizeMT(video,1280,640)

Direct adding this as a batch job @ 1280 x 720, using the very latest standard RipBot:-

#Downscale
LoadPlugin("F:\RipBot264v1.26.3\Tools\AviSynth plugins\ColorMatrix\ColorMatrix64.dll")
LoadPlugin("F:\RipBot264v1.26.3\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline36ResizeMT(video,1280,640)

Atak has made some interesting "under the hood" changes for this :)

The only thing I would change is Spline36ResizeMT to Spline64ResizeMT..:sly:

This should also allow you to add any size clip, (in Batch) and it will "keep" the correct ratio, from now on. NICE.

[archiel]

The only thing I would change is Spline36ResizeMT to Spline64ResizeMT..:sly:

This should also allow you to add any size clip, (in Batch) and it will "keep" the correct ratio, from now on. NICE.

Thanks for the results, I need to do do some more testing this evening. In regard to changing Spline32ResizeMT to Spline64ResizeMT, is this something that can be done globally, or were you suggesting it as an option?

[guest]

Thanks for the results, I need to do do some more testing this evening. In regard to changing Spline32ResizeMT to Spline64ResizeMT, is this something that can be done globally, or were you suggesting it as an option?

You're welcome, and I hope you get it working.

No, this is not a global option, it would have to be done on a per job basis, unless again, you created your own scripts.

It would be nice if it was an option, OR changed by default, as I've read that 64 IS better than 36.

[Atak_Snajpera]

Because We all know that higher number is better... Right?

[guest]

Because We all know that higher number is better... Right?

Well, official documentation says so...

http://avisynth.nl/index.php/Resize#Spline_based_resizers

Spline64Resize may be the most accurate of the Resize filters.

Spline16Resize is sharper and rings just a bit (which may be desirable with soft sources),
and looks pleasing to the eye when enlarging or reducing in moderate amounts.

Spline36Resize is somewhere in between the other two.

[Atak_Snajpera]

Do some real tests first. Spline64Resize for example is ~20% slower than Spline36Resize without any noticeable by humans difference.
Like you mentioned Spline36Resize is a good compromise between speed and overall quality of scaling. Do not expect miracles using spline64. You won't get extra details like with some AI powered stuff.

[archiel]

Problem solved, for some reason Updater did not update RipBot264.exe. Second clean install and now 2.00:1 is working

[rlev11]

All I know is I have done a bunch of downsizing of 4k to 1080 for a friend of mine with "I guess" Spline36Resize, never paid attention to that, and I have always had great results. Everything looks fine to me . I don't use ripbot to upscale anything, If I need to upscale 480p stuff I run that through Topaz Video Enhance AI before I convert back to x265.

[guest]

I thought it was time to make an updated build of this, for those who use Atak's RipBot, and would like the latest available for the main components.

Moved, and updated.

[Glarioo]

I thought it was time to make an updated build of this, for those who use Atak's RipBot, and would like the latest available for the main components.

https://www.mediafire.com/file/9sktobrp6k23yww/update+package+for+RipBot264+(14-02-23).7z/file

Thank you, Pauly!

[guest]

Atak, as you well know, several years ago you made the decision to change the default video decoder from FFMS2 to the then fairly new Lsmash, mainly for frame accuracy, I believe.

But there is no option (other than to do it manually in the .ini file), to change this back to FFMS2.

I'm sure it wouldn't be too difficult for you to re-instate this as a user option, so at least they had an easy choice.

There have been several FFMS2 updates recently, so maybe update it in RB at the same time :o

https://forum.doom9.org/showthread.php?p=1983002#post1983002

There have also been some new updates for avsresize as well...

https://forum.doom9.org/showthread.php?p=1982991#post1982991

But, as always, this is entirely up to you, so please consider.

:thanks:

[guest]

Do some real tests first. Spline64Resize for example is ~20% slower than Spline36Resize without any noticeable by humans difference.
Like you mentioned Spline36Resize is a good compromise between speed and overall quality of scaling. Do not expect miracles using spline64. You won't get extra details like with some AI powered stuff.

Just thought I'd report back with some results:-

A 5 minute 1080p clip @ Spline32 took 3:28..size was 126,016Kb

Same 5 min clip @ Spline64 took 4:48. and was 125,935Kb

Couldn't tell any difference on 27" 4K monitor, but maybe on 4K TV :rolleyes:

Have started using Topaz Video Enhance AI :o

[Atak_Snajpera]

Atak, as you well know, several years ago you made the decision to change the default video decoder from FFMS2 to the then fairly new Lsmash, mainly for frame accuracy, I believe.

But there is no option (other than to do it manually in the .ini file), to change this back to FFMS2.

I'm sure it wouldn't be too difficult for you to re-instate this as a user option, so at least they had an easy choice.

There have been several FFMS2 updates recently, so maybe update it in RB at the same time :o

https://forum.doom9.org/showthread.php?p=1983002#post1983002

There have also been some new updates for avsresize as well...

https://forum.doom9.org/showthread.php?p=1982991#post1982991

But, as always, this is entirely up to you, so please consider.

:thanks:

FFMS2 after all those years still has the same problems. Corrupted frames and frames returned in wrong order

https://i.postimg.cc/Cxk5v1G5/seek.png

https://i.postimg.cc/PqHx0jy4/seek2.png

Do you really want that kind of problems after encoding in distributed encoding mode?

[AMED]

I'm trying to use Ripbot264 on a Dell Poweredge R510 and it seems to be stuck opening after I have installed the OpenCL runtimes for the Xeon CPUs. The OpenCLinfo.cmd step seems to keep dumping info in to OpenCLinfo.txt and doesn't seem to finish (been waiting 30mins). The OpenCLinfo.txt file is currently 72MB in size and still increasing.

Platform 0.
Name : Intel(R) CPU Runtime for OpenCL(TM) Applications
Vendor : Intel(R) Corporation
Version : OpenCL 2.1 WINDOWS
Profile : FULL_PROFILE
Extensions : cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_dx9_media_sharing cl_intel_dx9_media_sharing cl_khr_d3d11_sharing cl_khr_gl_sharing cl_khr_fp64 cl_khr_image2d_from_buffer cl_intel_vec_len_hint

0.0 Device name :
Hardware version :
Software version :
OpenCL C version :
Compute units : 0

......................................
Then lots of empty entries.
......................................

0.555005 Device name :
Hardware version :
Software version :
OpenCL C version :
Compute units : 0

0.555006 Device name :
Hardware version :
Software version :
OpenCL C version :
Compute units :

I think I've found a workaround. I made a copy of OpenCLinfo.cmd and edited it like below, ran the script and then changed OpenCLinfo.txt to read only. now no more delay opening Ripbot264
"D:\Storage\RipBot264v1.26.3\tools\OpenCLinfo\OpenCLinfo.exe" /cpu >> "D:\Storage\RipBot264v1.26.3\tools\OpenCLinfo.txt"

[guest]

FFMS2 after all those years still has the same problems. Corrupted frames and frames returned in wrong order

Do you really want that kind of problems after encoding in distributed encoding mode?

Thanks for the detailed reply, but those test files are from pretty old movies, is this very current testing ??

I have been using FFMS2 & DE for a couple of weeks, and I haven't noticed any processing or playback problems.

But if you think it's mainly a problem for DE, I'm sure there are MANY users who can't or don't use DE.

NOTE:- and for you users that aren't aware, Distributed Encoding CAN be used on a single pc !!!, and there are benefits of doing so !!

[guest]

I'm trying to use Ripbot264 on a Dell Poweredge R510 and it seems to be stuck opening after I have installed the OpenCL runtimes for the Xeon CPUs. The OpenCLinfo.cmd step seems to keep dumping info in to OpenCLinfo.txt and doesn't seem to finish (been waiting 30mins). The OpenCLinfo.txt file is currently 72MB in size and still increasing.

I think I've found a workaround. I made a copy of OpenCLinfo.cmd and edited it like below, ran the script and then changed OpenCLinfo.txt to read only. now no more delay opening Ripbot264
"D:\Storage\RipBot264v1.26.3\tools\OpenCLinfo\OpenCLinfo.exe" /cpu >> "D:\Storage\RipBot264v1.26.3\tools\OpenCLinfo.txt"

It seems that you are, or have been a long term Staxrip user, so welcome here :)

So, it might be an idea to add a basic AMD or nVidia GPU to use OpenCL better.

But if you've found a workaround, that might be all it needs.

I have several Dell & SMC server's and haven't had too much success with Intel OpenCL stuff, so I have just added a GPU.

Good Luck.

[LigH]

:eek: Page 1000, wow... :cool:

[Atak_Snajpera]

Thanks for the detailed reply, but those test files are from pretty old movies, is this very current testing ??

I have been using FFMS2 & DE for a couple of weeks, and I haven't noticed any processing or playback problems.

But if you think it's mainly a problem for DE, I'm sure there are MANY users who can't or don't use DE.

NOTE:- and for you users that aren't aware, Distributed Encoding CAN be used on a single pc !!!, and there are benefits of doing so !!

Because You are not using FFMS2 in Distributed encoding mode.
Just check 1.avs file in Chunks folder.

[guest]

Because You are not using FFMS2 in Distributed encoding mode.
Just check 1.avs file in Chunks folder.

So you're saying that despite decoding with FFMS2, DE is using Lsmash :confused:

It also shows in the video script.

I will check that tomorrow. DONE !!

EDIT:- I have checked 1.avs in the Chunks folder, and this is what it shows :-

#VideoSource
LoadPlugin("\\RYZEN-9-7950X\RipBot264temp\Tools\AviSynth plugins\ffms\ffms_latest\x64\ffms2.dll")
video=FFVideoSource("\\RYZEN-9-7950X\RipBot264temp\job1\video.mkv",threads=0,cachefile="\\RYZEN-9-7950X\RipBot264temp\job1\video.mkv.ffindex")

I'm going to find your "SeekTester", and do some tests myself !!!

[Ryushin]

FFMS2 after all those years still has the same problems. Corrupted frames and frames returned in wrong order

Do you really want that kind of problems after encoding in distributed encoding mode?

And actually this is very important for Dolby Vision. The encoded frame count has to be the same as the source frame count.

[guest]

Like I said, I was going to do some tests of my own, and here are the results !!

Nothing is perfect, it seems :(

Removed screen shot, as it has been copied in Atak's reply, below.

That's just a bit too random IMO.

AFAIC, if you don't have any encoding & playback problems, who gives a toss about "test's".

[guest]

Hey guy's,

I have 2 new re-hashed builds for you to try.

If you want a simpler experience, with a few Custom SMDegrain scripts ready to go, then the "Lite" build will be for you.

https://forum.doom9.org/showthread.php?p=1983764#post1983764

If you what to boggle your mind with almost endless possibilities, then the full build is for you.

It's only limited by your imagination, experience & requirements.

There are some very exciting new filters & scripts to explore.

https://forum.doom9.org/showthread.php?p=1983764#post1983764

Not sure what else to say, the ppl that already use these builds, (and I know there's 100's of you), will know what to do.

Newbies just need to unpack the .7z, do not rename the extracted folder, and put it where you want (preferably in the root of C:\ drive), read the instructions & install everything, and it should be up and running in no time.

Set your .ini files or use you existing files.

Good luck.

[MCFish]

Hey guy's,

I have 2 new re-hashed builds for you to try.

Thx mr. dunne

[Atak_Snajpera]

Like I said, I was going to do some tests of my own, and here are the results !!

Nothing is perfect, it seems :(

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

That's just a bit too random IMO.

AFAIC, if you don't have any encoding & playback problems, who gives a toss about "test's".

With FFMS2 YOU WILL DEFINETELY have problems at split point in DE mode!
Trust me! I've been there and I was extremely frustrated with FFMS2 until I switched to LSmash. All my problems were gone when I dumped FFM2S! Older users of DE mode can testify how buggy was FFMS2. Corrupted frame when chunk starts, duplicated frames at chunks start and so on...

Missing frame means that frame for some reason was not extracted for testing. Maybe ffmpeg.exe crashed... Maybe you ran out of memory because UHD consumes a lot especially with 32 thread CPU! On my 16 thread CPU memory consumption reaches 18 GiB!
Focus on CORRUPTED FRAME ERROR and FRAME INSERTED ERROR