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

[supersnakeyez]

Originally Posted by FTLOY

Yes it is :- (as of 08-06-2024)

I would rely on your signature showing version available but no longer see it there. Thx for confirming though

Originally Posted by supersnakeyez

I would rely on your signature showing version available but no longer see it there. Thx for confirming though

Have no idea why that disappeared, but thank you for letting me know.

However, updates are few & far between.

I might have been hacked, as most of my info was changed.

[supersnakeyez]

Originally Posted by FTLOY

Have no idea why that disappeared, but thank you for letting me know.

However, updates are few & far between.

I might have been hacked, as most of my info was changed.

damn that sucks if that happened to you. hope all is good tho

[mikehbkwm]

Have a weird situation. I've been encoding DVD's (MPEG2) or Blu-ray (h.264) and upscaling them to HEVC 4K. Sometimes there's no issues when I playback in Plex, but other times when I go to play back the movie Plex states: Playback Stopped, Not enough disk space to convert this item. Utilizing Apple TV's as the client and never had this issue before.

Another example: Return of the Jedi (2006 Limited Edition DVD - GOUT) - upscaled to 4K HEVC with subtitles, and plays back in Plex no problems.
Star Wars (2006 Limited Edition DVD - GOUT) - upscaled to 4K HEVC with subtitles and get the playback stopped message.

I'm truly baffled as it doesn't make sense why one encode would work and the next one does not.

Any thoughts on this?

RipBot264 v1.27.3 (08-06-24)

Originally Posted by mikehbkwm

Have a weird situation. I've been encoding DVD's (MPEG2) or Blu-ray (h.264) and upscaling them to HEVC 4K. Sometimes there's no issues when I playback in Plex, but other times when I go to play back the movie Plex states: Playback Stopped, Not enough disk space to convert this item. Utilizing Apple TV's as the client and never had this issue before.

Another example: Return of the Jedi (2006 Limited Edition DVD - GOUT) - upscaled to 4K HEVC with subtitles, and plays back in Plex no problems.
Star Wars (2006 Limited Edition DVD - GOUT) - upscaled to 4K HEVC with subtitles and get the playback stopped message.

I'm truly baffled as it doesn't make sense why one encode would work and the next one does not.

Any thoughts on this?

RipBot264 v1.27.3 (08-06-24)

Not sure why you're upscaling DVD's to 4K ?!?!?!, but each to their own, I do some stuff that others don't understand !!!!

Could it be PLEX itself ???, it must be trying to decode stuff, and it's clearly running out of room, is there a setting for this "Not enough disk space" ??

https://www.youtube.com/watch?v=ZUfyK4ShsUk

I don't use PLEX, so good luck.

I would be very interested to know how many Threadripper owners are using RipBot successfully, with Distributed Encoding mainly.

Can it be "loaded up" to encode @ close to 100% CPU usage.

Anyone that own's a Ryzen 7950X (and 5950X's have a similar issue) will know what I'm on about, need to have specific encoder commands to get the best out of them, surely a CPU with more than 16 cores will suffer the same "dropping off a cliff" with especially 4K encodes.

I would suggest that the upcoming 9950X's will also be the same.

All and any comments will be appreciated

[rlev11]

So a couple years ago I ran tests with doing some 4k encoding on my 5950x and 7950x to see what the best way the "cripple" them was. As a review, a 7950x running full ran at 4.5fps, using aviprefetch set to 12 was 8.27fps, using affinity mask to run essentially as a 7900x was 8.41fps. Actually the best way was to using affinity mask to split the 7950x in half running essentially as 2 separate 8 core machines which had a combined fps as 9.73. I don;t remember if this was with mdegrain or smdegrain, but i don't think the percentages changed any.

So my GUESS would be for a threadripper with 24 or 32 actual cores, the best way to fully load them up would be to run them broken up into either 8 or 12 cpu separate servers when doing 4k encodes using affinity mask and use distributed encoding.

My testing also indicated when doing 1080p and below, that separating out the 16 core Ryzens into dual 8 cores had a very significant HIT in performance (about 30% lower). So I would think one would want to run a large core threadripper with all cores active, and probably would see a performance gain running multiple servers in this configuration

[Atak_Snajpera]

can't wait to see the same tests with latest Zen5 cpus. I wonder if larger L3 cache in TR would help in this case?

[rlev11]

Originally Posted by Atak_Snajpera

can't wait to see the same tests with latest Zen5 cpus.

As soon as they are released and drop from the initial above retail price I will find out.

I also found that encoding 4k with the 7950x with avx-512 in the encoding profile helps a little bit if the cpu is running all 16 avi-synth prefetch threads, but still no where near the performance with the avi-synth prefetch threads set to 12. It's just not AMD, my 14700 I had to adjust the prefetch threads down to 12 as well even with the P and E cores adding up to 20.

Like we have surmised, there is some buffer that just gets overloaded with all the additional bits in a 4k stream.

[Atak_Snajpera]

Do you see the same problem even with wide aspect 4k content. For example 3840x1600 (2.40:1)

[rlev11]

Originally Posted by Atak_Snajpera

Do you see the same problem even with wide aspect 4k content. For example 3840x1600 (2.40:1)

yes , but it is not as bad. Issue is worse at a full 3840x2160 and does get better as the aspect ratio gets "thinner", but not to the full speed of a crippled 16 core cpu. I always do an autocrop, so i don't encode black space.. I don't remember if the level of degraining plays any part in it as well.

I haven't really done any real bench marking lately as those numbers were from Jan 2023. Now I'm just noticing if I forget to do my 4k encoding server script that the numbers look down, then a quick swap of the server and things are back to normal.

I'll see if over the next week or so I can run some tests again on different aspect ratio clips with different parameters of both mdegrain and smdegrain scripts. One thing I really haven't tested is if not adding any degraining, just crop and go, if that makes any difference. Since it is avisynth prefetch threads, it might not.

It would be nice to figure out eventually exactly what is causing the issue, even if it can't easily be fixed.

Originally Posted by rlev11

yes , but it is not as bad. Issue is worse at a full 3840x2160 and does get better as the aspect ratio gets "thinner", but not to the full speed of a crippled 16 core cpu. I always do an autocrop, so i don't encode black space.. I don't remember if the level of degraining plays any part in it as well.

I haven't really done any real bench marking lately as those numbers were from Jan 2023.

Now I'm just noticing if I forget to do my 4k encoding server script that the numbers look down, then a quick swap of the server and things are back to normal.

That is why I have setup 2 RipBot's, one for 4K and its settings & scripts, and another for 1080p and under, each uses a separate temp & encodes folder works well, and you don't have to "remember" to swap thing between different resolutions. And even tho I haven't tested this, you could possibly run 2 instances of RB....

I'll see if over the next week or so I can run some tests again on different aspect ratio clips with different parameters of both mdegrain and smdegrain scripts. One thing I really haven't tested is if not adding any degraining, just crop and go, if that makes any difference. Since it is avisynth prefetch threads, it might not.

It would be nice to figure out eventually exactly what is causing the issue, even if it can't easily be fixed.

I just don't understand the purpose of cropping !!!

I did a couple of basic tests just the other day, and did a crop & no crop sample 4K run, and when played on my TV, it looks exactly the same !!!!

And my understanding is, don't Threadrippers have some form of NUMA, where the Ryzen's don't, per se.

If that's the case, then they can be "split" into 2 separate encoders.

But as I said to rlev11 in a PM the other day, for the price of even a budget Threadripper 7960X, you could almost have 3 basic 7950X's, and that would way more productive for ppl using DE

[rlev11]

So got a chance to run some test in the most controlled manner i could think of. Did a test with a GOT episode at 3840x2160, ST Strange New Worlds at 3840x1600, and The Wire at 1920x1080 just to see how a crippled 7950x reacts to 1080p. Each 7950x fps score was on Chunk 5 and a comparison 7900x score from Chunk6. Dual server 7950x scores were from chunks 5 and 6 combined. Resultant spreadsheet is linked below.

My take on what I saw this time. AVX512 on the 7900 and 7950 makes very little difference, and in most cases actually hinders performance a bit.
Anything more than 12 avisynth-prefetch threads just kills 3840x2160, but does get much less a difference at 3840x1600. I would imagine the percentages difference for say 1:1.85 ,1:2.0, and 1:2.35 would fall in line somewhere in between.
SMdegrain is just so much faster than mdegrain3 especially in anything 4k.
Running a 7950 as a pseudo 7900 using affinity mask is NOT the way to go.
Though the actual numbers will be different, I would imagine that the best way to cripple a 7950x would also be the best way to cripple a 5950x. Intels would probably be best using the lower avisynth prefetch threads of 12. No idea how affinity mask would even work with the whole E and P cores
Was actually surprised by the numbers of turning a 7950x into a pseudo dual server 7700x (column G) in Ripbot.


https://docs.google.com/spreadsheets...f=true&sd=true

Originally Posted by rlev11

So got a chance to run some test in the most controlled manner i could think of. Did a test with a GOT episode at 3840x2160, ST Strange New Worlds at 3840x1600, and The Wire at 1920x1080 just to see how a crippled 7950x reacts to 1080p. Each 7950x fps score was on Chunk 5 and a comparison 7900x score from Chunk6. Dual server 7950x scores were from chunks 5 and 6 combined. Resultant spreadsheet is linked below.

My take on what I saw this time. AVX512 on the 7900 and 7950 makes very little difference, and in most cases actually hinders performance a bit.
Anything more than 12 avisynth-prefetch threads just kills 3840x2160, but does get much less a difference at 3840x1600. I would imagine the percentages difference for say 1:1.85 ,1:2.0, and 1:2.35 would fall in line somewhere in between.
SMdegrain is just so much faster than mdegrain3 especially in anything 4k.
Running a 7950 as a pseudo 7900 using affinity mask is NOT the way to go.
Though the actual numbers will be different, I would imagine that the best way to cripple a 7950x would also be the best way to cripple a 5950x. Intels would probably be best using the lower avisynth prefetch threads of 12. No idea how affinity mask would even work with the whole E and P cores
Was actually surprised by the numbers of turning a 7950x into a pseudo dual server 7700x (column G) in Ripbot.


https://docs.google.com/spreadsheets...f=true&sd=true

Interesting results, and a bit of time spent doing that

So all these tests were using DE on a single PC ??

Are the MDegrain & SMDegrain settings as close to each other as you could get ??? I'm thinking MD3 is a lot "stronger than SMD tr=3....and did you change the mutli thread settings for MD on page 1 ??

Also, I am currently using prefetch threads of 14, on all doing 4K encodes, even my 13900KF.

===============================

On another topic, I have watched several YT reviews of the new 9600X's & 9700X's, not looking too good, let's hope the "big" one's are on point, otherwise it could be a waste of money, money you could spend on a Threadripper, for example....or a couple more 7950X's.

[rlev11]

Originally Posted by FTLOY

Interesting results, and a bit of time spent doing that

So all these tests were using DE on a single PC ??

Are the MDegrain & SMDegrain settings as close to each other as you could get ??? I'm thinking MD3 is a lot "stronger than SMD tr=3....and did you change the mutli thread settings for MD on page 1 ??

Also, I am currently using prefetch threads of 14, on all doing 4K encodes, even my 13900KF.

===============================

On another topic, I have watched several YT reviews of the new 9600X's & 9700X's, not looking too good, let's hope the "big" one's are on point, otherwise it could be a waste of money, money you could spend on a Threadripper, for example....or a couple more 7950X's.

All test runs on same computer which is my main 7950x using distributed encoding. My 7900x was in the mix for all the runs as well.

The mdegrain3 was just choosing it in the menu with strength 200, no other custom settings. This is what I used to use before switching to smdegrain for light degraning on mostly clean source material. The smdegrain custom script is what I use now on similar material and the results are comparable to my eyes.

Interesting on the 14 prefetch threads, Pretty sure back a while ago I determined that 12 was the magic number, but I will try 14 and see if that works a little better now.

Main point was to answer Atak's question a few threads above about 4k 2.40 aspect ration and how it compared. I knew what the answer was from all my encoding I have done over the years, but wanted to confirm with some hard numbers. I don't know enough about avisynth multi threading to really dig into where the bottleneck is, but maybe someone else can figure it out. It's not really a big deal to switch the encoding server on the 16 core ryzens when doing 4k using a .bat file, in fact my 3 5950's and 1 3950 that I have in my encoding farm have a startup script that loads 12 prefetch threads and I just leave them like that for everything. I only switch my main client 7950 when I do a 4k run.

Originally Posted by rlev11

All test runs on same computer which is my main 7950x using distributed encoding. My 7900x was in the mix for all the runs as well.

The mdegrain3 was just choosing it in the menu with strength 200, no other custom settings. This is what I used to use before switching to smdegrain for light degraning on mostly clean source material. The smdegrain custom script is what I use now on similar material and the results are comparable to my eyes.

Interesting on the 14 prefetch threads, Pretty sure back a while ago I determined that 12 was the magic number, but I will try 14 and see if that works a little better now.

Main point was to answer Atak's question a few threads above about 4k 2.40 aspect ration and how it compared. I knew what the answer was from all my encoding I have done over the years, but wanted to confirm with some hard numbers. I don't know enough about avisynth multi threading to really dig into where the bottleneck is, but maybe someone else can figure it out. It's not really a big deal to switch the encoding server on the 16 core ryzens when doing 4k using a .bat file, in fact my 3 5950's and 1 3950 that I have in my encoding farm have a startup script that loads 12 prefetch threads and I just leave them like that for everything. I only switch my main client 7950 when I do a 4k run.

So in reference to this post:-

https://forum.doom9.org/showthread.p...02#post2005202

Why crop ??

[rlev11]

Originally Posted by FTLOY

So in reference to this post:-

https://forum.doom9.org/showthread.p...02#post2005202

Why crop ??

Pretty simple, Why encode the bits in the black bars. Just re-ran the strange new worlds run (Block D-17 on the spreadsheet). Doing an autocrop reducing the 3840x2160 original file to 3840x1600, at 1600 I had speeds of 18.11fps for the 7950x and 15.5 for the 7900x. The same chunks without an autocrop at 2160 they dropped to 14.18 and 12.57. That's about a 20% drop in performance...

Originally Posted by rlev11

Pretty simple, Why encode the bits in the black bars. Just re-ran the strange new worlds run (Block D-17 on the spreadsheet). Doing an autocrop reducing the 3840x2160 original file to 3840x1600, at 1600 I had speeds of 18.11fps for the 7950x and 15.5 for the 7900x. The same chunks without an autocrop at 2160 they dropped to 14.18 and 12.57. That's about a 20% drop in performance...

OK, so the way I understand that is, it removes the black bars for the encoding process, but looks exactly the same on a TV ???

[rlev11]

Correct, It will only encode the bits that are needed, regardless of what aspect ratio it is, even a 4:3 encode will not include the left and right bars. TVs don't care, it will always just center whatever is sent to it

Originally Posted by rlev11

Correct, It will only encode the bits that are needed, regardless of what aspect ratio it is, even a 4:3 encode will not include the left and right bars. TVs don't care, it will always just center whatever is sent to it

Thanks very much for that, like I said I very rarely crop, and if I do, I rely on the autocrop function...

So I wiil defintely start using that, and see what happens.