View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
silentstrife
26th September 2019, 13:36
Compress whole job folder (without big files like video.mkv or audio files) and send IT to me. I will take a look...
Sorry to have troubled you. I re-installed my codec pack and that seems to have fixed what ever was causing my issue.
Have a good day.
byteshare
26th September 2019, 16:30
New x265 3.2
https://bitbucket.org/multicoreware/x265/raw/353572437201d551381002aebf20d244bd49ef17/doc/reST/releasenotes.rst
Version 3.2
===========
Release date - 25th September, 2019.
New features
------------
1. 3-level hierarchical motion estimation using :option:`--hme` and :option:`--hme-search`.
2. New AQ mode (:option:`--aq-mode` 4) with variance and edge information.
3. :option:`selective-sao` to selectively enable SAO at slice level.
Enhancements to existing features
---------------------------------
1. New implementation of :option:`--refine-mv` with 3 refinement levels.
Encoder enhancements
--------------------
1. Improved quality in the frames following dark scenes in ABR mode.
API changes
-----------
1. Additions to x265_param structure to support the newly added features :option:`--hme`, :option:`--hme-search` and :option:`selective-sao`.
Bug fixes
---------
1. Fixed encoder crash with :option:`--zonefile` during failures in encoder_open().
2. Fixed JSON11 build errors with HDR10+ on MacOS high sierra.
3. Signalling out of range scaling list data fixed.
4. Inconsistent output fix for 2-pass rate-control with cutree ON.
Known issues
------------
1. Build dependency on changeset cf37911 of SVT-HEVC.
Update: Thank you for updating RB!
byteshare
28th September 2019, 17:41
I have been having some slowness issues when doing any filters with my GPU, such as KNLmeans.
Looking at Process Explorer a bit more I realized that FFMpeg didn't show any GPU usage (GPU, GPU System Bytes, GPU Dedicated Bytes, GPU Committed Bytes)
If I run the RipBot script in AVSPmod I do see GPU System Bytes, GPU Dedicated Bytes, and GPU Committed Bytes showing usage.
The AVS Meter also behaves strangely, where the text fields go over the line and I have to scroll down to see all of the data.
The script runs in RipBot (just using the Adaptive KNLMeansCL in RipBot to test with) and a job will complete. The output looks like I expect just very slow to get it.
When running a job using KNLmeans I can't get a lot of CPU usage because my guess is the decoder (FFMpeg) can't supply enough to process). If I use a non-GPU filter the CPU can basically max out. Using non-DE mode at the moment.
Any ideas what is happening?
Atak_Snajpera
28th September 2019, 18:12
I have been having some slowness issues when doing any filters with my GPU, such as KNLmeans.
Looking at Process Explorer a bit more I realized that FFMpeg didn't show any GPU usage (GPU, GPU System Bytes, GPU Dedicated Bytes, GPU Committed Bytes)
If I run the RipBot script in AVSPmod I do see GPU System Bytes, GPU Dedicated Bytes, and GPU Committed Bytes showing usage.
The AVS Meter also behaves strangely, where the text fields go over the line and I have to scroll down to see all of the data.
The script runs in RipBot (just using the Adaptive KNLMeansCL in RipBot to test with) and a job will complete. The output looks like I expect just very slow to get it.
When running a job using KNLmeans I can't get a lot of CPU usage because my guess is the decoder (FFMpeg) can't supply enough to process). If I use a non-GPU filter the CPU can basically max out. Using non-DE mode at the moment.
Any ideas what is happening?
Run Process Explorer as Administrator to see GPU usage on ffmpeg.exe. You most likely have bottleneck on GPU. KNLMeansCL is extremely intensive even for most modern GPUs.
byteshare
29th September 2019, 04:11
Run Process Explorer as Administrator to see GPU usage on ffmpeg.exe. You most likely have bottleneck on GPU. KNLMeansCL is extremely intensive even for most modern GPUs.
Running it as Admin does show the bytes used.
Hmmm...now to figure out why I'm getting ~1-2FPS with a Geforce 980 and Ryzen 1700. I get without the GPU filter ~20FPS with the same x265 settings. I'm using about 1.7GB of GPU memory (of 4GB) from FFMpeg but the GPU core load (using Open Hardware Monitor) bounces between 0-13%.
I've been working "around" it by using other encoders to use more CPU on sources that don't need filters. I would use DE mode but the second server usually never starts.
I don't have an older version of RB to try, I think 1.23 but up to some point in 1.24 before something was changed. Is the one linked on the first page the first version of 1.24? I recall getting 8-12FPS with the same settings, granted different sources, but getting 1-2FPS on several sources with the most recent version of RBk./.
I'll try updating my drivers for now. update: didn't seem to make a different. I also changed the following to no avail: my power profile to high performance and same for the Nvidia Control Panel "Power management mode" to "Perfer maximum performance".
Atak_Snajpera
29th September 2019, 09:35
How many FPS do you get in avsmeter with only knlmeans enabled? 2fps on 1920x1080 is indeed very slow. I also get 2fps but on GeForce 710 (99% gpu usage)
byteshare
30th September 2019, 01:18
How many FPS do you get in avsmeter with only knlmeans enabled? 2fps on 1920x1080 is indeed very slow. I also get 2fps but on GeForce 710 (99% gpu usage)
With AVSMeter
KNLmeansCL h=2 27FPS 90-95% GPU
KNLmeansCL Adaptive h=2 ??FPS 80-90% GPU (AVSMeter shows the information scrolling so I can't see true FPS)
KNLmeansCL Adaptive + MD2 h=2 ??FPS 0-20% GPU (AVSMeter shows the information scrolling so I can't see true FPS)
In the OpenCL setup, I have x264 OpenCL acceleration set to no (none) device and KNLMeansCL set to Geforce GTX 980
Turning that on for x264 doesn't seem to help, but it does seem worse getting ~0.7 FPS.
Running same HEVC (not with AVSmeter) with just these filters: `FastLineDarkenMOD4().LSFmod()` (video is in the actual script, so I didn't forget that :D ) I'm getting ~12 FPS
Atak_Snajpera
30th September 2019, 10:05
Mdegrain2 running on CPU is a real bottleneck in your case. How many FPS do you get with mdegrain2 only?
duffbeer
30th September 2019, 16:31
I'm having an issue encoding audio to AC3 at the moment.
For some reason, RipBot produces an error any time I re-encode the audio to AC3. The error report states that the encoded audio file cannot be found.
My sources are either full disc structure or MKV. Sometimes with DTS audio and sometimes Dolby Atmos.
It always used to work perfectly so I'm not sure what has changed or whether it may be a local problem for me. Any ideas Atak?
Atak_Snajpera
30th September 2019, 17:12
I'm having an issue encoding audio to AC3 at the moment.
For some reason, RipBot produces an error any time I re-encode the audio to AC3. The error report states that the encoded audio file cannot be found.
My sources are either full disc structure or MKV. Sometimes with DTS audio and sometimes Dolby Atmos.
It always used to work perfectly so I'm not sure what has changed or whether it may be a local problem for me. Any ideas Atak?
You may try running manually jobx_EncodeAudioAll.cmd and then see what happens. I recommend doing this manually via console (cmd.exe) instead of just clicking on .cmd file.
byteshare
30th September 2019, 21:08
Mdegrain2 running on CPU is a real bottleneck in your case. How many FPS do you get with mdegrain2 only?
Can't get Mdegrain2 to work with AVSMeter, having the scrolling issue for some reason.
Had to run a job, used the same job that was getting ~12 FPS with these filters: `FastLineDarkenMOD4().LSFmod()`
Found I was only getting ~2FPS, so yeah, Mdegrain is the slow down (I was wrong, wasn't to do with my GPU, sorry), but (not using DEmode) only using ~33% (20%-40% seems to be the range) of the CPU during encode, so it seems the multiple processing threads isn't working for some reason? I have the "Limit to following filters only" unchecked.
Atak_Snajpera
30th September 2019, 21:56
Show me your full script
byteshare
1st October 2019, 03:51
Show me your full script
I ran it on a Ryzen 1700. I ran a similar test on a Ryzen 2700x and it is using more CPU ~60% in AVSmeter, which is showing correctly (not scrolling the data).
Update: Re-ran the above test after another reboot and an update to RB the AVSmeter isn't scrolling and not sure what you changed but it is using way more CPU and I'm getting ~9 FPS now!
Awesome, thank you!
byteshare
1st October 2019, 19:04
Something I'm noticing with the new update (now that my jobs are going faster!) is most of the jobs are failing at the remux step.
I don't think it is the filename, unless it is the "-" and if I manually run the batch file to make the video.265 it works fine and the video looks good.
I have at least 4 others I am able to see this happening on and two others that worked correctly. I am only encoding the video (skipping the demux step in the options to skip audio)
Update: Set my last update time to 2016, don't see any new updates, my Core is 2019.09.30.
Added a job that was failing again, and it failed again. only characters not ABC123, were brackets and a dash: "[" "]" "-"
duffbeer
2nd October 2019, 10:44
How does RipBot handle HDR10+? Does it get passed through to the encoded MKV file or is it converted to HDR10?
Atak_Snajpera
2nd October 2019, 11:05
No. You have to pass that data on your own.
cypher007
2nd October 2019, 11:43
Noticed when encoding some anime, using very slow and animation tunes, that my intel i5 9100f doesn’t use 100% cpu. It seems to max 2 cores and about 70-80% the other 4 cores.
The result is 2-4fps. But if I open taskmgr it will then creep upto 16fps, this is on the first pass of a 2 pass encode.
So when I left some encodes to run 2 took nearly 3 hrs for 23min of video. But then the last 2 took 45mins. As I think I checked the cpu usage.
It’s like rip bot is dozing until the pc is used.
Atak_Snajpera
2nd October 2019, 12:51
Most likely win10 is doing something "Smart". Change power profile to high performance
userx
2nd October 2019, 18:27
Hello
Is there any possibility to automatically delete source file after successful end of job?
Atak_Snajpera
2nd October 2019, 18:58
Hello
Is there any possibility to automatically delete source file after successful end of job?
Not yet. Maybe in next update.
slalom
2nd October 2019, 22:17
There is a problem
If I run a job again, the program doesn't overwrite the previous file. I have to rename the old, for the new to be created
EDIT
To be more precise, running CombineAllChunks.cmd, doesn't overwrite existing video.264/5 in jobx folder
EDIT 2
Delete previous line
Something else is happening and overwrite doesn't work
Ryushin
3rd October 2019, 13:18
Just wanted to bring this up again. I don't know how it would just be me though. I installed fresh versions of Ripbot264 a month or so ago and the 4K seamless branching is still causing issues. From a previous post:
I rip a 4K disc to the hard drive that has seamless branching, such as Incredibles 2. I then use Ripbot to pull in the movie and process it. The output will have out of sync audio towards the end of the movie. I think this only happens on 4K discs that are towards 2 hours or longer. Just had to go through this with Ralph Breaks the Internet and Snow White and the Huntsman Extended edition.
The work around I've been doing is to use MakeMKV to create a video file from the same source and then pull that into Ripbot to process it and it comes out fine.
This time the 4K disc in question is Ratatouille.
Is anyone else experiencing this?
byteshare
3rd October 2019, 15:28
Just wanted to bring this up again. I don't know how it would just be me though. I installed fresh versions of Ripbot264 a month or so ago and the 4K seamless branching is still causing issues. From a previous post:
I rip a 4K disc to the hard drive that has seamless branching, such as Incredibles 2. I then use Ripbot to pull in the movie and process it. The output will have out of sync audio towards the end of the movie. I think this only happens on 4K discs that are towards 2 hours or longer. Just had to go through this with Ralph Breaks the Internet and Snow White and the Huntsman Extended edition.
The work around I've been doing is to use MakeMKV to create a video file from the same source and then pull that into Ripbot to process it and it comes out fine.
This time the 4K disc in question is Ratatouille.
Is anyone else experiencing this?
Which decoder are you using? And what is your Core version?
Ryushin
3rd October 2019, 16:11
Which decoder are you using? And what is your Core version?
FFMS2 for the decoder and v1.25. Under tools, Core says 2019.09.01.
byteshare
3rd October 2019, 16:31
FFMS2 for the decoder and v1.25. Under tools, Core says 2019.09.01.
You're using an old version, should be 2019.09.30 for the core
cypher007
3rd October 2019, 20:36
Most likely win10 is doing something "Smart". Change power profile to high performance
I’ll try putting it on high performance and see what happens.
GZZ
3rd October 2019, 21:04
Just wanted to bring this up again. I don't know how it would just be me though. I installed fresh versions of Ripbot264 a month or so ago and the 4K seamless branching is still causing issues. From a previous post:
I rip a 4K disc to the hard drive that has seamless branching, such as Incredibles 2. I then use Ripbot to pull in the movie and process it. The output will have out of sync audio towards the end of the movie. I think this only happens on 4K discs that are towards 2 hours or longer. Just had to go through this with Ralph Breaks the Internet and Snow White and the Huntsman Extended edition.
The work around I've been doing is to use MakeMKV to create a video file from the same source and then pull that into Ripbot to process it and it comes out fine.
This time the 4K disc in question is Ratatouille.
Is anyone else experiencing this?
Be carefull with MakeMKV, it has issues with Disney/Pixar Animation. I think its because of the seamless branching. I had alot of issue where ripbot will reject it saying it didnt have any audio. It turned out that MakeMKV does a poor job and there was a glitch in the movie and audio. I then switched to MKVToolNix to rip the main movie and it seem to do a proper job and havent got any AV sync issues.
Ryushin
4th October 2019, 12:03
You're using an old version, should be 2019.09.30 for the core
Updated to the latest version and it is still doing the same thing.
Be carefull with MakeMKV, it has issues with Disney/Pixar Animation. I think its because of the seamless branching. I had alot of issue where ripbot will reject it saying it didnt have any audio. It turned out that MakeMKV does a poor job and there was a glitch in the movie and audio. I then switched to MKVToolNix to rip the main movie and it seem to do a proper job and havent got any AV sync issues.
I'll keep an eye out for that. I'm using the MakeMKV for Linux and at least for me, it is making mkv files that are synced correctly and I import those into RipBot and I get the good output that is synced.
This only seems to occur on 4K content. Blu-ray seamless branching seems to work great and I have no issues.
GZZ
4th October 2019, 13:50
This only seems to occur on 4K content. Blu-ray seamless branching seems to work great and I have no issues.
I only had issue with Disney/Pixar and MakeMKV, I use it for all other movies without issue. So thinking its the way Disney/Pixar 4k UHD is created.
byteshare
4th October 2019, 18:17
There is a problem
If I run a job again, the program doesn't overwrite the previous file. I have to rename the old, for the new to be created
EDIT
To be more precise, running CombineAllChunks.cmd, doesn't overwrite existing video.264/5 in jobx folder
EDIT 2
Delete previous line
Something else is happening and overwrite doesn't work
For me it seems if I open RB, start jobs, abort, and then without restarting RB start the jobs again at the end of a job it won't mux.
--Update, might be more to it but I'm having the issue on more than one machine for jobs not muxing at the end (was only using one for a bit), so two separate machines with different sources running DE mode locally.
Running The batch CombineAllChunks then job1_MuxFiles works fine when I do it manually, so for now I'm run the combineallchunks then the jobxx_muxfiles batch manually. :/
"Z:\Temp\RipBot264temp\job1\video.265"
mkvmerge v37.0.0 ('Leave It') 64-bit
Error: The file 'Z:\Temp\RipBot264temp\job1\video.265' could not be opened for reading: open file error.
Side thing: I see .lwi files being made even though I have it set to FFMS2, is that intentional and if so why?
Atak_Snajpera
5th October 2019, 09:33
.lwi file is always created in order to avoid huge delay when you decide to switch from ffms2 to lsmash (indexing may take few minutes)
byteshare
5th October 2019, 16:19
.lwi file is always created in order to avoid huge delay when you decide to switch from ffms2 to lsmash (indexing may take few minutes)
Oh, didn't realize that was happening, but I also didn't realize that each job was getting muxed twice until with a more recent version it started breaking on me....
The more you know :D
Thank you for answering.
--To be clear the muxing issue isn't all of the time. If I can get it to work once then the following jobs keep working. Right now I've been restarting a job until it doesn't fail and then the jobs after work...then I don't touch anything because even adding more jobs seems to have a possibility of breaking it again.
slalom
6th October 2019, 08:43
For me it seems if I open RB, start jobs, abort, and then without restarting RB start the jobs again at the end of a job it won't mux.
--Update, might be more to it but I'm having the issue on more than one machine for jobs not muxing at the end (was only using one for a bit), so two separate machines with different sources running DE mode locally.
Running The batch CombineAllChunks then job1_MuxFiles works fine when I do it manually, so for now I'm run the combineallchunks then the jobxx_muxfiles batch manually. :/
"Z:\Temp\RipBot264temp\job1\video.265"
mkvmerge v37.0.0 ('Leave It') 64-bit
Error: The file 'Z:\Temp\RipBot264temp\job1\video.265' could not be opened for reading: open file error.
Side thing: I see .lwi files being made even though I have it set to FFMS2, is that intentional and if so why?
When the DE finishes, the next job starts. At least the files are there to do it manually
userx
6th October 2019, 13:17
Can report same behavor. CombineAllChunks.cmd has to be started manually. D:\Temp\RipBot264temp\job8\video.264 is not created before job8_MuxFiles.cmd is executed.
Very annoying. Some jobs succeeded and after any point all jobs finish with ERROR and no output files is created.
mparade
6th October 2019, 13:30
Your program is what I have been looking for in the past…
thank you very much!
In the past I used DGDecNV for video decoding, which is the preferred (most reliable if I can say something like this) one in Ripbot?
I think sometimes I would like to use some denoiser on my sources (very rarely when bitrates are getting higher very much). Do you have some guidelines when to use which?
I am reencoding only high bitrate HD sources but sometimes grain, noise doesn't let me reduce the bitrate in the amount I would like to.
Distributed encoding is just amazing on my 32 cores! I have never seen anything like this in other programs.
Thank you very much for your amazing program.
Atak_Snajpera
6th October 2019, 17:38
In the past I used DGDecNV for video decoding, which is the preferred (most reliable if I can say something like this) one in Ripbot?
LSMASH
I think sometimes I would like to use some denoiser on my sources (very rarely when bitrates are getting higher very much). Do you have some guidelines when to use which?
Just activate MDegrain2
byteshare
7th October 2019, 16:42
If anyone missed it. New update to x265 (3.2+5), MKVtoolnix (38.0.0), and Core (2019.10.06)
Thank you for the update.
How do we use the "Run Script after finished job"?
Atak_Snajpera
7th October 2019, 17:24
How do we use the "Run Script after finished job"?
What do you mean?
byteshare
7th October 2019, 17:30
What do you mean?
I don't see an option/where to define what script it will run, unless it is an internal script?
I can check it but I don't see what it does, so I don't know how to use it.
--Oh, thank you for adding GPU as a option in the settings for decoders and not just a right click option. Other than needing Intel or NVidia to use, any downsides to it over FFMS2 or LSMASH?
Atak_Snajpera
7th October 2019, 17:53
I don't see an option/where to define what script it will run, unless it is an internal script?
Just check Job finished successfully.cmd and Job finished with error.cmd
byteshare
7th October 2019, 18:00
Just check Job finished successfully.cmd and Job finished with error.cmd
Ah, thank you!
Dhry
7th October 2019, 20:41
I'm also encountering the video.265 could not be opened for reading: open file error issue. Started after a recent update, everything worked perfectly fine for months before, through multiple previous updates. And I too discovered that running the CombineAllChunks then then jobx_MuxFiles scripts manually will complete the process. Please fix.
Also, separate question: Are there any plans for a Linux encodingserver? I have a couple of Linux machines that I'd like to throw into the farm.
Thanks for the software, it's fantastic!
Dhry
Atak_Snajpera
7th October 2019, 22:42
Install windows (win10 works without activation forever) on virtual machine and you are good to go.
mparade
7th October 2019, 23:12
should I ignore it?:
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling
byteshare
8th October 2019, 06:57
I'm also encountering the video.265 could not be opened for reading: open file error issue. Started after a recent update, everything worked perfectly fine for months before, through multiple previous updates. And I too discovered that running the CombineAllChunks then then jobx_MuxFiles scripts manually will complete the process. Please fix.
Make sure you're on core 2019.10.06 and you should be good to go. I suspect you're on an older version.
LigH
8th October 2019, 07:23
should I ignore it?:
Possibly yes. Your x264 build does not support hardware acceleration (if there is a speed-up at all), but that doesn't keep it from finishing its job correctly with usual CPU routines only.
There may be x264 builds out there which can use some OpenCL functions of a modern GPU. So you might replace xour x264 executable; but I won't guarantee that they work correctly with RipBot264, they might interfere with other filters using the GPU too, even. Test and get experienced.
mparade
8th October 2019, 15:35
Thank you very much.
DTS-HD MA 5.1 audio track was identified as 2.0 by Ripbot.
After reading input stream only stereo profiles were available from the list.
Dhry
8th October 2019, 15:42
Make sure you're on core 2019.10.06 and you should be good to go. I suspect you're on an older version.
That was correct. However, this morning it auto-updated, I tried a test 265 encode and it worked fine. Cheers!
byteshare
8th October 2019, 16:28
That was correct. However, this morning it auto-updated, I tried a test 265 encode and it worked fine. Cheers!
You should re-create the jobs if it just updated (the ones that haven't been processed).
Dhry
8th October 2019, 17:29
You should re-create the jobs if it just updated (the ones that haven't been processed).
No need. For the jobs that died, the folders are still there and all I need to do is to manually run the two existing scripts to combine and remux and all's well.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.