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

[cypher007]

Hello. Are there any limitations in the ripbot264 on the use of the cpu? To be specific I can't use the full power of my cpu and gpu .The cpu used during encoding is no more than 22%

https://iili.io/JJ3JxIa.md.png (https://freeimage.host/i/JJ3JxIa)
https://iili.io/JJ3JzhJ.md.png (https://freeimage.host/i/JJ3JzhJ)

Edit: Second pass is no more than 46%
https://iili.io/JJ3ohml.md.png (https://freeimage.host/i/JJ3ohml)

are you using windows 10? i had a similar issue and its the way the thread scheduler works in win 10. i did fix it and post in this thread but it was a bit of fafing about so just use win 11 instead. it only affects the newer Hybrid CPU's like 12th gen+

[Yopen71]

are you using windows 10? i had a similar issue and its the way the thread scheduler works in win 10. i did fix it and post in this thread but it was a bit of fafing about so just use win 11 instead. it only affects the newer Hybrid CPU's like 12th gen+

Going to Win 11 is not a solution. It's still very buggy. It's not worth it because of a program to change entire Windows.Maybe there have a solution in win 10?

[Atak_Snajpera]

Workaround
1) disable fast first pass option
2) activate distributed encoding mode with 2 local active encoding servers. Chuck size set to 0. encoding servers priority set to variable.

This should help with CPU usage.

[Yopen71]

Workaround
1) disable fast first pass option
2) activate distributed encoding mode with 2 local active encoding servers. Chuck size set to 0. encoding servers priority set to variable.

This should help with CPU usage.
Thanks for your answer,but actually is little bit unclear for me cuz I'm new ripbot user.
1) disable fast first pass option -you mean to encode in one pass cbr ?
2) activate distributed encoding mode with 2 local active encoding servers. - As far as I know Ripbot264 use Distributed Encoding Mode for connection between several PCs and I have only one PC. Sorry I'm just confused.

Edit:Opss Understand:
https://iili.io/JJFtB3X.md.png (https://freeimage.host/i/JJFtB3X)

[caphp]

Hi Yopen71,
because you are using an i5-13600k ( p and e cores ), you can try to switch your windows power plan to "High performance".
This might help.

[Yopen71]

Hi Yopen71,
because you are using an i5-13600k ( p and e cores ), you can try to switch your windows power plan to "High performance".
This might help. I can choose between only 2 plans balanced and economical win10 22H2.
With the help of Atak_Snajpera I managed to reach the full potential of my PC.
Many many Thanks!

[Atak_Snajpera]

I can choose between only 2 plans balanced and economical win10 22H2.
With the help of Atak_Snajpera I managed to reach the full potential of my PC.
Many many Thanks!

Since you are encoding only on one machine I suggest these settings

Make sure that you put 0.0.0.0 in unused slots!
https://i.postimg.cc/yYVjGjvh/Capture.png


Then click on wrench icon and change priority from low to variable

https://i.postimg.cc/qR1qvkHv/Capture.png

With variable priority there is higher chance that both chunks will be encoded at the same time.

1) disable fast first pass option -you mean to encode in one pass cbr ?
uncheck USE FAST FIRST PASS IN 2-PASS MODE in Settings

[Yopen71]

Since you are encoding only on one machine I suggest these settings

Make sure that you put 0.0.0.0 in unused slots!



Then click on wrench icon and change priority from low to variable



With variable priority there is higher chance that both chunks will be encoded at the same time.


uncheck USE FAST FIRST PASS IN 2-PASS MODE in Settings
Thanks again! Using exactly your steps. CPU now use it's full power

https://iili.io/JJfVjkb.md.png (https://freeimage.host/i/JJfVjkb)

Edit: Second pass cpu lose 50%

With next movie I will try to activate server 3 and 4. Something strange happening,but it's not a big deal.
https://iili.io/JJfvKns.md.png (https://freeimage.host/i/JJfvKns)

Edit2:
Problem with cpu solved. Using DE with 4 servers instead of 2 solve the problem.Great application! The only downside for me is, that I can't encode the audio stream separately from the video.I mean If I have to re-encode the audio stream I must to re-encode and the video stream again

[rlev11]

Just asking why you would want to encode the audio stream separately from the video? You can encode the audio stream to pretty much whatever you want when you do the whole video in ripbot. When you add the video, in the encoder settings window change the profile under audio from x.xcopy stream (leaves audio alone) to whatever you want. I do this to convert from dts to AC3.

if you need to do the audio separately for some other reason, suggest using mkvtoolnix gui to extract the audio, then run it through Audacity to convert it, then use mkvtoolnix gui to add the new audio back in with the video.

[Yopen71]

Just asking why you would want to encode the audio stream separately from the video? You can encode the audio stream to pretty much whatever you want when you do the whole video in ripbot. When you add the video, in the encoder settings window change the profile under audio from x.xcopy stream (leaves audio alone) to whatever you want. I do this to convert from dts to AC3.

if you need to do the audio separately for some other reason, suggest using mkvtoolnix gui to extract the audio, then run it through Audacity to convert it, then use mkvtoolnix gui to add the new audio back in with the video.

Of course, there have many tools to edit/encode audio Audacity,Sound Forge, foobar2000 etc. Actually there have different apps for every process in ripbot264, but one flexible program will be much better for me ,than jumping from app to app and to next app... It's just my opinion, nothing more. For example: someone has a large collection of movies with dts audio. And if he want just to replace thats dts to flac or ac3. And if ripbot264 has x.xcopy stream ( video ), will be just one click replacement for one movie instead of using mkv merge for extracting,then audacity for encoding, then back to mkv tool for muxing...

[Atak_Snajpera]

Using DE with 4 servers instead of 2 solve the problem.
Still I does not look right that you need 4 x264 encoders running at the same time to fully saturate 14 core cpu(6p+8e). For example 16-core AMD CPUs do not have that problem. I'm pretty sure win11 would do much better in this matter. Clearly win10 scheduler is doing something stupid here.

[rlev11]

Of course, there have many tools to edit/encode audio Audacity,Sound Forge, foobar2000 etc. Actually there have different apps for every process in ripbot264, but one flexible program will be much better for me ,than jumping from app to app and to next app... It's just my opinion, nothing more. For example: someone has a large collection of movies with dts audio. And if he want just to replace thats dts to flac or ac3. And if ripbot264 has x.xcopy stream ( video ), will be just one click replacement for one movie instead of using mkv merge for extracting,then audacity for encoding, then back to mkv tool for muxing...

Years ago I did a similar batch convert from dts to ac3. I put the videos in a folder and then ran this command from that folder and it did the audio convert and left the video alone. Went pretty fast if I remember. Not sure if the script would support other outputs, but it probably would. If I remember right, I setup different folders depending on the number of audio channels and then just changed the output size accordingly. so 6 channel left at 640k and 2 channel changed that to 256k. Re-did all the videos and added -Ac3 to the file name of the converted one. Then loaded up RenameMaster and batch removed the -AC3 from the filename.

FOR %%f IN (*.mkv) DO E:\ffmpeg\bin\ffmpeg.exe -i "%%f" -map 0 -vcodec copy -scodec copy -acodec ac3 -b:a 640k "%%~nf"-AC3.mkv

[Yopen71]

Still I does not look right that you need 4 x264 encoders running at the same time to fully saturate 14 core cpu(6p+8e). For example 16-core AMD CPUs do not have that problem. I'm pretty sure win11 would do much better in this matter. Clearly win10 scheduler is doing something stupid here.

In my case:
when I use 2 servers: pass1 cpu at 100%, pass2 cpu at 46%
when I use 3 servers: 1 and 2 pass cpu at 100%
I use 4 servers, to be sure :)

[redeyes50]

hi, it has certainly been written but how do I set up automatic indexing with ffvideosurce instead LSMASHSource

[guest]

hi, it has certainly been written but how do I set up automatic indexing with ffvideosurce instead LSMASHSource

Congrats on your first post :)

Interesting that you don't want to use L-Smash.

There is a very new L-smash update, if you want to try that,

https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases/tag/1141.0.0.0

there is also a recent update for FFMS2 as well.

https://forum.doom9.org/showthread.php?p=1991852#post1991852


But if you want to use FFMS2 as your "decoder / indexer", then all you need to do is this :-

overwrite this field in RipBot264.ini if you want to use FFMS2 instead of L-Smash

[DefaultVideoDecoder]
MPEG-2=FFMS2
VC-1=FFMS2
AVC=FFMS2
HEVC=FFMS2
OTHER=FFMS2

Just a heads-up, if you change this, it will stay there until you do ANY other change to the settings in the GUI, and press the Apply button !!!

[redeyes50]

Now I have a problem I can't get 2 PCs to communicate on the same network. establishes the connection but immediately closes with an error. ripbtot264temp\job1\chuncks\5.cmd. does not exist!


therefore the connection is also successful but then it is unable to exploit the other CPU

[rlev11]

Now I have a problem I can't get 2 PCs to communicate on the same network. establishes the connection but immediately closes with an error. ripbtot264temp\job1\chuncks\5.cmd. does not exist!


therefore the connection is also successful but then it is unable to exploit the other CPU

First thing to check,

Are you able to create a share on each machine and connect to it from the other one and both read and write to the shares. This will have to work for distributed encoding to work and copy the chunks from the client to the servers and back.

Are you using a username and password to log into the computers. to do the share you may have to put in the authentication username and password in the distributed encoding section.

If you are not using a password to log into windows , check under advanced file sharing and make sure that under all networks, turn off password protected sharing is selected.

[lemaireus]

Atak, EAC3 seems to have some advantages over AC3, so would you please consider incorporating an option to encode audio in EAC3? XMedia Recode has done a pretty good job of providing EAC3 encode option in their GUI and it would be great if we could get that option in RipBot as well. Thank you.

[tkwou]

Hi Atak. I haven't been doing much encoding lately but I've kept my server farm updated. I have a Ryzen 3600, a couple older FX 8 cores and a couple older I7's. My desktop is a Ryzen 5600G. With encoding of Bluray I seem to get a frame rate of just over a hundred. The Ryzen 5600G gets the highest individual encode rate of up to about 30 fps. Surprisingly when I did the encode alone with the Ryzen 5600G, I got over 60 fps just on it's own. Does this seem correct? Does all the DE overhead slow things down that much? Thanks.

[guest]

Hi Atak. I haven't been doing much encoding lately but I've kept my server farm updated. I have a Ryzen 3600, a couple older FX 8 cores and a couple older I7's. My desktop is a Ryzen 5600G. With encoding of Bluray I seem to get a frame rate of just over a hundred. The Ryzen 5600G gets the highest individual encode rate of up to about 30 fps. Surprisingly when I did the encode alone with the Ryzen 5600G, I got over 60 fps just on it's own. Does this seem correct? Does all the DE overhead slow things down that much? Thanks.

Just my 2 cents worth.....

Maybe the other PC's are dragging the whole process down, you might be better off just using the Ryzen's, scrap the others.

[tkwou]

Thanks TDS. I tried the same encode with just the two Ryzens. The 5600G got about 35-36fps and the 3600 was at 15-16fps with a total rate around 51fps. The 5600G encoding alone was encoding at over 60fps.

[guest]

Thanks TDS. I tried the same encode with just the two Ryzens. The 5600G got about 35-36fps and the 3600 was at 15-16fps with a total rate around 51fps. The 5600G encoding alone was encoding at over 60fps.

I have to say that that is strange, DE is supposed to accelerate the process.

Of course, it can depend on what filters you're using, and other processing settings, etc.

It's pretty much impossible to figure out what might be causing this, without "being at your system".

[Atak_Snajpera]

Hi Atak. I haven't been doing much encoding lately but I've kept my server farm updated. I have a Ryzen 3600, a couple older FX 8 cores and a couple older I7's. My desktop is a Ryzen 5600G. With encoding of Bluray I seem to get a frame rate of just over a hundred. The Ryzen 5600G gets the highest individual encode rate of up to about 30 fps. Surprisingly when I did the encode alone with the Ryzen 5600G, I got over 60 fps just on it's own. Does this seem correct? Does all the DE overhead slow things down that much? Thanks.

What was the CPU usage? If IT was lower then this could mean that there is some bottleneck. Which pc is hosting file? FX or ryzen? Regarding overhead there is none as long as you have good LAN connection and main pc is not a pottato.

[rlev11]

Might want to try loading the client on the 3600 and use the 5600g as a server and see what happens. Will the 5600 go back up to speed, and will the 3600 drop off as the client. I run a 5600g in my farm and for what it is, I get pretty good performance out of it for it's price point. Slots in just a bit below my Ryzen 3900's. I'll try running an encode with DE turned off when I get a chance to see what happens, although being a 7950x and 10 gig network backbone, I doubt I have any overhead and see a difference.

And BTW Atak, I've been redoing a bunch of my older encodes to SMdegrain just because, but I have had 12 physical machines and 15 encoder threads running pretty much non-stop for a week now with upwards of 500 jobs in the queue at times and not 1 glitch in Ripbot (I am impressed)

[Atak_Snajpera]

Might want to try loading the client on the 3600 and use the 5600g as a server and see what happens. Will the 5600 go back up to speed, and will the 3600 drop off as the client. I run a 5600g in my farm and for what it is, I get pretty good performance out of it for it's price point. Slots in just a bit below my Ryzen 3900's. I'll try running an encode with DE turned off when I get a chance to see what happens, although being a 7950x and 10 gig network backbone, I doubt I have any overhead and see a difference.

And BTW Atak, I've been redoing a bunch of my older encodes to SMdegrain just because, but I have had 12 physical machines and 15 encoder threads running pretty much non-stop for a week now with upwards of 500 jobs in the queue at times and not 1 glitch in Ripbot (I am impressed)

I'm impressed as well. LOL!

[guest]

Might want to try loading the client on the 3600 and use the 5600g as a server and see what happens. Will the 5600 go back up to speed, and will the 3600 drop off as the client. I run a 5600g in my farm and for what it is, I get pretty good performance out of it for it's price point. Slots in just a bit below my Ryzen 3900's. I'll try running an encode with DE turned off when I get a chance to see what happens, although being a 7950x and 10 gig network backbone, I doubt I have any overhead and see a difference.

And BTW Atak, I've been redoing a bunch of my older encodes to SMdegrain just because, but I have had 12 physical machines and 15 encoder threads running pretty much non-stop for a week now with upwards of 500 jobs in the queue at times and not 1 glitch in Ripbot (I am impressed)

But that's with a PD build Ripbot !!, obviously.

[Atak_Snajpera]

But that's with a PD build Ripbot !!, obviously.

Did he compile whole thing in delphi with added new code?

Definition of build
https://www.techopedia.com/definition/3759/build

[rlev11]

As far as I remember I have a base install (which gets updated automatically) and all I did was add in the couple of PD scripts to enable SMdegrian to work. It is not a full PD Build download. Regardless, the PD builds wouldn't touch the underlying program.
My point was just to say that there are a crap ton of bits flying around in all different directions that Ripbot needs to keep track of and has done so flawlessly for a very long time and even during this recent extreme power session and thought the author should be made aware of my experience. To load up hundreds of jobs and walk away with the confidence that when I return all is running as expected is something that I appreciate greatly, especially for a program that is essentially freeware.

I have no doubt that a base Ripbot install would perform just as well (and did in the past mostly once a patch or workaround was figured out), but would only be losing the speed and quality benefit that SMdegrain provides. The only real batch stability issue I experienced in the past was with the windows 11 update, some encoding servers would periodically lock and not restart, stopping an encode until I manually aborted it and restarted it. This was easily fixed by making sure the encoding server window did not get minimized in the system tray as i had it set with Windows 10, Once I kept it maximized on the desktop, that whole issue went away.

[rlev11]

And on another topic Atak, I'm starting to see some stuff crop up at a 2.2:1 aspect ratio now (Gaslit for 1 and something else I can't remember, plus the upcoming Oppenheimer). I know in the past you added 2:1 to the resize drop down when requested. Not a big deal, but on your next update for something else if you could add in 2.2:1 to the drop down that would be appreciated

[tkwou]

What was the CPU usage? If IT was lower then this could mean that there is some bottleneck. Which pc is hosting file? FX or ryzen? Regarding overhead there is none as long as you have good LAN connection and main pc is not a pottato.

Thanks Atak. The Ryzen 5600G/B450 is running client. Everything is running on a gigabit LAN. Encoding is standard one pass bluray at CQ18. Between x264 and Ripbot264 they are using over 90% cpu. I reversed the roles with the Ryzen 3600/B450 running client instead. This time the 3600 was encoding in the 45-48fps range (significantly up from 15-16fps) and but the 5600G is still only doing 28-30fps. Then I had the 3600 run solo and it went up to 65fps (faster than the 5600G). The 3600 is running an NVidia 3060. I don't know if that makes a difference. For some reason the 5600G doesn't like be client.

[rlev11]

that is very strange, especially with the cpu usage consistent whether you are using a pc either as a client, server, or single. Try this with something short, say a 10 or 15 minute clip. run it on the 5600 with DE off and actually time how long it takes (forget about the fps display). then turn de back on with the 3600 back in the mix. Start the same encode and as soon as it starts, in the distributed encoding window turn off the 3600 so only the 5600 is encoding and do the same and measure the time. Really interested if the total time to encode with the 5600 is that much different when it is encoding alone with de on or de off. It may take a little longer with DE on as there is some time overhead as each chunk initializes the encoding process, but it should not take twice as long the the fps display would suggest.
It could just be the fps display calculation if off with de on or off. just seems strange to see so much of a difference on the fps display

[guest]

Did he compile whole thing in delphi with added new code?

Definition of build
https://www.techopedia.com/definition/3759/build

You edited this post from what you said originally!!!

No, how could he have done that, especially when RB is such a "closed source" application.

But as soon as someone mentions that they are using SMDegrain, it has to be something to do with PD's builds, as you seem to not be interested in implementing it into RB.

I think I can safely say that anyone who's not using SMDegrain, and it's filtering possibilities, is just simply wasting their time.

[guest]

As far as I remember I have a base install (which gets updated automatically) and all I did was add in the couple of PD scripts to enable SMdegrian to work. It is not a full PD Build download. Regardless, the PD builds wouldn't touch the underlying program.
My point was just to say that there are a crap ton of bits flying around in all different directions that Ripbot needs to keep track of and has done so flawlessly for a very long time and even during this recent extreme power session and thought the author should be made aware of my experience. To load up hundreds of jobs and walk away with the confidence that when I return all is running as expected is something that I appreciate greatly, especially for a program that is essentially freeware.

I have no doubt that a base Ripbot install would perform just as well (and did in the past mostly once a patch or workaround was figured out), but would only be losing the speed and quality benefit that SMdegrain provides. The only real batch stability issue I experienced in the past was with the windows 11 update, some encoding servers would periodically lock and not restart, stopping an encode until I manually aborted it and restarted it. This was easily fixed by making sure the encoding server window did not get minimized in the system tray as i had it set with Windows 10, Once I kept it maximized on the desktop, that whole issue went away.

So how I understand it, you run the "vaniila" v1.27.0, with auto-updates enabled, and have "hacked" SMDegain (and dependencies) out of a PD build ??

So what about all the updated components that the PD build has, compared to the "vanilla" ?? or do you update it yourself ??

There' has been a substantial amount of component updates released recently, FYI.

But there hasn't been an RB update since 17/06/2023.

[Guest]

All I can say is thank goodness for ppl like Pauly Dunne for taking the time to be able to use SMDegrain with RipBot.

It's such a shame that he doesn't seem to be posting any newer builds. :(

[rlev11]

So how I understand it, you run the "vaniila" v1.27.0, with auto-updates enabled, and have "hacked" SMDegain (and dependencies) out of a PD build ??

So what about all the updated components that the PD build has, compared to the "vanilla" ?? or do you update it yourself ??

There' has been a substantial amount of component updates released recently, FYI.

But there hasn't been an RB update since 17/06/2023.

All I am saying is around 1 year ago, I added in to whatever ripbot version at the time what was called the PD-Lite version, which included if i remember right adding a folder under avisynth plugins and then running a couple scripts to load the avisynth and the couple dll files to get smdegrain to work. After that I have not touched anything. I got everything the way I need it and it just works. After 40 years in IT, I have learned it is not always prudent to update, just for sake of updating.

I to am very grateful for the work done to get SMdegrain to work with Ripbot. Just the speed increase in encoding is a huge deal. Whether it is ever incorporated natively into Ripbot is up to the Author and doesn't concern me. It's very easy to incorporate it into the base program and with everything else, it just works.

All I did was I wanted to let Atak know that I am in the middle of about as extreme of a stress test as one could want, and everything is just humming along going on about 180 hours full-bore non-stop. That's it, nothing else, and my last word on the subject.

[guest]

All I am saying is around 1 year ago, I added in to whatever ripbot version at the time what was called the PD-Lite version, which included if i remember right adding a folder under avisynth plugins and then running a couple scripts to load the avisynth and the couple dll files to get smdegrain to work. After that I have not touched anything. I got everything the way I need it and it just works. After 40 years in IT, I have learned it is not always prudent to update, just for sake of updating.

I to am very grateful for the work done to get SMdegrain to work with Ripbot. Just the speed increase in encoding is a huge deal. Whether it is ever incorporated natively into Ripbot is up to the Author and doesn't concern me. It's very easy to incorporate it into the base program and with everything else, it just works.

All I did was I wanted to let Atak know that I am in the middle of about as extreme of a stress test as one could want, and everything is just humming along going on about 180 hours full-bore non-stop. That's it, nothing else, and my last word on the subject.

Just as well you did the SMDegrain addition back then, as you would have a lot more to do, if you were to do it now, as the PD builds are not around anymore.

I would doubt that are too many users that would queue up so many jobs, and having it running non-stop for so long, I'm glad I'm not paying your energy bill.

You clearly have a very reliable setup, to be able to run that long without any or few problems, I'm sure it's not like for everyone, it's just the nature of the beast, the beast being RipBot.

[Slogra]

I'm using Ripbot264 1.26.0 to encode DVDs. The discs were ripped with good old DVD Decrypter in ifo mode to vob.
The vobs have an ac3 audio track, but ripbot264 does not demux it. No ac3 files are in the temp folder. And ripbot264 shows NO AUDIO audio dropdown.
Am i doing something wrong?

How can i mux the ac3 audio with the correct delay to my video?

[tkwou]

that is very strange, especially with the cpu usage consistent whether you are using a pc either as a client, server, or single. Try this with something short, say a 10 or 15 minute clip. run it on the 5600 with DE off and actually time how long it takes (forget about the fps display). then turn de back on with the 3600 back in the mix. Start the same encode and as soon as it starts, in the distributed encoding window turn off the 3600 so only the 5600 is encoding and do the same and measure the time. Really interested if the total time to encode with the 5600 is that much different when it is encoding alone with de on or de off. It may take a little longer with DE on as there is some time overhead as each chunk initializes the encoding process, but it should not take twice as long the the fps display would suggest.
It could just be the fps display calculation if off with de on or off. just seems strange to see so much of a difference on the fps display
So here's the results. 15 minutes of bluray encoded @ 4.0 standard AVC at CQ=18 Single Pass. Encode time only.

5600G DE=off 5:54 @60.6fps
5600G DE=on 5600G lone server 10:24 @36.5 fps
5600G DE=on 5600G +3600 server 7:16 @52.5 fps (5600G@35.2fps,3600@17.26fps)
3600 DE=off 5:25 @67.0fps (using NV3060 for OpenCL acceleration)
3600 DE=on 3600 lone server 9:07 @43.0fps
3600 DE=on 3600 + 5600G server 6:13 @68.0fps (3600@41.70fps,5600G@26.4fps)
With DE=off both CPU's are maxed out. DE=on encoding server is only running at 60% or less. Encoding server is set to Encoding Priority=normal but in the TCP Communication log, it is set to belownormal. Is this being sent by Encoding Client?

[rlev11]

Ok, so the time and the fps match up pretty close. I just tested on my client. my 7950x running as a single (or with others) in distributed mode is doing a test encode (hevc 10bit crf 18, smdegrain mild, pretty much what I use for most stuff) came in around 45fps. when I turned off distributed mode and ran the exact same settings, I still got around 45fps.

I'm at a complete loss to what you are seeing. Now I do not do any kind of hardware decoding. In the ripbot settings I have "CPU" set for all the default video decoders, and in the OpenCL Tab I have none in the opencl acceleration device drop down. Are you setting anything in the avisynth menu like CPU or GPU denoise?

My TCP log also shows encoding server below normal when it runs in DE mode, but I see no difference in speed, not sure what that means

[rlev11]

I'm using Ripbot264 1.26.0 to encode DVDs. The discs were ripped with good old DVD Decrypter in ifo mode to vob.
The vobs have an ac3 audio track, but ripbot264 does not demux it. No ac3 files are in the temp folder. And ripbot264 shows NO AUDIO audio dropdown.
Am i doing something wrong?

How can i mux the ac3 audio with the correct delay to my video?

My suggestion would be to download and run the dvd decrypter file through Makemkv which should convert it to an mkv. I think it should be able to handle that. Then see if ripbot can read the audio from the ac3 file. Ripbot for some reason may not be able to extract the ac3 out of the vob for some reason

[guest]

I'm using Ripbot264 1.26.0 to encode DVDs. The discs were ripped with good old DVD Decrypter in ifo mode to vob.
The vobs have an ac3 audio track, but ripbot264 does not demux it. No ac3 files are in the temp folder. And ripbot264 shows NO AUDIO audio dropdown.
Am i doing something wrong?

How can i mux the ac3 audio with the correct delay to my video?

I would suggest that you update to v1.27.0 either using the autoupdate function, OR directly from the link below.

I have found that MKVToolNix is a bit "fussy" processing .vobs, but it can be done.

But if your disk's aren't encrypted, you could try MakeMKV, as rlev11 suggested.

However, it seems that MakeMKV does rip encrypted dvd's, so you could skip the DVD Decryptor step, all together.

I would try Handbrake, it eat's it up.

Personally, I prefer to use VideoRedo to do the rip (if not encrytped), and process to .mkv, so you'd need to use DVD Decryptor beforehand.

[guest]

So here's the results. 15 minutes of bluray encoded @ 4.0 standard AVC at CQ=18 Single Pass. Encode time only.

5600G DE=off 5:54 @60.6fps
5600G DE=on 5600G lone server 10:24 @36.5 fps
5600G DE=on 5600G +3600 server 7:16 @52.5 fps (5600G@35.2fps,3600@17.26fps)
3600 DE=off 5:25 @67.0fps (using NV3060 for OpenCL acceleration)
3600 DE=on 3600 lone server 9:07 @43.0fps
3600 DE=on 3600 + 5600G server 6:13 @68.0fps (3600@41.70fps,5600G@26.4fps)
With DE=off both CPU's are maxed out. DE=on encoding server is only running at 60% or less. Encoding server is set to Encoding Priority=normal but in the TCP Communication log, it is set to belownormal. Is this being sent by Encoding Client?

As I said in this post :-

https://forum.doom9.org/showthread.php?p=1993389#post1993389

And as rlev11 mentioned, whether using DE or as single, with one CPU, the "speed" should be basically identical.

You must have some bottleneck in there somewhere.

Good luck figuring it out, it will be worth it in the long run.

[tkwou]

Ok, so the time and the fps match up pretty close. I just tested on my client. my 7950x running as a single (or with others) in distributed mode is doing a test encode (hevc 10bit crf 18, smdegrain mild, pretty much what I use for most stuff) came in around 45fps. when I turned off distributed mode and ran the exact same settings, I still got around 45fps.

I'm at a complete loss to what you are seeing. Now I do not do any kind of hardware decoding. In the ripbot settings I have "CPU" set for all the default video decoders, and in the OpenCL Tab I have none in the opencl acceleration device drop down. Are you setting anything in the avisynth menu like CPU or GPU denoise?

My TCP log also shows encoding server below normal when it runs in DE mode, but I see no difference in speed, not sure what that means
Thanks, I don't know what's happening but it's clearly happening in two separate machines in exactly the same manner. They both encoding much slower in DE mode than when running DE=off. CPU is maxed out in solo mode but DE mode doesn't run more than about 60% CPU. And as I have suspected all my other DE servers are also encoding at less than their maximal rates too. I have not used Ripbot264 much over the past 18 months but I seemed to remember that I used to get a lot higher overall encode rate with the server farm than I presently do. I have not changed any settings that I am away of. I pretty much use all default settings. I have kept Ripbot updated on all of the server farm each time before I do an encode.

[guest]

Thanks, I don't know what's happening but it's clearly happening in two separate machines in exactly the same manner. They both encoding much slower in DE mode than when running DE=off. CPU is maxed out in solo mode but DE mode doesn't run more than about 60% CPU. And as I have suspected all my other DE servers are also encoding at less than their maximal rates too. I have not used Ripbot264 much over the past 18 months but I seemed to remember that I used to get a lot higher overall encode rate with the server farm than I presently do. I have not changed any settings that I am away of. I pretty much use all default settings. I have kept Ripbot updated on all of the server farm each time before I do an encode.

I could get proven wrong with this, and as I haven't been using RipBot for several months I'm a little rusty.

But I recall, there were some changes made to assist DE, quite a while back, and you can edit the command line to modify how many cpu cores/threads are used, how x264 & x265 use the cpu, etc, and it can make a huge difference.

If you go into the RipBot264.ini file you will see similar to below, these thread settings change how the encodes are processed.

Server1CommandLine=/port 1000 /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 16 /x265-threads 16
Server2CommandLine=/port 2000 /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 16 /x265-threads 16

Depending on how many core/threads your CPU has, you can change the 12's & 16's up or down to suit your setup.

Now this may not be as critical on lesser Ryzen's, but the 12 & 16 core cpu's, it can change things a LOT.

I know that rlev11 spent a lot of time with these settings, when he first got his 7950X, as did I...

It would be interesting to see what your current settings are, just to compare.

Worth a shot.

[Slogra]

I manually checked the delay with dgindex (included with ripbot264). I opened the vob, then save as project. Turns out the delay for the audiotracks is zero :).

In my experience, Makemkv does not deal with delays correctly. But i might be wrong, or it might be fixed in current versions.

I'm not a fan of Handbrake in general. I'm always struggling to get simple settings to work. In this case i needed 50fps deinterlace but there is no good option for that.

MKVtoolnix is a bit fuzzy about delay indeed. Last time i tried to set a delay, then reopened the same mkv, the delay was gone.


My next DVD will probably have delay, so i'll check how it goes with the newer version of ripbot264. But i gues it will not process the audio either.
I'll also start with the default config file, maybe that helps. Post edit: nope, same issue. No audio demuxed using Ripbot264 v1.27.0.


Btw this thread is somewhat related. http://forum.doom9.org/showthread.php?t=185162
In a nutshell. It's about h.265 GPU and deinterlacing in Handbrake. CPU encoding turns out much better though. I did encoding tests using x.264 with various filters and x.265 without filters. I ended up using x.265 veryfast 10bits without any filters.

[Slogra]

Ran into a case of broken chapters. The original video does have chapters, but as you can see the chapter file contains weird text.

Job1_log.txt:
mkvmerge v51.0.0 ('I Wish') 64-bit
Error: Unknown chapter file format in 'E:\Temp\RipBot264temp\job1\chapters.txt'. It does not contain a supported chapter format.


chapters.txt:

CHAPTER01=Codec config
CHAPTER01NAME=hvcC



I found this in the MediaInfo tab of MPC-HC, which might be related to the issue:

Menu #1
ID : 3
Codec ID : text
Duration : 21 min 55 s
Language : English
Bit rate mode : CBR
Menu For : 1,2
00:00:00.000 : (01)00:00:00:000
00:00:58.000 : (02)00:00:58:000
00:05:16.000 : (03)00:05:16:000
00:10:42.000 : (04)00:10:42:000
00:15:45.000 : (05)00:15:45:000
00:21:20.000 : (06)00:21:20:000
00:21:51.000 : (07)00:21:51:000
Bit rate mode : Constant

Menu #2
00:00:00.000 : (01)00:00:00:000
00:00:58.000 : (02)00:00:58:000
00:05:16.000 : (03)00:05:16:000
00:10:42.000 : (04)00:10:42:000
00:15:45.000 : (05)00:15:45:000
00:21:20.000 : (06)00:21:20:000
00:21:51.000 : (07)00:21:51:000

[tkwou]

I could get proven wrong with this, and as I haven't been using RipBot for several months I'm a little rusty.

But I recall, there were some changes made to assist DE, quite a while back, and you can edit the command line to modify how many cpu cores/threads are used, how x264 & x265 use the cpu, etc, and it can make a huge difference.

If you go into the RipBot264.ini file you will see similar to below, these thread settings change how the encodes are processed.

Server1CommandLine=/port 1000 /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 16 /x265-threads 16
Server2CommandLine=/port 2000 /priority normal /restart-if-no-progress /avisynth-prefetch-threads 12 /x264-threads 16 /x265-threads 16

Depending on how many core/threads your CPU has, you can change the 12's & 16's up or down to suit your setup.

Now this may not be as critical on lesser Ryzen's, but the 12 & 16 core cpu's, it can change things a LOT.

I know that rlev11 spent a lot of time with these settings, when he first got his 7950X, as did I...

It would be interesting to see what your current settings are, just to compare.

Worth a shot.
Thanks TDS, I was unaware that the ServerCommands needed to be adjusted. Encoding Server was only using 6 out of 12 threads. I reran the encode and it did help. Encode time dropped to 9:16 from 10:24 and the frame rate increased from 36.5 to 44.2 but the CPU was still not maxed out. I added a second server and the time dropped to 8:34 and the frame rate went up to 47.9. CPU was maxed out with both servers running. I'm still significantly below the 60.6 fps running with DE=off though. I will repeat this test with the 3600 and see if the results are different.

[tkwou]

I just realized it wasn't accepting the prefetch threads number I was using in the ServerCommand line. I have set it to 12 like the x264threads and now it's running much better.

5600G DE=off 5:54 @60.6fps
5600G DE=on 7:11 @56.1fps using 2 Encoding servers
3600 DE=off 5:25 @67.0fps
3600 DE=on 6:23 @62.2fps using 2 Encoding servers

So on my computers the overhead of running E client and E server does slow down the encoding rate about 7.5% compared to running in solo mode. I'm sure this is way less noticeable on 16 core machine. I'm surprised that I had to run 2 instances of ES to get the machines to max out the CPU's.

[guest]

I just realized it wasn't accepting the prefetch threads number I was using in the ServerCommand line. I have set it to 12 like the x264threads and now it's running much better.

5600G DE=off 5:54 @60.6fps
5600G DE=on 7:11 @56.1fps using 2 Encoding servers
3600 DE=off 5:25 @67.0fps
3600 DE=on 6:23 @62.2fps using 2 Encoding servers

So on my computers the overhead of running E client and E server does slow down the encoding rate about 7.5% compared to running in solo mode. I'm sure this is way less noticeable on 16 core machine. I'm surprised that I had to run 2 instances of ES to get the machines to max out the CPU's.

Wow, now that's a good result :)

Yep, that's another advantage of DE, you can just "load up" the cpu until it's maxed out (or more)..

You could even start experimenting with command line options in x265, that can also make some noticeable differences.

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

But x264, not so much :(

Keep tweaking....

Cheers.

[rlev11]

I just realized it wasn't accepting the prefetch threads number I was using in the ServerCommand line. I have set it to 12 like the x264threads and now it's running much better.

5600G DE=off 5:54 @60.6fps
5600G DE=on 7:11 @56.1fps using 2 Encoding servers
3600 DE=off 5:25 @67.0fps
3600 DE=on 6:23 @62.2fps using 2 Encoding servers

So on my computers the overhead of running E client and E server does slow down the encoding rate about 7.5% compared to running in solo mode. I'm sure this is way less noticeable on 16 core machine. I'm surprised that I had to run 2 instances of ES to get the machines to max out the CPU's.

Just curious so I understand, did you have the threads and prefetch threads as part of your command line and they were setup wrong, or was it just plain like this?
encodingserver /restart-if-no-progress /priority normal

I only use the threads and prefretch threads command lines on my 16 core ryzens so i don't have to remember to knock them down when doing 4k stuff. I lose a little on 1080 and below, but I don't have to remember to switch it when doing 4k stuff. I wouldn't think i have to manually set the threads on all my 12 cores and below servers (I just use the command above) in the server command. Might have to try setting the threads on a 12 or 8 core ryzen and see if there is a difference if you were using a bare command line to start the server. I just have a .bat file I load at startup on all my servers to load the encoding servers. My fps on the 6, 8 and 12 core servers look like they are comparable so I don't think I need to add them, but interesting none the less

And good call TDS on the threads command, would have never even thought of that....