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

[guest]

Could you test your SSD/HDD in my benchmark tool?
http://www.mediafire.com/file/i630b6n1fal38fj/IOSpeedTester.7z/file

Results on my 5 years old 120GB SSD (MLC)
https://i.imgsafe.org/65/652bfb9795.png

It is a command line tool. Use these switches

IOSpeedTester.exe --test-location "X:\" --transfer-size 120GIB --log-file "C:\users\%username%\Desktop\MyLog.csv"


Where X is a drive letter of your drive.

Upload MyLog.csv somewhere.

full help
IOSpeedTester v1.0 by Atak_Snajpera
Syntax: IOSpeedTester [options]

Options:
--help Show this help text and exit
--test-location <string> Folder where test files will be stored
--threads <1..64> Number of working threads. [1]
--buffer-size <1KiB..64MiB> Write/Read buffer size. [16MiB]
--transfer-size <integer> Amount of bytes to transfer. [1GiB]
--buffered-io Enables IO buffering in RAM. [Unbuffered]
--log-file <string> Log information to specific file. [None]
--write-only Performs write test only. [Write+Read]

Example usage:

Sequential Test with logging to a file
IOSpeedTester --test-location "%temp%" --log-file "MyLog.csv"

MIN IOPS Test
IOSpeedTester --test-location "%temp%" --buffer-size 4KiB

MAX IOPS Test
IOSpeedTester --test-location "%temp%" --buffer-size 4KiB --threads 64

Hey byteshare, would you be so kind as to download this, and runs the tests on your NVME's, and post of to Atak.

[guest]

yeah. If your workflow requires high consistent write speed then TLC/QLC is a big no no.

Well, this was all to get the final processes of RB to be faster.

But like I said, I will do the RAID-0 set up (which unfortunately will only leave me with 1 drive, instead of 2). So not sure what to use it for, for max. benefit (meaning either the Temp drive, or the drive that the encode is compiled to).

Anyway, I have a few setup options to try.

[byteshare]

So you don't think it would change anything using different PCI-e slots ??
Depends on your board, even if all of your PCIe ports are 16x, it doesn't mean they'll run at 16x when they're all in use, or even all at the same PCIe version. What is your mother board?

And the only way to create a RAID-0 would be in Windows Disk Management.
If you're using Windows 8x or higher you can also use Storage Spaces, which is built into Windows now.

Hey byteshare, would you be so kind as to download this, and runs the tests on your NVME's, and post of to Atak.
Samsung 970 EVO 500GB
Results: https://pastebin.com/LDwWrU10
Gets slower and slower over time while writing, but didn't drop below 700MiB/s for the 120GiB file. The read seemed more stable at 3GiB/s
@Atak_Snajpera what are you using to graph this?

[Atak_Snajpera]

https://i.imgsafe.org/48/48b959c7a9.png

https://i.imgsafe.org/48/48b959631e.png

@Atak_Snajpera what are you using to graph this?
LibreOffice Calc

@Pauly Dunne
Are you sure that you bought this model?
https://www.amazon.com/XPG-SX8200-Gen3x4-3000MB-ASX8200PNP-512GT-C/dp/B07K1HMMJC/ref=sr_1_5?crid=1HUJVI2W13NQE&keywords=xpg+8200+pro&qid=1572115673&sprefix=xpg+8200+pro%2Caps%2C253&sr=8-5

[guest]

@Pauly Dunne
Are you sure that you bought this model?
https://www.amazon.com/XPG-SX8200-Gen3x4-3000MB-ASX8200PNP-512GT-C/dp/B07K1HMMJC/ref=sr_1_5?crid=1HUJVI2W13NQE&keywords=xpg+8200+pro&qid=1572115673&sprefix=xpg+8200+pro%2Caps%2C253&sr=8-5

Yep, just checked with the packet it came in.

Something strange going on here, I think !!!

Also, thankyou byteshare :)

[Atak_Snajpera]

Yep, just checked with the packet it came in.

Something strange going on here, I think !!!

Also, thankyou byteshare :)

Yeah that advertised write speed of ~3GiB/s is impossible to achieve in real world scenarios.

BTW. This https://www.tweakguides.com/Hardcon19_7.html confirms that SLC cache for samsung 970 evo 500 GB is only 22GiB so my benchmark works correctly.

[Atak_Snajpera]

I think I know why they advertise that ssd as 3GiB/s+ ... They use ATTO benchmark with tiny file size (for example 256MiB)! This means that they are literally testing write/read on DRAM cache.
example
https://i.imgur.com/3tzNSfj.png

[guest]

Depends on your board, even if all of your PCIe ports are 16x, it doesn't mean they'll run at 16x when they're all in use, or even all at the same PCIe version. What is your mother board?

ASUS P9X79-E WS (a bit old I know), I've since tried them in various slots, and there's basically no difference.

If you're using Windows 8x or higher you can also use Storage Spaces, which is built into Windows now.

Tried to set up a Storage Space...didn't want to do it for me :( And a "Spanned" set up didn't make any noticable difference either.

Samsung 970 EVO 500GB
Results: https://pastebin.com/LDwWrU10
Gets slower and slower over time while writing, but didn't drop below 700MiB/s for the 120GiB file. The read seemed more stable at 3GiB/s
@Atak_Snajpera what are you using to graph this?

I guess I'll just ignore all this "testing", and see what (if any) difference it makes to the RB process...HAS to better than anything else I currently have.

Thanks for your input :)

PS:- I should have asked you if you're using PCI-e adapter's, or directly into the MB.

[guest]

I think I know why they advertise that ssd as 3GiB/s+ ... They use ATTO benchmark with tiny file size (for example 256MiB)! This means that they are literally testing write/read on DRAM cache.

So it's all sales bullshit, then...that sux !!!

Just out of interest I went looking for a Youtube clip of a test of the Adata drive, and this guy (who prefers Samsung's), said the Adata's were quite comparable, and he showed some Crystal Disk Mark results of the Adata on some hi end MSI board (I think it was), ANYWAY, I noted the "numbers", and did a Crystal test on mine, and wasn't really that close...all I can think is there is a performance hit, having to use NVMe's via a PCI-e adapter.

Having said that, it was good of byteshare to contribute to the data, and the Adata is only a little "slower" than his "basic" 970's.

I also tried several different PCI-e slots, to no avail, and I created a "Spanned" set in Disk Manager, and run your test, didn't make a **** of difference, either...wierd thing, even though they were suppose to be spanned, when I ran the test, it only seemed to be accessing one "drive", not both (as per blinking led's)

Anyway, you get what you pay for :( forget the hype !!!

[Atak_Snajpera]

Crystal disk and assd are also useless because by default they use 1GiB test file. That's still enough to fit in ssd's dram cache. Most reviewers on YouTube do not bother to change that option.

[guest]

Crystal disk and assd are also useless because by default they use 1GiB test file. That's still enough to fit in ssd's dram cache. Most reviewers on YouTube do not bother to change that option.

Fair enough, but I did notice that, and did a couple of 32Gb runs...I think it slowed it down a bit.

Anyway, I've had enough of testing...I did a couple of "test's" with RB.

I noticed (with a stop watch), that the NVMe's DO speed up the copying & indexing in the initial stage of job creation.

Then the whole point of this saga...the combining of the chunks & the muxing is a LOT faster.

So I will run a few of my "big ass" 4K encodes, and see how they handle them.

If I decide to throw some NVMe's into another PC, I will NOT get ADATA's again. Even 970's would be better, and the 970 Plus's would be a little again..Pro are a bit exy. :(

Change of subject..

I'm thinking of possibly utilising the new script you have added to RB.

Could you please give me some pointer's on how I could use that to move a finished encode off the NVMe, to another location.

eg:- from G:/Ripbot Encodes to D:/

[Atak_Snajpera]

I'm thinking of possibly utilising the new script you have added to RB.
Could you please give me some pointer's on how I could use that to move a finished encode off the NVMe, to another location.
So you find it useful after all... Who would have thought ;)

here is the script
move /Y "%OUTPUTFILEDIR%\%OUTPUTFILENAME%.%OUTPUTFILEEXT%" "D:\"

[guest]

So you find it useful after all... Who would have thought ;)

here is the script
move /Y "%OUTPUTFILEDIR%\%OUTPUTFILENAME%.%OUTPUTFILEEXT%" "D:\"

Yeah, I know....you've got a good memory. :rolleyes:

I guess what changed my mind was using it for something other than deleting job's, I'd still think I'd prefer to do that manually.

Thanks for that, I'll have a "play", but to ask a noob question, do I need to rename anything here ??

And is this added to the .ini file ??

Very little experience with "command's".

[Atak_Snajpera]

Thanks for that, I'll have a "play", but to ask a noob question, do I need to rename anything here ??
No. Those %VARIABLES% will be automatically replaced by ripbot264.

And is this added to the .ini file ??
You add this to Job finished successfully.cmd

[guest]

No. Those %VARIABLES% will be automatically replaced by ripbot264.


You add this to Job finished successfully.cmd

Yes, I had a look in there, after I sent the question.

Excellent, will give it a whirl.

Cheers & Thanks again.

BTW, I finished my crf 12, crf 16 & 30mb/s test's on a 1080 HEVC..I think the crf 12 has the edge, but they all look better than original. :)

[mparade]

Can you reach the share manually from the remote PC?
Can you ping the remote PC?

Admin could ping the remote PC and told everything seems to be ok with my VPN connection. I did not check the first one yet. Is there something more to set within from Ripbot for things to work?

Thank you. For 4K encoding I would definitely would like to utilizie the additional 16 cores.

[byteshare]

While not what we're doing but related to speed tests:
M.2 NVMe vs SSD vs OPTANE+HDD vs HDD Game Loading Times
https://youtu.be/2BS_6xOf0mw

Admin could ping the remote PC and told everything seems to be ok with my VPN connection. I did not check the first one yet. Is there something more to set within from Ripbot for things to work?

Thank you. For 4K encoding I would definitely would like to utilizie the additional 16 cores.
Check if you can manually reach the share since you can ping the computer. Might need to just change the permissions on the share and/or add the login info into RipBot's DE settings.

[GZZ]

having a problem with HDR10 on Red Heat. It seems to not honor the HDR10 encoding properly from the source.

I use the same settings as on other movies where it works just fine. But it seems like some info is missing in the reencoded. (marked with red line)

MediaInfo from Source:


Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 44 min
Bit rate : 63.0 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.316
Stream size : 45.8 GiB (94%)
Language : English
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : BT.2020
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Original source medium : Blu-ray


MediaInfo from Reencode

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 44 min
Bit rate : 19.5 Mb/s
Width : 3 840 pixels
Height : 2 076 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.102
Stream size : 14.2 GiB (82%)
Writing library : x265 3.2+7-37648fca915b:[Windows][GCC 9.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=3 / numa-pools=+ / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2076 / interlace=0 / total-frames=2880 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant


Reencode script:

@echo off
@echo ""\\DESKTOP_8700K\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\DESKTOP_8700K\RipBot264temp\job7\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | "\\DESKTOP_8700K\Ripbot264temp\tools\x265\x265_x64.exe" --seek 0 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --crf 18 --fps 24 --min-keyint 24 --keyint 240 --frames 2880 --sar 1:1 --profile main10 --output-depth 10 --ctu 64 --y4m --pools "+" --output "\\DESKTOP_8700K\RipBot264temp\job7\Chunks\1.265" -"
"\\DESKTOP_8700K\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\DESKTOP_8700K\RipBot264temp\job7\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | "\\DESKTOP_8700K\Ripbot264temp\tools\x265\x265_x64.exe" --seek 0 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --crf 18 --fps 24 --min-keyint 24 --keyint 240 --frames 2880 --sar 1:1 --profile main10 --output-depth 10 --ctu 64 --y4m --pools "+" --output "\\DESKTOP_8700K\RipBot264temp\job7\Chunks\1.265" -


Normally I see a line like this: "--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" but it seems to be missing.

Also from the x265 encoding log its missing a line.
It normally has this line, but not in this case: x265 [warning]: Turning on repeat-headers for HDR compatibility


y4m [info]: 3840x2076 fps 24000/1000 i420p10 sar 1:1 unknown frame count
raw [info]: output file: \\DESKTOP_8700K\RipBot264temp\job7\Chunks\10.265
x265 [info]: HEVC encoder version 3.2+7-37648fca915b
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 12 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(33 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 240 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=8 deblock sao
x265 [info]: frame I: 38, Avg QP:17.39 kb/s: 45065.87
x265 [info]: frame P: 805, Avg QP:18.67 kb/s: 25801.51
x265 [info]: frame B: 2037, Avg QP:21.68 kb/s: 8957.98
x265 [info]: Weighted P-Frames: Y:2.9% UV:2.5%
x265 [info]: consecutive B-frames: 10.7% 15.1% 12.1% 46.3% 15.9%


Sample: https://www.dropbox.com/s/sb81qwfeyu712th/Red%20Heat_Sample.mkv?dl=0

[Atak_Snajpera]

Sample: https://www.dropbox.com/s/sb81qwfeyu...ample.mkv?dl=0
Ok thanks...

BTW. I do not think that encoding such old movie in 3840x2076 makes any sense.
cropped frame 2160p
https://i.imgsafe.org/87/87244d2eb6.png

cropped frame 2160p -> downsampled to 1080p -> upsampled to 2160p
https://i.imgsafe.org/87/8724361bc6.png

It is another so called fake 4K. If I was you I would downsample to 1080p and activate MDegrain2. You will have much smaller file size and cleaner image.

[GZZ]

Ok thanks...

BTW. I do not think that encoding such old movie in 3840x2076 makes any sense.
cropped frame 2160p
https://i.imgsafe.org/87/87244d2eb6.png

cropped frame 2160p -> downsampled to 1080p -> upsampled to 2160p
https://i.imgsafe.org/87/8724361bc6.png

It is another so called fake 4K. If I was you I would downsample to 1080p and activate MDegrain2. You will have much smaller file size and cleaner image.

It was rescanned from the 35mm film to 4k in the 2019 remaster which the UHD is from: https://www.imdb.com/title/tt0095963/technical?ref_=tt_dt_spec
Digital Intermediate (4K) (2019 remaster)

But I was more into keeping the HDR flag (4k or 2k)

[Atak_Snajpera]

It was rescanned from the 35mm film to 4k in the 2019 remaster which the UHD is from: https://www.imdb.com/title/tt0095963/technical?ref_=tt_dt_spec
Digital Intermediate (4K) (2019 remaster)
My test clearly shows that you do not get true pixels. It looks like 2k upscale to 4k with added noise to fool you that It has more details.

[Ryushin]

Hi Atak,

Still encountering the bug with pulling in a MKV that has the TrueHD stream before the AC3 stream:
FFAudioSource: No audio track found
(D:\Temp\RipBot264temp\job19\getinfo.avs, line 4)

This is the default that MakeMKV creates as I need to use it to make a MKV file to pull into Ripbot264 if I have a seamless branching 4K. I'm having to remux it to put the AC3 track first before the TrueHD track and then it pulls in fine.

[Atak_Snajpera]

Hi Atak,

Still encountering the bug with pulling in a MKV that has the TrueHD stream before the AC3 stream:
FFAudioSource: No audio track found
(D:\Temp\RipBot264temp\job19\getinfo.avs, line 4)

This is the default that MakeMKV creates as I need to use it to make a MKV file to pull into Ripbot264 if I have a seamless branching 4K. I'm having to remux it to put the AC3 track first before the TrueHD track and then it pulls in fine.

Can you send me a sample for testing purposes?

[Ryushin]

Can you send me a sample for testing purposes?

I'll try and get you a sample. Not sure if I can chop a Atmos TrueHD stream or not.

I know electronics are crazy expensive where you are, just wondering if you've been able to move to 4K ripping and encoding for yourself personally yet.

[Ryushin]

I'll try and get you a sample. Not sure if I can chop a Atmos TrueHD stream or not.

I've tried trimming the mkv several times with ffmpeg and I can import the trimmed version, but not the original 4K version. Frustrating. Not sure what to do. I'll try a few more tests.

[GZZ]

I've tried trimming the mkv several times with ffmpeg and I can import the trimmed version, but not the original 4K version. Frustrating. Not sure what to do. I'll try a few more tests.

Dont know if I did it correctly. But I used MKVToolNix and set the output to be devided by size and choose 350mb output files. Then it divide the file into 350mb chunks, but they are not equal in size, so I think it does it by keyframe or something. Then I choose one of the file as a sample and delete the others.

[byteshare]

Dont know if I did it correctly. But I used MKVToolNix and set the output to be devided by size and choose 350mb output files. Then it divide the file into 350mb chunks, but they are not equal in size, so I think it does it by keyframe or something. Then I choose one of the file as a sample and delete the others.
Yes, MKVtoolnix will use key frames if you're cutting by size, duration, and even frames.
I've tried trimming the mkv several times with ffmpeg and I can import the trimmed version, but not the original 4K version. Frustrating. Not sure what to do. I'll try a few more tests.
Did you try MKVtoolnix?

[guest]

Would it be too much to ask if you could implement an option where you could send a shut down/kill command thru to an individual server's IP address, when ever you wanted or needed to ??

Preferably within the Encoding Client window/screen.

Very handy when the servers are elsewhere !!

Separate to the shut down options at the end of an encode.

I've had another idea about "power saving" during long "wait's" between encodes, in reference to DE, and several server pc's.

Now I have no idea if someone else has thought of this, and not too sure how it would work, anyways.

IF, you had the "remote" DE servers set to go to "sleep" once there were off a high cpu usage encode, would RB be able to "wake them" out of that sleep, once it started encoding the next job ??

[Ryushin]

Hi Atak,

Would is be possible to add a "Add Padding" tick box to the resize video. So selecting a setting like HDReady (720p) will scale the video and keep the aspect ratio of the video (keeps cropping settings) to fit within the resize video window. Then clicking the Padding box will add boarders if necessary to make the video fit the 720p range.

There also an issue with typing in the box to manually enter the size. I'm trying to type 960x720 (4x3 movies) and it keeps auto-correct the size to make it fit within a parameter before I can finish typing the size. The only way for me to do it is to copy 960 to the clipboard and paste it into the box.
or selecting a different audio source.or selecting a different audio source.

I wanted to wait to ask about an issue until I upgraded to SSDs on my server which I just completed yesterday. I bought six Crucial MX500 2TB drives and put then in a ZFS raidz2 (like raid6). I'm waiting on Supermicro to release a new Epyc Rome motherboard before upgrading the CPU (which is an old 4 core Xeon) to the 24 core Epyc. My RipBot server is a KVM Virtual Machine running on the linux server and it's only acting as a director to pull in the jobs and use DE to send them to other servers for encoding. It's virtual drive is now running on the SSD storage pool.

Working with HD sources is fairly quick and it only takes a few seconds when it's "Gathering Information" when leaving the Avisynth window. 4K sources on the other hand, takes minutes. Selecting a second audio source also takes a very long time.

Another issue is having it do auto cropping. I'll use this option for HD sources which might take a minute. 4K sources can be a 15-30 minute wait when having it do auto cropping. For 4K sources I'm selecting manual and entering the numbers manually.or selecting a different audio source.or selecting a different audio source. Even selecting New Frame takes a very long time to pull in.

[Atak_Snajpera]

Would is be possible to add a "Add Padding" tick box to the resize video. So selecting a setting like HDReady (720p) will scale the video and keep the aspect ratio of the video (keeps cropping settings) to fit within the resize video window. Then clicking the Padding box will add boarders if necessary to make the video fit the 720p range.
I will see...

There also an issue with typing in the box to manually enter the size. I'm trying to type 960x720 (4x3 movies) and it keeps auto-correct the size to make it fit within a parameter before I can finish typing the size. The only way for me to do it is to copy 960 to the clipboard and paste it into the box.
OK. I see the problem...

Working with HD sources is fairly quick and it only takes a few seconds when it's "Gathering Information" when leaving the Avisynth window. 4K sources on the other hand, takes minutes. Selecting a second audio source also takes a very long time.

Another issue is having it do auto cropping. I'll use this option for HD sources which might take a minute. 4K sources can be a 15-30 minute wait when having it do auto cropping. For 4K sources I'm selecting manual and entering the numbers manually.or selecting a different audio source.or selecting a different audio source. Even selecting New Frame takes a very long time to pull in.
On my real win7 and Xeon E5-2690 with 64GiB of RAM autocropping takes ~12s with UHD bluray source and ~3s with regular avc bluray source.

[Ryushin]

Dont know if I did it correctly. But I used MKVToolNix and set the output to be devided by size and choose 350mb output files. Then it divide the file into 350mb chunks, but they are not equal in size, so I think it does it by keyframe or something. Then I choose one of the file as a sample and delete the others.

I tried this and I'm afraid I still cannot duplicate the issue with a small trimmed file. Only the original it seems. I guess I'll just need to deal with this issue for the time being. The bigger issue though is the seamless branching in 4K sources causing Ripbot to cause audio sync problems. At least I have a workaround. Ripbot is still amazing software and I use it just about daily.

[Ryushin]

I will see...
On my real win7 and Xeon E5-2690 with 64GiB of RAM autocropping takes ~12s with UHD bluray source and ~3s with regular avc bluray source.

So I'm probably CPU bound then for the auto cropping. My seven year old Xeon E5-2609 at 2.40GHz with three of the four cores passed through to the VM is probably the issue with the cropping then. I'll do some more testing in a couple of months or so once Supermicro releases a new board and I get the 24 core Epyc Rome.

Do you think I'm still CPU bound for the Gathering Information slowness? Before it looked like I was I/O bound and looking at the Task Manager that is no longer the case. CPU is running around 75% during this time. But since there are only three cores, that could be an issue.

[Atak_Snajpera]

So I'm probably CPU bound then for the auto cropping. My seven year old Xeon E5-2609 at 2.40GHz with three of the four cores passed through to the VM is probably the issue with the cropping then. I'll do some more testing in a couple of months or so once Supermicro releases a new board and I get the 24 core Epyc Rome.

Do you think I'm still CPU bound for the Gathering Information slowness? Before it looked like I was I/O bound and looking at the Task Manager that is no longer the case. CPU is running around 75% during this time. But since there are only three cores, that could be an issue.

I would blame virtual machine instead of cores. 12s vs minutes looks weird even on 4C.

[byteshare]

IF, you had the "remote" DE servers set to go to "sleep" once there were off a high cpu usage encode, would RB be able to "wake them" out of that sleep, once it started encoding the next job ??
Are you still seeing huge waits between muxing at the end of jobs?
From my usage of RB, the time between jobs is not a lot. At most I could see a reason for another job to start once all of the chunks are done or in process, but even that wouldn't be a major difference IMO, unless you had a huge server farm, but at that point (no offense to RB) you should use different software or have more individual sessions of RB going.

[Ryushin]

I would blame virtual machine instead of cores. 12s vs minutes looks weird even on 4C.

Though what is stranger is the huge amount of difference it is between HD and 4K. Is there an option to use a different decoder for the auto detect boards and new frame option. I notice things got really slow for me around the time lsmash was implemented.

The VM has been fine, but a little slow in general, but overall, it got the job done. Now though the Gathering Information on anything related to 4K sources seems to take a very long time.

Oh, one other thing, is it still necessary to convert .sup to .sub when rendering subtitles?

[slalom]

Oh, one other thing, is it still necessary to convert .sup to .sub when rendering subtitles?
Uncheck the box in Main Settings

[GZZ]

I tried this and I'm afraid I still cannot duplicate the issue with a small trimmed file. Only the original it seems. I guess I'll just need to deal with this issue for the time being. The bigger issue though is the seamless branching in 4K sources causing Ripbot to cause audio sync problems. At least I have a workaround. Ripbot is still amazing software and I use it just about daily.

Did you extract it using MakeMKV ? I have noticed that on Animation like Disney and Pixar this issue occure. I found out there is a glitch in the movie when extracted with MakeMKV (I think its extraction issue in makeMKV)

To find the glitch
What I did to find it, is to run MKVToolNix on the MKV file and then try load all the chunks into Ripbot264 (Use batch mode), one the chunks will fail with that error (no audio), it did on mine. Then try play this chunk and see if there is a glitch in the audio (you can hear it).

To fix it
Use MkvToolNix on your bluray/UHD source to extract the movie to mkv and then try load it into ripbot264

[Ryushin]

Uncheck the box in Main Settings

That is unchecked and muxing in subtitles works correctly. Rendering subtitles always converts sup to sub regardless of the setting in Main Settings.

[Ryushin]

Did you extract it using MakeMKV ? I have noticed that on Animation like Disney and Pixar this issue occure. I found out there is a glitch in the movie when extracted with MakeMKV (I think its extraction issue in makeMKV)

To find the glitch
What I did to find it, is to run MKVToolNix on the MKV file and then try load all the chunks into Ripbot264 (Use batch mode), one the chunks will fail with that error (no audio), it did on mine. Then try play this chunk and see if there is a glitch in the audio (you can hear it).

To fix it
Use MkvToolNix on your bluray/UHD source to extract the movie to mkv and then try load it into ripbot264

I did not know MkvToolNix could make a mkv from a BD/4K source. I would prefer MkvToolNix to do the work.

[guest]

Are you still seeing huge waits between muxing at the end of jobs?
From my usage of RB, the time between jobs is not a lot. At most I could see a reason for another job to start once all of the chunks are done or in process, but even that wouldn't be a major difference IMO, unless you had a huge server farm, but at that point (no offense to RB) you should use different software or have more individual sessions of RB going.

TBH, I haven't done any 4K encodes since getting the NVMe's, but that's not really what info I was after.

I know there's an option for RB to "wake up" DE server's, but I haven't had any success with that...

So despite how long the "wait" times are between encodes, there is STILL a period where the servers aren't doing anything, and as in my case, I have 6 hungry servers eating up power, when they could be asleep, or even better, OFF.

Under full load the "farm" uses approx 2400W, and I guess when they're idling, it would be maybe a 1/4 of that, so lets say 600W for say 10 - 15 minutes, several times a day, adds up to a lot of wasted energy.

you should use different software or have more individual sessions of RB going.

So what different software can do what RB can do ??

And AFAIK, the only way to have individual sessions of RB, is to have another client pc "sharing" the "farm", but that kinda defeats the purpose of doing large encodes using the whole farm for a process as fast as possible.

[byteshare]

TBH, I haven't done any 4K encodes since getting the NVMe's, but that's not really what info I was after.

I know there's an option for RB to "wake up" DE server's, but I haven't had any success with that...

So despite how long the "wait" times are between encodes, there is STILL a period where the servers aren't doing anything, and as in my case, I have 6 hungry servers eating up power, when they could be asleep, or even better, OFF.

Under full load the "farm" uses approx 2400W, and I guess when they're idling, it would be maybe a 1/4 of that, so lets say 600W for say 10 - 15 minutes, several times a day, adds up to a lot of wasted energy.
Seems reasonable to me (the amount of power waste), but have you been able to suspend/sleep your computers and wake them remotely with other software? Might not be a RB issue. Not all of my computers fully support it.

So what different software can do what RB can do ??

And AFAIK, the only way to have individual sessions of RB, is to have another client pc "sharing" the "farm", but that kinda defeats the purpose of doing large encodes using the whole farm for a process as fast as possible.
The full quote of what I said is important IMO
unless you had a huge server farm, but at that point (no offense to RB) you should use different software or have more individual sessions of RB going.
Talking about a major server farm, which you don't have. There is other software but talking at a commercial level, so nothing free.
Are you trying to do it as fast as possible or trying to maximize CPU usage all of the time? I thought you wanted to maximize CPU usage, and in that case another RB sharing the server pool would be helpful.
If you want it as fast as possible than the way RB is now is better because you have every server waiting at the ready for the next job.
Like we've talked about the only thing that could speed that up a little is if another job started while the last job finished the muxing, but depending on your job and setup that can be a very minimal amount of time or like how you were doing it a lot of time.

[guest]

Seems reasonable to me (the amount of power waste), but have you been able to suspend/sleep your computers and wake them remotely with other software? Might not be a RB issue. Not all of my computers fully support it.

I have tried a couple of basic things, that seem to work.

Several years ago I installed a small app that monitored CPU usage (among other things), and you could set it up to either sleep, hibernate, or shutdown, once cpu usage dropped below a certain level, but I can't remember what it was :(

this:- http://www.ampsoft.net/utilities/WinOFF.php#Download

I haven't tried a "sleep or hibernate" function yet, I was just "putting it out there"

So how do you set up RB to "wake up" a server ??, I have the options enabled in RB, I have all the MAC address & username's etc, but I have no success (but I haven't tried that recently)

The full quote of what I said is important IMO

Sorry if I've upset you, but I did have the full quote, in the previous quote, and decided just to use that sentence for the next comment..check.

Talking about a major server farm, which you don't have. There is other software but talking at a commercial level, so nothing free.
Are you trying to do it as fast as possible or trying to maximize CPU usage all of the time? I thought you wanted to maximize CPU usage, and in that case another RB sharing the server pool would be helpful.
If you want it as fast as possible than the way RB is now is better because you have every server waiting at the ready for the next job.
Like we've talked about the only thing that could speed that up a little is if another job started while the last job finished the muxing, but depending on your job and setup that can be a very minimal amount of time or like how you were doing it a lot of time.

Yes, I want to maximise CPU usage, to do it faster....

Not sure why you're suggesting another client doing other jobs....(which I do anyway), BUT on "big ass" encodes, 1 client, ALL the DE servers dedicated to that one job...isn't that utilising CPU usage, and getting it done as fast as possible ??? or am I missing something here.

[mparade]

1) run encodingserver.exe on remote pc and take a screenshot.
2) run ripbot264.exe on your home pc. go to settings->Distributed encoding and show me what client ips are listed under CLIENT IP
3) Are you sure firewall on remote pc does block connection?

This is the screenshot from home pc:

http://mammutmail.com/hu/download/b8303cc66fb21282c2be3d994bd7ec1e

[Atak_Snajpera]

This is the screenshot from home pc:

http://mammutmail.com/hu/download/b8303cc66fb21282c2be3d994bd7ec1e

Have you checked firewall settings on your Work-PC? If EncodingClient can't connect to server (assuming that IP reported by EncodingServer is the same as you typed in RipBot264 settings) then I would suspect firewall issue.

[mparade]

This is the screenshot from work pc:

http://mammutmail.com/hu/download/c668db124bc39be7e763ac5cd6bacaf4

I have double checked that firewall on work-PC has been switched off.

Server reported some "socket" problem right after it made contact with EncodingClient.

[Atak_Snajpera]

Server reported some "socket" problem right after it made contact with EncodingClient.
Too bad you didn't take a screenshot... That message is important.

[GZZ]

My test clearly shows that you do not get true pixels. It looks like 2k upscale to 4k with added noise to fool you that It has more details.

Hi Atak_Snajpera
Did you find a solution for the HDR issue ?

[Atak_Snajpera]

Hi Atak_Snajpera
Did you find a solution for the HDR issue ?

yes...

[mparade]

Too bad you didn't take a screenshot... That message is important.

There you are :):

http://mammutmail.com/hu/download/f12357709850442d2867fce26e0afa38

[Atak_Snajpera]

There you are :):

http://mammutmail.com/hu/download/f12357709850442d2867fce26e0afa38

Your home pc blocks connection from encodingserver. ( Connection timeout). Connection must be established in both ways. Check firewall settings on home pc.