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

[excellentswordfight]

Originally Posted by Pauly Dunne

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 ????

Look at your CPU utilization and you will probably find that decreasing the maximum CU size will increase the potential for higher multi threaded load. The resolution you are encoding at and the number of threads you have available will determine how much impact this will have. Also note that it might be worth changing the merange value to accommodate for this change. With a high thread CPU like 5950X you will have a hard time saturating 32 threads for 1080p and bellow for single instance encoding without lowering the CU size, hence the speed increase.

I have a vague recollection that the devs posted some tests showing that it does effect encoding output somewhat hence why they stick to 64 even for lower res (for UHD you probably always wanna stick to 64). But I'm pretty sure its rather negatable, for high core count systems its probably worth the trade off.

[Pauly Dunne]

Originally Posted by excellentswordfight

Look at your CPU utilization and you will probably find that decreasing the maximum CU size will increase the potential for higher multi threaded load. The resolution you are encoding at and the number of threads you have available will determine how much impact this will have. Also note that it might be worth changing the merange value to accommodate for this change. With a high thread CPU like 5950X you will have a hard time saturating 32 threads for 1080p and bellow for single instance encoding without lowering the CU size, hence the speed increase.

I have a vague recollection that the devs posted some tests showing that it does effect encoding output somewhat hence why they stick to 64 even for lower res (for UHD you probably always wanna stick to 64). But I'm pretty sure its rather negatable, for high core count systems its probably worth the trade off.

Interesting....and it's early days for me and the 5950X, haven't really done too much with it yet, done a bit more with the 3950X, but I think the 5950X is SO much better

I haven't done too much in the way of "tuning" x265, and I also don't know what merange runs at, within RipBot...I thought I saw a reference, showing it @ 9, but apparently the "default" setting is 57.

https://x265.readthedocs.io/en/stable/presets.html

So some testing is on the cards, as I have a LOT to do, and a short time to do it.

[excellentswordfight]

Originally Posted by Pauly Dunne

Interesting....and it's early days for me and the 5950X, haven't really done too much with it yet, done a bit more with the 3950X, but I think the 5950X is SO much better

I haven't done too much in the way of "tuning" x265, and I also don't know what merange runs at, within RipBot...I thought I saw a reference, showing it @ 9, but apparently the "default" setting is 57.

https://x265.readthedocs.io/en/stable/presets.html

So some testing is on the cards, as I have a LOT to do, and a short time to do it.

"Motion search range. Default 57

The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames."

https://x265.readthedocs.io/en/stable/cli.html

So for 1080p and lower you might wanna try --ctu 32 --merange 26 if you use preset slow or lower, for UHD just stick with default.

[Pauly Dunne]

Originally Posted by excellentswordfight

"Motion search range. Default 57

The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames."

https://x265.readthedocs.io/en/stable/cli.html

So for 1080p and lower you might wanna try --ctu 32 --merange 26 if you use preset slow or lower, for UHD just stick with default.

Nice, not too concerned about 1080p or lower all that much, but currently I'm doing a lot of DVD res stuff, old TV series, DVD rips etc.

But the main project is getting a LOT of 4K stuff done, it's just such a shame that it takes so long....if I could get a encode done in a day (6 - 8 hours, won't let it run overnight !!!!), that would be awesome.

So what would you recommend for nice 4K results & speed ??

Do you use RipBot ??

[Ripmann]

A quick and easy feature request for consideration:

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).

[Pauly Dunne]

Originally Posted by Ripmann

A quick and easy feature request for consideration:

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).

I'm pretty sure that this same question was asked not too long ago..

That copy option is only available for certain file types, eg:- .ts, ,m2ts, etc. .mp4 & .mkv don't.

[ReinerSchweinlin]

Originally Posted by Ripmann

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).

Yes, I asked that some time ago, too.

[chainring]

Snip...

Originally Posted by Pauly Dunne

So what would you recommend for nice 4K results & speed ??

Back some time ago, I had the same dilemma. I don't recall which thread it was in, but I asked benwaggoner and Blue_Misfit about resizing 4K content down to 2560 x X since the majority of 4K releases had been rendered at DCI 2K. I figured 2560 was a happy medium between 4K (3840) and DCI 2K (2048). Consensus was it'd be a good idea as long as my playback device could handle the resolution.

All the content I have is played back through Nvidia Shields and I have zero problems. I also play those same movies on a Samsung Tab S6 (OLED screen) via Kodi and it has no problems, either.

Anything 4K with HDR, gets the following treatment:
Resized to 2560 x X
x265 10 bit
--hdr10 --hdr10-opt
Preset Medium

Flavor to taste with:
I start with CQ16 and adjust upwards if file size gets out of control.
Denoise with MDegrain and adjust to grain content. Most of the time, MDegrain2 is the highest I go.

I've been overall very satisfied with the speed of processing when using RipBot's DE mode and four older Dell PCs. If there's no MDegrain involved, I can rip through an encode in 2-3 hours. Add in MDegrain2 and we're talking more like 9 hours. File sizes are sometimes ridiculously small, even at CQ16 and it's a bit difficult to accept, but I go with it.

[Boulder]

--hdr10-opt is the one that causes the bitrate drop, the CRF values with and without it are not directly comparable. For HDR, I use CRF 14 or 15, downscaling to 1440p or 1080p largely depending on whether it's a native 4K source or just upscaled from 2K.

[Atak_Snajpera]

You are wasting energy! 30Mbps for 1080p and 60Mbps for 2160p? That's Probably more than original bitrate. Just remux that movie and do not reencode!

[Pauly Dunne]

Originally Posted by Atak_Snajpera

You are wasting energy! 30Mbps for 1080p and 60Mbps for 2160p? That's Probably more than original bitrate. Just remux that movie and do not reencode!

I was actually expecting you to chime in...

I think you'll find that GOOD quality original 1080p's & 2160p's can be ≥ than the bitrates I encode @ !!!

As far as I have noticed, it doesn't affect the processing time of the encode, it's simply the muxing that might take a little longer, but if you've got powerful CPU's & fast NVMe's, it's NOT an issue.

And just so you know, there's NO wasted energy here, "sunshine", I ONLY encode when I'm getting "free" power from my solar panels !!!!

Admittedly, some could be simply remuxed, but some need filtering !!

And while I have your attention, I have noticed an issue with Windows 11 (not that you'll care too much), but in the Encoding Client window, that little row of "button's" for each server, seem to loose their functionality, mainly the Shutdown Server button, not only doesn't it change it's appearance, you can't tell whether it's enabled or disabled, but either way, as it doesn't seem to want to turn off the server(s)....however, the main Shutdown Servers & Client works, tho.

[Atak_Snajpera]

You do not have my attention sunshine.

[Pauly Dunne]

Originally Posted by Atak_Snajpera

You do not have my attention sunshine.

I beg to differ...you replied

[chainring]

Originally Posted by Pauly Dunne

Hey chainring, yeah, not interested in downsizing 4K footage, I mean, that's why I bought a 4K, HDR TV !!!

4K, meh. HDR is where it's at.

I also use SMDegrain filters, found them better than MDegrain, I also don't use any CRF settings, I just go for bitrate, size is NOT an issue.

After years of messing with different scripts put together by the honest to god geniuses of Doom9, I no longer have the time nor inclination to constantly tweak scripts anymore. MDegrain works plenty good for me.

Bitrate is for when you need a predictable sized outcome. Why, if you're doing this for your own purposes, are you not letting CQ decide? Constant Quality. It ain't dumb. Go back and find posts from akupenguin and Dark_Shikari; get some history under your belt.

So 15,000kbps for 720p, 30,000kbps for 1080p, and 60,000kbps for 4K, and SMDegrain to "flavour"

You're wasting time and energy encoding at those bit rates. Why don't you stick with a remux?

[Ryushin]

Hi Atak,

I think I uncovered a bug. For some reason I can never bind to my subnet, 192.168.9.* for the encoding server. I tried adding to the encoding server:
/IP 192.168.9.40
And it always grabs the secondary IP 192.168.1.40. I added 172.28.27.40 and 192.168.0.40 as secondary IPs and the encoding server will bind to those, but not to 192.168.9.40. Very odd.

[LigH]

Shh, calm down please. Let's focus on technical solutions, not personal opinions.

[ReinerSchweinlin]

I just wanted to say "thanx" for the compare function in the avisynth tab Very helpful !

[slalom]

Originally Posted by Pauly Dunne

So 15,000kbps for 720p, 30,000kbps for 1080p, and 60,000kbps for 4K, and SMDegrain to "flavour"

1/2 το 1/3 of those numbers are good for me

[Daringbaaz]

Is There any Update Related to Ripbot,

Specially EncodingServer.exe

it Won't Opening on My RDP (Dedicated)

[Atak_Snajpera]

Originally Posted by Daringbaaz

Is There any Update Related to Ripbot,

Specially EncodingServer.exe

it Won't Opening on My RDP (Dedicated)

https://forum.doom9.org/showthread.p...15#post1941815