View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
Atak_Snajpera
17th August 2024, 18:18
Looks like AviSynth+ default is 4GB according to the wiki. 1080p does not come close to that, I saw about 2 gig for ffmpeg during a 1080 run,
Thanks....
What is the lowest memory value without performance drop? 8192?
Boulder
17th August 2024, 18:45
Looks like AviSynth+ default is 4GB according to the wiki. 1080p does not come close to that, I saw about 2 gig for ffmpeg during a 1080 run,
Thanks....
"DefaultMemoryMax = minimum(physical_memory / 4, secondary_memory_max_limit)" with maximum limit at that 4GB.
I'm just a bit confused if it's actual installed physical memory, or free memory as mentioned in the wiki.
8GB would probably match most cases.
rlev11
17th August 2024, 18:46
What is the lowest memory value without performance drop? 8192?
I will let you know tomorrow
Guest
18th August 2024, 07:59
I will let you know tomorrow
I've been fiddling around with this all afternoon, and not too sure if I have it going any better, or not, but it's easy to make it worse....
The memory value doesn't have a huge difference, but I would suggest probably not going below 16384...
But one thing if this call SetCacheMode(CACHE_OPTIMAL_SIZE) is added to a script, it's not too good, I've found that SetCacheMode() seems the best.
SetCacheMode(mode)
AVS+Fine tunes the internal frame caching strategy in AviSynth+.
Available values:
0 or CACHE_FAST_START start up time and size balanced mode (default)
1 or CACHE_OPTIMAL_SIZE slow start up but optimal speed and cache size
since Avisynth+ 3.6.1
And video=Prefetch(video,32,16) doesn't do a lot, either :(
Guest
18th August 2024, 10:57
Atak,
I would like to make you aware that apparently upcoming x265 builds have been altered/updated, call it what you will, but app's that use it may have to edit the way that x265 commands are written...
I have been chatting with LigH, and he has been kind enough to show what needs to be done, so please go here, and have a little read:-
https://forum.doom9.org/showthread.php?p=2005750#post2005750
And before you say that I shouldn't be using modded builds, even the latest "vanilla" builds are having the same "problem".
If you download this build and try it for yourself, then you might be able to figure out what needs to be done with RB.
https://forum.doom9.org/showthread.php?p=2005647#post2005647
LigH
18th August 2024, 13:44
I did not compile a "modded" build. Only a very recent one. Multicoreware changed the rules for the CLI parsing because they need it to support multiple input streams for MVC.
rlev11
18th August 2024, 17:01
What is the lowest memory value without performance drop? 8192?
Ran the same tests with GOT with same Mdegrain3-200, running the job1_EncodeVideoPass1.cmd manully.
First thing I found is SetCacheMode(CACHE_OPTIMAL_SIZE) make little if any difference. In fact SetCacheMode() appears to a a couple percent faster.
Ran the same script changing the SetMemoryMax(xxxxx) number and came up with the following numbers which I recorded when the job went to 2% on each run.
4096 - 2.28fps
5120 - 4.52fps
6144 - 6.15fps
8192 - 6.50fps
10240 - 6.50fps
16384 - 6.51fps
So looks like 8192 at least in this case is the magic number. Is similar to what I see when changing prefetch threads to 12. I still have not done these same tests on my 3950x, 5950x, or i7-14700 to make sure I see similar results but it would make sense if it did.
Atak, I can do any additional testing you want with my variety of high core cpu's. I understand the complexity of taking a small testing sample and thinking about how best to incorporate anything into a program update. If you would rather take this offline for now, just PM me and we can setup anything you want as far as testing.
Additional testing has showed setting the 3950x and 5950x to prefetch=16 and the 14700 to prefetch=20 with the SetMemoryMax(8192) shows the same improvement as the 7950x
rlev11
18th August 2024, 20:32
So it is looking like this effort is having some positive results for me now. End result is now we no longer have to cripple the thread count of the high core cpu's down to 12-14 when doing 4k encoding regardless of using the built in mdegrain or in my case using a custom smdegrain script.
The bottleneck for 4k encoding is the avisynth max memory setting. For both mdegrain and my custom smdegrain scripts having SetMemoryMax(8192) restores performance on the high core cpu's in my results I am seeing. I tried 16384 and saw very little difference (1-3%) so no need to go above 8192 unless you need to for other reasons.
So now I will set prefetch threads to number of physical cores regardless on all servers, add in SetCacheMode() and SetMemoryMax(8192) to all my custom degraining scripts, and enjoy a little better performance over my previous method of crippling my R9's to 12 prefetch threads. Back to using my full 13 server distributed encoding farm, On my same GOT test I have been using, using SetMemoryMax(8192) was about 7% faster than prefetch=12 in total fps. This should also speed up 1080p and below a bit since I don't have to remember to switch the high core encoding servers to full prefetch (16 or 20 depending on the cpu)
Not sure how this may translate to other users workflows though, guess time will tell... but thanks for suggestions and input on this issue that has been bugging me for years now
Guest
19th August 2024, 02:59
So it is looking like this effort is having some positive results for me now. End result is now we no longer have to cripple the thread count of the high core cpu's down to 12-14 when doing 4k encoding regardless of using the built in mdegrain or in my case using a custom smdegrain script.
I still think you should be using SMD scripts for your tests, as you so rarely use MD, and the results could be quite different !!!
The bottleneck for 4k encoding is the avisynth max memory setting. For both mdegrain and my custom smdegrain scripts having SetMemoryMax(8192) restores performance on the high core cpu's in my results I am seeing. I tried 16384 and saw very little difference (1-3%) so no need to go above 8192 unless you need to for other reasons.
Also interesting that you've "settled" for only 8192, when (in your previous post), 16384 was a smidgen faster.....I tested up to 32768, and even tho there was only a very slight difference between the three, 32 was faster.
So now I will set prefetch threads to number of physical cores regardless on all servers, add in SetCacheMode() and SetMemoryMax(8192) to all my custom degraining scripts, and enjoy a little better performance over my previous method of crippling my R9's to 12 prefetch threads. Back to using my full 13 server distributed encoding farm, On my same GOT test I have been using, using SetMemoryMax(8192) was about 7% faster than prefetch=12 in total fps. This should also speed up 1080p and below a bit since I don't have to remember to switch the high core encoding servers to full prefetch (16 or 20 depending on the cpu)
Your comment (also in the previous post) regarding SetCacheMode(CACHE_OPTIMAL_SIZE), I totally agree, it slowed things down, for me, and SetCacheMode() was the best option :)
There was no mention of the Prefetch threads/frames setting ?? did you try it ??
I have also tweaked several other settings that dramatically change the speed, but the proof will be when encoding full length movies, etc, not just small test samples
Not sure how this may translate to other users workflows though, guess time will tell... but thanks for suggestions and input on this issue that has been bugging me for years now
Exactly, depends so much on hardware setup, scripts used....lot's of variables.
My testing will continue for a little while yet, just to be sure.
The next obstacle, is the new generation of x265...that WILL need to be addressed, soon.
Juha
26th August 2024, 19:30
Is it anyway possible to customize audio options? I have source material that has PCM and DTS audio tracks. They both have 2 channels. I'd like to convert them to AAC and use 256 Kbps at least but Ripbot doesn't allow to use higher bitrate for 2 channel AAC audio than 128 Kbps.
I tried to mess around in the program settings but despite what changes I make there, I get no different options.
Atak_Snajpera
26th August 2024, 22:30
Profiles/Audio.txt
Guest
27th August 2024, 03:46
Profiles/Audio.txt
Audio.txt
2.0 OPUS CODEC 64 kbps [abr]
2.0 OPUS CODEC 96 kbps [abr]
2.0 OPUS CODEC 128 kbps [abr]
5.1 OPUS CODEC 160 kbps [abr]
5.1 OPUS CODEC 240 kbps [abr]
5.1 OPUS CODEC 320 kbps [abr]
7.1 OPUS CODEC 224 kbps [abr]
7.1 OPUS CODEC 336 kbps [abr]
7.1 OPUS CODEC 448 kbps [abr]
2.0 FHG AAC-HE 64 kbps [abr]
2.0 FHG AAC-LC 96 kbps [abr]
2.0 FHG AAC-LC 128 kbps [abr]
2.0 FHG AAC-LC 256 kbps [abr]
5.1 FHG AAC-HE 192 kbps [abr]
5.1 FHG AAC-LC 256 kbps [abr]
5.1 FHG AAC-LC 320 kbps [abr]
7.1 FFMPEG AAC 384 kbps [abr]
7.1 FFMPEG AAC 448 kbps [abr]
7.1 FFMPEG AAC 640 kbps [abr]
2.0 FFMPEG AC3 192 kbps [cbr]
2.0 FFMPEG AC3 224 kbps [cbr]
2.0 FFMPEG AC3 256 kbps [cbr]
5.1 FFMPEG AC3 384 kbps [cbr]
5.1 FFMPEG AC3 448 kbps [cbr]
5.1 FFMPEG AC3 640 kbps [cbr]
2.0 FFMPEG FLAC ??? kbps [vbr]
5.1 FFMPEG FLAC ??? kbps [vbr]
7.1 FFMPEG FLAC ??? kbps [vbr]
Well, I know my crystal ball doesn't work, are you trying to suggest that it can be simply added to this list ??
UPDATE:- I thought I'd try this, and it indeed add's it to the Profile options for the job, I guess the proof is in the pudding if it actually encodes it to that setting.
Juha
28th August 2024, 15:37
I tested editing that text file. I managed to convert with that custom value. Thanks!
Another question if you don't mind... :)
I wonder what would be sane values when denoising a specific grainy video?
Sample pics:
Original video: https://images2.imgbox.com/0d/ce/X8DX3n8B_o.png
Used Degrain3, 400 : https://images2.imgbox.com/91/c9/EUoz0E3G_o.png
Used Degrain3, 800 : https://images2.imgbox.com/08/e5/yKAB34TV_o.png
Sample pics2:
Original video: https://images2.imgbox.com/d5/50/loTDbpNr_o.png
Used Degrain3, 400 : https://images2.imgbox.com/79/78/Pec7u2cb_o.png
Used Degrain3, 800 : https://images2.imgbox.com/4d/6d/FlrBBok1_o.png
What I'm asking is second a second opinion - do you think those values are reasonable / do those pictures look good? Personally I think both of them look good to me. I'm just worried that Degrain3 800 would be too much.
Guest
28th August 2024, 15:44
I tested editing that text file. I managed to convert with that custom value. Thanks!
Good to know that you sorted the audio situation :)
SMDegrain would probably do better (but that's a whole different story)..
It doesn't really matter what other ppl might say..if it looks good to you, that's all that matters.
TBH, your source file is pretty bad, what resolution is that ??
rlev11
29th August 2024, 01:53
I tested editing that text file. I managed to convert with that custom value. Thanks!
Another question if you don't mind... :)
I wonder what would be sane values when denoising a specific grainy video?
Sample pics:
Original video: https://images2.imgbox.com/0d/ce/X8DX3n8B_o.png
Used Degrain3, 400 : https://images2.imgbox.com/91/c9/EUoz0E3G_o.png
Used Degrain3, 800 : https://images2.imgbox.com/08/e5/yKAB34TV_o.png
Sample pics2:
Original video: https://images2.imgbox.com/d5/50/loTDbpNr_o.png
Used Degrain3, 400 : https://images2.imgbox.com/79/78/Pec7u2cb_o.png
Used Degrain3, 800 : https://images2.imgbox.com/4d/6d/FlrBBok1_o.png
What I'm asking is second a second opinion - do you think those values are reasonable / do those pictures look good? Personally I think both of them look good to me. I'm just worried that Degrain3 800 would be too much.
I don't think that I have ever used anything more than Mdegrain3-400 on even my most grainy sources. I use smdegrain now but even with that I would use something equivalent in degraining strength.
There is a point in my eyes where too much degraining can cause adverse picture quality. Where I would notice it in particular would be peoples foreheads when there is motion. I would notice the pores get washed out really bad and get "plastic" looking. then when stopped the pores would return.
I also hate film grain so there is a fine balance between too little and too much degraining.
I'm pretty much to the point now where I only use 3 different strengths. Very little grain , some grain , a lot of grain. I watch a couple scenes of a video and just pick the one I feel is the closest and go with it. You will never completely eliminate a heavy grained source and retain all the detail. Even something like Topaz AI is going to struggle with that.
Juha
29th August 2024, 18:51
TBH, your source file is pretty bad, what resolution is that ??
Believe it or not, but it's an uncompressed Full HD H264 video from a Blu-Ray disc... It's a 90's movie.
I don't think that I have ever used anything more than Mdegrain3-400 on even my most grainy sources. I use smdegrain now but even with that I would use something equivalent in degraining strength.
There is a point in my eyes where too much degraining can cause adverse picture quality. Where I would notice it in particular would be peoples foreheads when there is motion. I would notice the pores get washed out really bad and get "plastic" looking. then when stopped the pores would return.
I also hate film grain so there is a fine balance between too little and too much degraining.
I'm pretty much to the point now where I only use 3 different strengths. Very little grain , some grain , a lot of grain. I watch a couple scenes of a video and just pick the one I feel is the closest and go with it. You will never completely eliminate a heavy grained source and retain all the detail. Even something like Topaz AI is going to struggle with that.
After giving some thought to this I think I'll use 800 in my case. The difference between 400 and 800 looks quite marginal and I feel that even stronger degraining could be used but I guess it's better not to overdo it. This looks good to me.
Thanks for replies.
Guest
1st September 2024, 12:23
I just wanted to post something about this again, as it will need to be addressed sometime soon.
For the users that like to update RB manually, any recent x265 builds, will produce an error like this :-
""\\RYZEN-9-7950X\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\RYZEN-9-7950X\RipBot264temp\job3\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | "\\RYZEN-9-7950X\Ripbot264temp\tools\x265\x265_x64.exe" --seek 0 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --crf 16 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 3610 --sar 1:1 --level 5.2 --profile main10
--output-depth 10 --ctu 64 --high-tier --vbv-bufsize 240000 --vbv-maxrate 240000 --y4m --pools "32" --output "\\RYZEN-9-7950X\RipBot264temp\job3\Chunks\1.265" -"
x265 [WARN]: extra unused command arguments given <->
Juha
4th September 2024, 12:03
I ripped my first 4K movie. For testing purposes, I made two rips of it:
- 4K resolution rip
- Full HD resolution rip (resized original 4K to Full HD)
I used the setting to crop black bars but Ripbot only cropped black bars from 4K rip. 4K -> Full HD rip didn't get black bars cropped.
I suspect it's because I didn't choose "custom" as the output resolution, but if I crop something, shouldn't it always be taken into account even if I choose a predefined resize option?
4K rip: https://images2.imgbox.com/07/ad/hd6GSBcs_o.png
Full HD rip: https://images2.imgbox.com/b9/ca/j4n4wjg7_o.png
(Screenshots were taken by using MPC's native "save image" function.)
Cropping / resize settings in Ripbot I used for the Full HD rip: https://images2.imgbox.com/da/a4/vBf2sUmF_o.png
Resolution of the output 4K rip is 3840 x 1600. Full HD rip is 1920 x 1080.
Guest
4th September 2024, 12:49
I ripped my first 4K movie. For testing purposes, I made two rips of it:
- 4K resolution rip
- Full HD resolution rip (resized original 4K to Full HD)
I used the setting to crop black bars but Ripbot only cropped black bars from 4K rip. 4K -> Full HD rip didn't get black bars cropped.
I suspect it's because I didn't choose "custom" as the output resolution, but if I crop something, shouldn't it always be taken into account even if I choose a predefined resize option?
4K rip: https://images2.imgbox.com/07/ad/hd6GSBcs_o.png
Full HD rip: https://images2.imgbox.com/b9/ca/j4n4wjg7_o.png
(Screenshots were taken by using MPC's native "save image" function.)
Cropping / resize settings in Ripbot I used for the Full HD rip: https://images2.imgbox.com/da/a4/vBf2sUmF_o.png
Resolution of the output 4K rip is 3840 x 1600. Full HD rip is 1920 x 1080.
Have you tested them on your TV ??
Juha
4th September 2024, 19:56
No issues when viewing on TV. Just that they (black bars) are unnecessary and waste of bitrate / encoding time. Not necessarily much but still.
rlev11
4th September 2024, 23:16
I ripped my first 4K movie. For testing purposes, I made two rips of it:
- 4K resolution rip
- Full HD resolution rip (resized original 4K to Full HD)
I used the setting to crop black bars but Ripbot only cropped black bars from 4K rip. 4K -> Full HD rip didn't get black bars cropped.
I suspect it's because I didn't choose "custom" as the output resolution, but if I crop something, shouldn't it always be taken into account even if I choose a predefined resize option?
4K rip: https://images2.imgbox.com/07/ad/hd6GSBcs_o.png
Full HD rip: https://images2.imgbox.com/b9/ca/j4n4wjg7_o.png
(Screenshots were taken by using MPC's native "save image" function.)
Cropping / resize settings in Ripbot I used for the Full HD rip: https://images2.imgbox.com/da/a4/vBf2sUmF_o.png
Resolution of the output 4K rip is 3840 x 1600. Full HD rip is 1920 x 1080.
What you want to do when downsizing like what you are doing is after you do the autocrop, in your case will show 280 pixels for top and bottom. When you do the resize, choose the second to the bottom, which will be custom (and the aspect ratio) in your case Custom [2.40:1]. Then in the width section, change 3840 to 1920. Height will automatically change to 800 then in your case.
This way you will get what you are trying to do is downsize the encode without encoding the black bars. Doing the 1920x1080 [2.40:1] will encode it at the resolution specified which would be 1920x1080, but will just put the flag into the stream that it is a 2.4:1 aspect ratio.
This way only works if the aspect ratio is one of the presets built into ripbot. I think what is in now is 1.78,1.85,2.0,2.35, and 2.4.
If the pixels are just a few off just choose the preset that it shows, So if the autocrop shows 2.394:1 just choose the 2.40 and go. you will not notice those couple of pixels added or missing.
If it is not really close to one of the presets for something oddball, just get out the calculator and figure out what the 1920 x height number is (round up or down if not a full pixel) by using the SAR number from the autocrop if you have black bars on top and bottom. Vertical bars you would do the same except take 1080 times the SAR number. So a SAR of 1.5 would be 1620x1080.
This is where you would use the bottom custom resize setting that lets you choose both width and height. Bottom line is for horizontal bars use 1920 as the width and calculate the height, and for vertical bars use a height of 1080 and calculate the width.
Guest
5th September 2024, 01:08
No issues when viewing on TV. Just that they (black bars) are unnecessary and waste of bitrate / encoding time. Not necessarily much but still.
So if it plays OK on your TV, and if you've got a reasonably powerful CPU, then why bother....I rarely crop.
And after rlev11's excellent explanation, it might take you longer to "set it up" than how much longer those black bars take to process, and from what I understand, if you don't get it right, then you'll have to do it all over again....just sayin'.
Guest
5th September 2024, 01:08
what you want to do when downsizing like what you are doing is after you do the autocrop, in your case will show 280 pixels for top and bottom. When you do the resize, choose the second to the bottom, which will be custom (and the aspect ratio) in your case custom [2.40:1]. Then in the width section, change 3840 to 1920. Height will automatically change to 800 then in your case.
This way you will get what you are trying to do is downsize the encode without encoding the black bars. Doing the 1920x1080 [2.40:1] will encode it at the resolution specified which would be 1920x1080, but will just put the flag into the stream that it is a 2.4:1 aspect ratio.
This way only works if the aspect ratio is one of the presets built into ripbot. I think what is in now is 1.78,1.85,2.0,2.35, and 2.4.
If the pixels are just a few off just choose the preset that it shows, so if the autocrop shows 2.394:1 just choose the 2.40 and go. You will not notice those couple of pixels added or missing.
If it is not really close to one of the presets for something oddball, just get out the calculator and figure out what the 1920 x height number is (round up or down if not a full pixel) by using the sar number from the autocrop if you have black bars on top and bottom. Vertical bars you would do the same except take 1080 times the sar number. So a sar of 1.5 would be 1620x1080.
This is where you would use the bottom custom resize setting that lets you choose both width and height. Bottom line is for horizontal bars use 1920 as the width and calculate the height, and for vertical bars use a height of 1080 and calculate the width.
wow !!!
Atak_Snajpera
5th September 2024, 11:55
So if it plays OK on your TV, and if you've got a reasonably powerful CPU, then why bother....I rarely crop.
And after rlev11's excellent explanation, it might take you longer to "set it up" than how much longer those black bars take to process, and from what I understand, if you don't get it right, then you'll have to do it all over again....just sayin'.
Are you sure about that?
1920x1080 + MDegrain2 400
https://i.postimg.cc/PrSFGVq8/Capture1.png
1920x800 + MDegrain2 400
https://i.postimg.cc/cL6kd7Kk/Capture2.png
You basically get ~16% faster script processing for free. Add x265 encoder and it may go up to ~20% total.
Here We call this optimization...
Guest
5th September 2024, 13:03
Here We call this optimization...
Ha, not everything needs to be cropped, and some it's a little complicated.
Autocrop can sometimes not do the job properly, and I'm not going to get the calculator out.
If it looks OK on the TV, WGAF !!, I did a crop test a week or so ago, and it looked the same....
Atak_Snajpera
5th September 2024, 13:06
Ha, not everything needs to be cropped, and some it's a little complicated.
Autocrop can sometimes not do the job properly, and I'm not going to get the calculator out.
If it looks OK on the TV, WGAF !!, I did a crop test a week or so ago, and it looked the same....
You still do not understand why we crop... I'm out.
Guest
5th September 2024, 13:24
You still do not understand why we crop... I'm out.
Well, you're not good at explaining anything, we all seem to need a crystal ball, you just expect us to know..
I'd like to say more, but I don't want to get banned.....
Boulder
5th September 2024, 13:59
There's no reason not to crop. The borders are not always totally black and also may contain (invisible) compression artifacts which affect the bitrate needed.
Cropping has been a strong recommendation since I started working with video stuff over 20 years ago.
Guest
5th September 2024, 15:36
There's no reason not to crop. The borders are not always totally black and also may contain (invisible) compression artifacts which affect the bitrate needed.
Cropping has been a strong recommendation since I started working with video stuff over 20 years ago.
I have never cropped, unless it's a strange ratio to start with, or old 4:3 stuff.
And I've been encoding for 20+ years too....
rlev11
5th September 2024, 16:03
Going back to my test video of ST Strange new worlds in 4k. Original pixels is 3840x2160, but in a 2.4:1 aspect ratio so there are 560 horizontal lines of black space. If I encode it without an autocrop (x265 and using Smdegrain...), my test chunk on my 7950x shows 14.06 fps. That same chunk with an autocrop so encoding 3840x1600 comes out at 19.83 fps. That like a 29% increase in speed at the expense of 2 extra clicks. Resizing that down to 1080p takes 3 more clicks and typing in 1920. And "getting the calculator out" would be very rare if only downsizing an oddball aspect ratio.
To each his own, but I will keep cropping useless data and enjoy the speed increase for the time of a few extra clicks....
rlev11
5th September 2024, 20:23
And just if anyone is interested, I just replace my 7950x with a 9950x. Doing a couple test runs looks like I am pushing about a 10-15% speed increase over the 7950x. Watching Ryzen Master I am also seeing about a 10 degree C decrease in cpu temp. Both were on the same 360mm Arctic 3 AIO. All I had set before with the 7950x in PBO was a hard thermal limit. Where the 7950x would top out my hard limit of 85 degrees C, the 9950x is sitting around 75C with the cpu utilization in task manager still running at 100%. I haven't changed anything in the bios after it reset everything on the CPU change, so I need to look to see if I can push things a bit more from seeing the lower temps. The 9950x is supposed to have a limit of 95C, I won't push it that much, but I think I can get a few more percent increase pushing it up so it hits that same 85C hardline i set.
I've read that the new Win11 update due out later this fall is supposed to really help boost Zen5, not sure if that is just gaming or everything, but will be interesting to see if it boosts encoding speed as well...
Ryushin
6th September 2024, 13:05
Cropping also helps with displays that are not 16:9. Some projectors screens are configured for 2.40:1 and a lot of mobile phones are around that same aspect ratio. Reverse also helps when watching 4:3 content on a 16:10 screen.
I only encode the back bars when I'm doing foreign movies and I want to push the subtitles into the black bars.
Wishbringer
13th September 2024, 10:46
anyone knows, what was the latest build of x265, that worked out of the box with RB?
Thanks
LigH
13th September 2024, 13:03
Probably v3.6+35, before alpha channel support was added. Or v3.6+46, after alpha but before multi-view.
Wishbringer
13th September 2024, 16:01
@LigH: for me 3.6-46 (your build) worked. 3.6-56 didn't start anymore in RB, so I stay at -46... Or are there other inter builds?
LigH
13th September 2024, 16:08
Not really, MultiCoreWare released patches in batches. You might try to select a specific patch but will risk that a feature depends on several patches at the same time.
Wishbringer
13th September 2024, 18:24
Before the patches to support MVC were committed, specifying the input file name for x265 was optional.
Now that x265 may be able to read multiple input sources, it may also be mandatory now to specify them with a preceding parameter "--input".
@Atak_Snajpera:
Solution is really simple.
In jobX_EncodeVideoPassX.cmd just add "--input" before the last "-"
As a workaround it would be so simple even for us to add "--input -" in profiles, but then still the last "-" in cmd-file is too much and blocks executing.
So for running long single machine encodes, there is no problem to manually edit the files to work. But for DE it's too much....
LigH
15th September 2024, 08:00
I changed my x265 v4.0+4 archive (https://forum.doom9.org/showthread.php?p=2006909#post2006909).
Please note: From version 4.0 on I will build all variants without MultiView support so that they may still work without explicit --input parameter, except for a 64 bit build which has it explicitly enabled.
Wishbringer
15th September 2024, 08:29
@Atak_Snajpera:
Thanks for updating RipBot264 to 1.27.4 and updating several tools too (including x265 4.0-4).
@LigH:
Thanks for modding x265 for work with RB, but it seems, it's now not necessary anymore.
LigH
15th September 2024, 08:33
This was not a "modification", just a selection of compilation flags already provided by the unmodified sources.
Epitaph
15th September 2024, 18:41
My 3 systems updated Ripbot yesterday(not entirely sure that is the culprit) and I proceeded to line up 60 or so encodes. I am encoding to HEVC and I have no issues with VC1 or H264 sources but my system is completely hung up on mpeg2 extras... specifically interlaced TFF. I unchecked all MPEG2 videos and all other encodes finished without issue. If i have deinterlace off or inverse telecine , everything works fine... AVS Meter, Preview and DE. If I select Interlaced TFF, AVS Meter shows no progress, Preview will open MPC but it will hang until I end the process, and DE will run with all servers stuck on initializing(I've also tried without DE). Full disclosure, I am also trying to track down a random BSOD (that occurs while my system is idle) so this is all 24 hours after an in place WIN 11 Reinstall keeping documents and settings. Any Ideas or suggestions?
I downloaded a fresh copy of Ripbot from the first post in this thread, copied in my .ini files and disabled update. Ran it loading my previous que and it was unable to do anything with the same file. I then re-added the file and everything seems to work again. Re-adding the file into the updated Ripbot makes no difference. So there is something in the updated tools breaking Interlaced MPEG2.
Juha
15th September 2024, 23:14
Not sure whether this is an issue with 1.27.4 but a job with specific film gets stuck each time at the end of the conversion and the job never finishes properly. I have removed and re-created the job but the issue still occurs again.
I'm stuck at this point: https://images2.imgbox.com/0e/ae/6Ig7KjDG_o.png (Waiting even for hours won't help, job won't be finished).
The original source file for the job was .m2ts file (blu-ray). I muxed the source file into a mkv file and created the job again with it but the result was the same. Stuck again.
My conversion settings:
Video:
H265
Profile: MA10
Preset: Default
Tune: Default
Mode: CQ
CRF: 16
Crop: top 132, bottom: 132
CPU denoise: MDegrain3, Strength: 300
Audio: 5.1 FHG AAC-LC 320
Data from the source file:
Format : Matroska
Format version : Version 2
File size : 23.4 GiB
Duration : 1 h 38 min
Overall bit rate mode : Variable
Overall bit rate : 34.0 Mb/s
Frame rate : 23.976 FPS
Encoded date : 2024-09-15 08:37:12 UTC
Writing application : MakeMKV v1.17.7 win(x64-release)
Writing library : libmakemkv v1.17.7 (1.3.10/1.5.2) win(x64-release)
Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : VC-1
Format profile : Advanced@L3
Codec ID : V_MS/VFW/FOURCC / WVC1
Codec ID/Hint : Microsoft
Duration : 1 h 38 min
Bit rate : 29.8 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.599
Stream size : 20.5 GiB (88%)
Language : English
Default : No
Forced : No
Original source medium : Blu-ray
Audio
ID : 2
ID in the original source medium : 4352 (0x1100)
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 38 min
Bit rate mode : Variable
Bit rate : 4 154 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Stream size : 2.86 GiB (12%)
Title : Surround 5.1
Language : English
Default : Yes
Forced : No
Original source medium : Blu-ray
Text
ID : 3
ID in the original source medium : 4608 (0x1200)
Format : PGS
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 1 h 37 min
Bit rate : 31.7 kb/s
Frame rate : 0.378 FPS
Count of elements : 2225
Stream size : 22.2 MiB (0%)
Language : Finnish
Default : Yes
Forced : No
Original source medium : Blu-ray
Menu
00:00:00.000 : en:Chapter 01
00:04:14.003 : en:Chapter 02
00:10:59.367 : en:Chapter 03
00:15:12.703 : en:Chapter 04
00:24:53.325 : en:Chapter 05
00:29:02.741 : en:Chapter 06
00:32:52.804 : en:Chapter 07
00:39:08.304 : en:Chapter 08
00:48:36.121 : en:Chapter 09
00:55:10.598 : en:Chapter 10
01:01:26.849 : en:Chapter 11
01:08:42.785 : en:Chapter 12
01:13:54.763 : en:Chapter 13
01:18:58.775 : en:Chapter 14
01:26:52.790 : en:Chapter 15
01:31:50.755 : en:Chapter 16
slalom
16th September 2024, 16:49
Remove 5 sec from the end with mkv merge and try again
lemaireus
17th September 2024, 11:38
Would one of you please help me find a way of extracting the Dolby Vision metadata from a blu-ray and remuxing that metadata to a Ripbot encode?
I do not have the skill to work with command line interfaces and have therefore not been able to use the DDVT tool which I'm sure would solve my problem quickly. If you are aware of a "how to use DDVT tools" set of instructions/help file, please post a link and I'll give that a shot. If there are GUIs that can get the job done, I'd be grateful for a nudge in the right direction.
My thirteen years on this platform have taught me the pointlessness of placing feature requests on this forum. Genuinely helpful suggestions have almost always come from all of you, the wonderful members of this community who have almost always done all they can to help others such as myself. Thank you very much, always.
lemaireus
18th September 2024, 11:03
Would one of you please help me find a way of extracting the Dolby Vision metadata from a blu-ray and remuxing that metadata to a Ripbot encode?
I do not have the skill to work with command line interfaces and have therefore not been able to use the DDVT tool which I'm sure would solve my problem quickly. If you are aware of a "how to use DDVT tools" set of instructions/help file, please post a link and I'll give that a shot. If there are GUIs that can get the job done, I'd be grateful for a nudge in the right direction.
My thirteen years on this platform have taught me the pointlessness of placing feature requests on this forum. Genuinely helpful suggestions have almost always come from all of you, the wonderful members of this community who have almost always done all they can to help others such as myself. Thank you very much, always.
Thank you both very much for helping out. Since both of you refer to DoVi_Scripts, I shall try that out and hope that I can keep up with the learning curve. The YouTube help video makes a breeze of installation etc. Hope I'll get a hang of running the scripts by and by.
To those who wish to hear, it tells a story that help now comes through PMs rather than messages in the forum.
Once again, much gratitude for the wonderfully detailed and concretely helpful advice.
Ryushin
20th September 2024, 02:46
Would one of you please help me find a way of extracting the Dolby Vision metadata from a blu-ray and remuxing that metadata to a Ripbot encode?
I do not have the skill to work with command line interfaces and have therefore not been able to use the DDVT tool which I'm sure would solve my problem quickly. If you are aware of a "how to use DDVT tools" set of instructions/help file, please post a link and I'll give that a shot. If there are GUIs that can get the job done, I'd be grateful for a nudge in the right direction.
My thirteen years on this platform have taught me the pointlessness of placing feature requests on this forum. Genuinely helpful suggestions have almost always come from all of you, the wonderful members of this community who have almost always done all they can to help others such as myself. Thank you very much, always.
I use that DDVT Tool for all my 4K encodes. It's command line menu drivin, but it is a piece of cake to use. Steps off the top of my head:
* Use MakeMKV to create the 4K MKV file.
* Check Blu-ray to come to verify if the aspect ratio is 1.78:1 or if not, I need to crop.
* Drag and drop the MKV file onto the DDVT_DEMUXER.cmd program.
* Select Crop if necessary, then start it up. A RPU.bin file will be created.
* Create your encode with RB. If you selected the crop option, make sure your output is cropped.
* Drag your created RB encode on DDVT_INJECTOR.cmd program and drag your RPU.bin file on it when it asks for it.
* Make sure the cropped settings match, select MUX to MKV and you're done.
lemaireus
20th September 2024, 12:19
I use that DDVT Tool for all my 4K encodes. It's command line menu drivin, but it is a piece of cake to use. Steps off the top of my head:
* Use MakeMKV to create the 4K MKV file.
* Check Blu-ray to come to verify if the aspect ratio is 1.78:1 or if not, I need to crop.
* Drag and drop the MKV file onto the DDVT_DEMUXER.cmd program.
* Select Crop if necessary, then start it up. A RPU.bin file will be created.
* Create your encode with RB. If you selected the crop option, make sure your output is cropped.
* Drag your created RB encode on DDVT_INJECTOR.cmd program and drag your RPU.bin file on it when it asks for it.
* Make sure the cropped settings match, select MUX to MKV and you're done.
Thank you so much, Ryushin. I haven't yet had the time to give dovi_scripts a run through and DDVT tools, when I tried it last, seemed forbidding because of the command line interface. However, the steps you have outlined seem straightforward enough even for a technologically challenged person such as myself; it really cannot get any simpler than a drag and drop. I'll definitely give it another shot, follow the steps you have outlined, and hope that DDVT tools works for me this time around. I'll post the results I get, regardless of whether that is a 'success' or a 'failure' message.
Once again, thank you very much for helping out.
lemaireus
21st September 2024, 08:03
I use that DDVT Tool for all my 4K encodes. It's command line menu drivin, but it is a piece of cake to use. Steps off the top of my head:
* Use MakeMKV to create the 4K MKV file.
* Check Blu-ray to come to verify if the aspect ratio is 1.78:1 or if not, I need to crop.
* Drag and drop the MKV file onto the DDVT_DEMUXER.cmd program.
* Select Crop if necessary, then start it up. A RPU.bin file will be created.
* Create your encode with RB. If you selected the crop option, make sure your output is cropped.
* Drag your created RB encode on DDVT_INJECTOR.cmd program and drag your RPU.bin file on it when it asks for it.
* Make sure the cropped settings match, select MUX to MKV and you're done.
Ryushin, I tried following the steps that you have so helpfully outlined, but I'm doing something wrong. When I double click DDVT_DEMUXER.cmd, the cmd window flashes "waiting for 30 seconds, press a key to continue . . .". Thereafter, when I "Drag and drop the MKV file onto the DDVT_DEMUXER.cmd program", the cmd window instantly disappears. In fact, all the DDVT_XXX.cmd files, with the exception of DDVT_HYBRID.cmd and DDVT_OPTIONS.cmd, perform the same disappearing act after 30 seconds, or the moment when I drag and drop an MKV file onto the cmd window. Here's how the cmd window looks before disappearing:
https://i.postimg.cc/3wSVzGBD/DDVT-Tool-Error.jpg
I am unable to figure out exactly what it is that I might be doing wrong.
lemaireus
21st September 2024, 13:57
Elementary, dear Watson, elementary. Some wonderful, generous, and precisely articulated help in PMs provided the correct diagnosis. I should have dragged the mkv file over the DDVT_DEMUXER.cmd script. Instead, I was double clicking DDVT_DEMUXER.cmd and dragging the file on the cmd window that opened thereafter. That is the first step out of the way; now to the next. Many thanks for helping out.
lemaireus
21st September 2024, 16:44
I succeeded in getting my first Ripbot encode with Dolby Vision metadata, all thanks to the wonderfully generous forum members handholding me in PMs and over here, in the forum, thanks to Ryushin. Once my elementary but fundamental mistake became clear, the rest was a cakewalk.
Ryushin and my PM-ing friends, much, much gratitude.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.