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

[StormMeows]

Originally Posted by JKyle

StaxRip does x265 chunk encoding by cutting frames into N chunks (simple arithmetic division of the total number of frames = equal chunking) if Input/Output > Chunks is set to N in x265 Options. But unlike RipBot, each chunk employs separate processes in the SAME CPU in StaxRip.

I don't know how RipBot cuts the frames for DE in different servers, but if it cuts the frames evenly by simple arithmetic division (equal chunking), the only difference b/w StaxRip and RipBot lies in whether different CPUs can be employed (RipBot) or not (StaxRip).

And equal chunking is obviously inferior to scene-aware chunking which cuts frames based on frame similarities via ffmpeg, etc.

If you're interested in scene-aware chunking in x265, you may want to try Av1an. But since it's a CLI app, it has some learning curve, though.

For reference, there was a request to implement scene-aware chunking in StaxRip, but it's put off as of now due to some difficult obstacles at the code level.

Anyway, my apologies for cluttering up this thread with StaxRip topics.

Thanks for the comparison between the two programs! I really appreciate it. It sounds like for x264 8-bit 1080p blu-ray encodes, I am fine using either of these fine programs.

[Deputy Cartman]

Looooong time RipBot264 user but I'm unable to resolve an issue with Temp files and I'm hoping someone here can point me in the right direction.

I just upgraded my ancient i7-3770K desktop, using Windows 10 Enterprise, to a Ryzen 5950X so I'm interested in doing encodes on said desktop. I have had RipBot264 running on a Windows 2019 VM on my ESXi server for quite some time now, Windows Server 2016 before that, that is able to write to and use a Temp\Ripbot264temp directory hosted on a CentOS 8 VM, also on said ESXi server, no problem. I have a lot of VMs running and this 16 core Ryzen 5950X is a beast, hence my desire to shift encodes to my newly-upgraded desktop.

Unfortunately, though I've mapped the Samba share with the same CentOS 8 account credentials as on the Windows Server 2019 VM, when I try to add an encode, it always spits out:

Cannot create file
"W:\Temp\Ripbot264temp\job1\Blu-Ray_structure_getinfo.cmd". The system cannot find the file specified.

I am able to create directories and files on on the mapped network drive in Temp\RipBot264temp without incident.

I do not want to write temp files to my 2 TB NVMe SSD in order to maintain its longevity.

RipBot264.ini reads as follows when it produces the mentioned error.

StoreTempFilesin=W
*truncated*
DefaultOutputPath=W:\

Change StoreTempFilesin to C or AUTO and POOF, no more error.

I am using RipBot264 1.26.1 on both Windows Server 2019 and on Windows 10 Enterprise (21H1). I am pretty confident it has nothing to do with the CentOS 8 Samba shares because SMB3 is the minimum protocol version allowed and even the "WTF were you thinking!?" chmod 777 of the directory does not fix the issue on Windows 10 (21H1).

[Pauly Dunne]

Originally Posted by StormMeows

Thanks for the comparison between the two programs! I really appreciate it. It sounds like for x264 8-bit 1080p blu-ray encodes, I am fine using either of these fine programs.

What you need to do is stop swapping from forum to forum, asking the same basic questions !!!

If you're after SPEED, then the ONLY option IS RipBot, and using the Distributed Encoding option, with your 5950X, it would just plough thru like nothing, as you don't use much filtering.

And if you have other PC's, they can join it, to speed it up even more !!

Until Staxrip implements a simliar DE option, (which doesn't seem to be in their plans any time soon) it WILL be slower !!!

[Pauly Dunne]

Hi Atak,

I can't help but hear about unprecedented rain & flooding in your part of the World....unbelievable damage.

Is this affecting you at all ??

Keep safe.

Cheers

[LigH]

In Germany, mainly the western part (Erftstadt, Wuppertal, etc.). About 160 people dead. The government was warned precisely and conveniently ahead of time; but it didn't pass through to the people. The disaster alarm system broke in the last decades. A siren test day last year failed, and this year it got postponed to next year because they did not get fixed in time.

[Pauly Dunne]

Originally Posted by LigH

In Germany, mainly the western part (Erftstadt, Wuppertal, etc.). About 160 people dead. The government was warned precisely and conveniently ahead of time; but it didn't pass through to the people. The disaster alarm system broke in the last decades. A siren test day last year failed, and this year it got postponed to next year because they did not get fixed in time.

I wasn't sure what you were talking about, until I had a bit more of a look on YT, and now I know that there was some flood early warning system in place....not sure how that would be affective, a bit like forecasting earthquakes, volcanic eruptions, tsunami's, etc

It's generally too late to do much

[Ronski]

Originally Posted by Deputy Cartman

I do not want to write temp files to my 2 TB NVMe SSD in order to maintain its longevity.

I can't help with your network issue, but what NVME drive are you using? How many encodes do you do?

Most 2TB NVME drives have a pretty high TBW rating, so will last an extremely long time. I've recently written a huge amount of data (Chia plots) to various NVME drives, and they've all got a lot of life left. each plot creates around 1.4TB of writes. I've always used an SSD for the temp file and for storing my working files, and made use of the move setting to limit wear, but I don't do a huge amount of encodes.

[Pauly Dunne]

So now that I have got a 5950X, to work along side the 3950X, I have been testing these "so called" AVX & AVX2 optimized x265's...

And sadly I cannot notice a significant difference between any of them, unless I am missing something....

If anyone has an opinion on this, I would be glad to hear it.

I also ran a few tests with a 4 minute test file I have (which unfortunately only uses 3 DE servers)...

So with all the x265 builds I tried, there was only a few seconds difference in the encoding time (start to finish), which was approx 3:00 minutes (on the 5950X),
I tested on the 3950X with ALL the same settings, and it was 15 seconds quicker, due to the fact that the 3950X was to run at 100% on the 3 DE servers,
whereas the 5950X was substantially less, at around 75% +/-, due to the extra "power" the 5950X has, I guess.

And just as a reference, I also ran the 4 minute test file without DE, on the 5950X. and it took 4:11, so that's how much difference DE can make, just on the same PC.

And just as a test, I also ran it on a single E5 2690 v1, and it took 13:11, running at 100% on the 3 DE's.

So just to sum up, I was rather disappointed that the "optimized" x265's were a bit of a let down

[Atak_Snajpera]

Avx optimizations are always automatically used in x265 by default. To see a difference you must explicity disable them via command line.

https://x265.readthedocs.io/en/3.4/c...rmance-options

[Boulder]

The optimization during compiling does not help if the code is already optimized manually (i.e. written in assembly). It will help in cases where there's only pure C code or something like that.

Having said that, the GCC builds of x265 produced by the Media Autobuild Suite were a couple of % faster than any of those other available builds on my 3900X when the Zen2 optimizations were enabled. I've been using MABS to build them ever since.

[Pauly Dunne]

Originally Posted by Atak_Snajpera

Avx optimizations are always automatically used in x265 by default. To see a difference you must explicity disable them via command line.

https://x265.readthedocs.io/en/3.4/c...rmance-options

Interesting...

So to lock it in, you'd use --asm avx, or --asm avx2, and to "kill" them all, it'd be --no-asm

[Pauly Dunne]

Originally Posted by Boulder

The optimization during compiling does not help if the code is already optimized manually (i.e. written in assembly). It will help in cases where there's only pure C code or something like that.

Having said that, the GCC builds of x265 produced by the Media Autobuild Suite were a couple of % faster than any of those other available builds on my 3900X when the Zen2 optimizations were enabled. I've been using MABS to build them ever since.

I tried a couple of DJATOM's Zen optimized builds, didn't notice any difference.

Any suggestions ??, what have you been using, and where can I get my hands on some ???

I've found that 3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/

[Boulder]

Originally Posted by Pauly Dunne

I tried a couple of DJATOM's Zen optimized builds, didn't notice any difference.

Any suggestions ??, what have you been using, and where can I get my hands on some ???

I've found that 3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/

This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.

[Pauly Dunne]

Originally Posted by Boulder

This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.

I just tried to download this, and got this msg

"The file you requested has been deleted"

[Boulder]

Originally Posted by Pauly Dunne

I just tried to download this, and got this msg

"The file you requested has been deleted"

That service seems to allow just one download for non registered uploads.

I've put the zip file here, if it works better:
https://www.4shared.com/s/fNyWQ4RLpiq

[benwaggoner]

Originally Posted by Boulder

This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.

Yeah, you want to be optimizing for YOUR version of Zen, not just Zen generically.

Profile-Guided Optimization may also help if you're trying to squeeze every last bit of performance out of it, particularly if you profile using the settings you'll be using with the final build.

[Pauly Dunne]

Originally Posted by Boulder

That service seems to allow just one download for non registered uploads.

I've put the zip file here, if it works better:
https://www.4shared.com/s/fNyWQ4RLpiq

Thanks for doing that, I use IDM to download stuff, and some sites don't work too well, so that's why I didn't get it on the first attempt.

Is this a "special" build ??

Cheers

[Pauly Dunne]

Originally Posted by Boulder

This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.

OK, Boulder, I have done a fair bit more testing and have some interesting results:-

Oh, and BTW, those parameters don't work under Windows, or at least in RipBot

So, using your x265.exe, (which seems to be 3.5+10-82786fc GCC 10.3) with my test file using --ctu 32, took 2:11, using --ctu 64, took 3:34.

The x265 I am currently using (3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/ ) using --ctu 32, took 2:07, using --ctu 64, took 3:31.

So just the tiniest bit faster....and these were ALL done at Level 5.2 10bit.

Dropping down to Level 4.0 --ctu16 (default), it took the same time, 2:07.

I read somewhere that the GCC 11.1 builds are a little better with Ryzen's.

So using --ctu 32 would yield a much faster encode, but would --ctu 64 look a little better ????

[Boulder]

I tested the two builds and the difference was just one second for 1500 frames so with my scripts and setup it's negligible. Nevertheless, the GCC builds seem best for Zen2 and probably Zen3 as well.
I use CTU 64 for 1080p and above and CTU 32 for below that.

[Pauly Dunne]

Originally Posted by Boulder

I tested the two builds and the difference was just one second for 1500 frames so with my scripts and setup it's negligible. Nevertheless, the GCC builds seem best for Zen2 and probably Zen3 as well.
I use CTU 64 for 1080p and above and CTU 32 for below that.

Thanks for the info, and I might do a test using 32 & 64 on a 4K encode.

Cheers