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

[Tlen]

Mm but look at the trousers

https://caps-a-holic.com/c_image.php?max_height=1080&s=120248&a=0&x=0&y=0&l=1

Not fantastically defined but the wrinkles are there, neat and clean and not upscale (you would definetively note in that case)

[Atak_Snajpera]

So perhaps another bad transfer labeled as UHD ;)

[Tlen]

Oh you were looking at the 4k screens.
Well...that... maybe eheh

[Fishman0919]

I'm trying to encode a 4k movie with the arguments --ctu 32 --merange 114 but the forced arguments --ctu 64 --merange 57 are coming in at the end and override my commands... I can edit the file but just a heads up

"D:\RipBot264v1.22.0\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "C:\Temp\RipBot264temp\job1\job1.avs" -strict -1 -f yuv4mpegpipe - | "D:\RipBot264v1.22.0\tools\x265\x265_x64.exe" --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --crf 22 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 179468 --sar 1:1 --profile main10 --output-depth 10 --aq-mode 3 --min-keyint 23 --keyint 250 --me umh --ctu 32 --merange 114 --ctu 64 --merange 57 --y4m --output "C:\Temp\RipBot264temp\job1\video.265" -

[guest]

I'm trying to encode a 4k movie with the arguments --ctu 32 --merange 114 but the forced arguments --ctu 64 --merange 57 are coming in at the end and override my commands... I can edit the file but just a heads up

Hi, I couldn't help but notice this :-

"D:\RipBot264v1.22.0\Tools\ffmpeg\bin\ffmpeg.exe"

Do you name the folder after the version you're running ?? Because if that's the case you are running a pretty old build, it's currently v1.24.1.

Now I'm not saying that this is why your seeing this change, but it would be interesting if you ran auto update to get the latest, to see if that does indeed fix this.

[activoice]

I usually use Ripbot in CQ mode to encode using Distributed Encoding and it works fine across 2 PCs on my home network.. However today I was trying to do Distributed Encoding in 2-pass mode, but on the second PC I constantly see it starting and stopping and the error briefly flashes by - x265 - unable to open input file. (The primary PC has no issues and continues to encode on it's own)

When I look at the files and paths in the encoder window everything looks correct to me, and if I open explorer I can reach all of those paths... so I am not sure which file it claims to be having a problem with... not sure if Ripbot has a log file I can post or something like that. I assume it's a file specific to 2 pass encoding that it can't find since I don't have any such error when encoding in CQ mode.

Any ideas?

[Fishman0919]

Hi, I couldn't help but notice this :-

"D:\RipBot264v1.22.0\Tools\ffmpeg\bin\ffmpeg.exe"

Do you name the folder after the version you're running ?? Because if that's the case you are running a pretty old build, it's currently v1.24.1.

Now I'm not saying that this is why your seeing this change, but it would be interesting if you ran auto update to get the latest, to see if that does indeed fix this.

No... that was the ver I download when it was new... I just unzipped it to that folder and never renamed it.

2020-06-28 11:23:21 : =========================[UPDATER ACTIVATED]=========================
2020-06-28 11:23:21 : Looking for correct UUID link in http://forum.doom9.org/showthread.php?t=127611
2020-06-28 11:23:21 : [SUCCESS] http://forum.doom9.org/showthread.php?t=127611 has correct UUID link 6c966b28-e0dd-48f6-b1c7-a56e8a275ec0
2020-06-28 11:23:22 : Downloading update file http://atak-snajpera.5v.pl/ripbot264update/update.zip
2020-06-28 11:23:22 : [SUCCESS] D:\RipBot264v1.22.0\Updates\update.zip saved!
2020-06-28 11:23:23 : CRC32 value has not changed for [core]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [aften]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [avs2pipemod]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [avs2yuv]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [avsmeter]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [bdsup2sub]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [chapterxtractor]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [dgindex]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [downloadposter]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [eac3to]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [ffmpeg]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [fhgaacenc]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [mediainfo]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [mkvtoolnix]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [modifychapters]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [mp4box]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [mpc]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [opus-tools]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [pgcdemux]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [remuxtool]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [setacl]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [ssatosrt]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [tsmuxer]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [vjoin]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [vsrip]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [wolcmd]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [x264]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [x265]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [autocrop]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [ffms]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [flash3kyuu_deband]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [hqdn3d]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [scripts]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [tivtc]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [vsfilter]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [yadif]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [knlmeanscl]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [openclinfo]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [masktools]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [mvtools]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [nnedi3]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [detectborders]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [avisynth]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [rawsourceplus]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [rgtools]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [nicaudio]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [plugins_jpsdr]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [waitforprocess]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [avsresize]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [dgtonemap]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [lsmash]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [7z]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [srttossa]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [hdrtools]. Update is not required.
2020-06-28 11:23:23 : CRC32 value has not changed for [matroskasplitter]. Update is not required.
2020-06-28 11:23:23 : Downloading finished.
2020-07-04 13:28:13 : =========================[UPDATER ACTIVATED]=========================
2020-07-04 13:28:13 : Looking for correct UUID link in http://forum.doom9.org/showthread.php?t=127611
2020-07-04 13:28:14 : [SUCCESS] http://forum.doom9.org/showthread.php?t=127611 has correct UUID link 6c966b28-e0dd-48f6-b1c7-a56e8a275ec0
2020-07-04 13:28:14 : Downloading update file http://atak-snajpera.5v.pl/ripbot264update/update.zip
2020-07-04 13:28:15 : [SUCCESS] D:\RipBot264v1.22.0\Updates\update.zip saved!
2020-07-04 13:28:15 : CRC32 value has not changed for [core]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [aften]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [avs2pipemod]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [avs2yuv]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [avsmeter]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [bdsup2sub]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [chapterxtractor]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [dgindex]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [downloadposter]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [eac3to]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [ffmpeg]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [fhgaacenc]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [mediainfo]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [mkvtoolnix]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [modifychapters]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [mp4box]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [mpc]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [opus-tools]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [pgcdemux]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [remuxtool]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [setacl]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [ssatosrt]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [tsmuxer]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [vjoin]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [vsrip]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [wolcmd]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [x264]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [x265]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [autocrop]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [ffms]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [flash3kyuu_deband]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [hqdn3d]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [scripts]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [tivtc]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [vsfilter]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [yadif]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [knlmeanscl]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [openclinfo]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [masktools]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [mvtools]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [nnedi3]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [detectborders]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [avisynth]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [rawsourceplus]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [rgtools]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [nicaudio]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [plugins_jpsdr]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [waitforprocess]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [avsresize]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [dgtonemap]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [lsmash]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [7z]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [srttossa]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [hdrtools]. Update is not required.
2020-07-04 13:28:15 : CRC32 value has not changed for [matroskasplitter]. Update is not required.
2020-07-04 13:28:15 : Downloading finished.
2020-07-04 13:28:37 : Next check after 2020-07-05 13:28:13

[guest]

No... that was the ver I download when it was new... I just unzipped it to that folder and never renamed it.

Yep, well you're up to date alright, and seeing there hasn't been any updates since 01-05-20, that's not the problem.

I am very puzzled why Atak isn't commenting on the forum as much as he used to, and the fact "we" haven't been any updates in over 2 months, is also very strange.

Many components that are used by RipBot have seen several new builds made available in the past 2 months.

Now, I do recall Atak mentioning that his main PC was not working, a week or so ago, and we don't know if there any other circumstances that might be keeping him from the forum(s), if Covid-19 has something to do with it, then so be it, that IS affecting EVERYONE.

So unless individual users update the components themselves, we'll just have to wait.

I have to admit I actually haven't used RB for month's...I have a nice Ryzen 9 3950X setup, and I just haven't been using it.

But I do check for updates nearly every day.

[duffbeer]

Anyone know if it's safe to manually update x264 and x265 in RB? x264 has had a few updates recently and I'd like to start using them.

[GZZ]

Anyone know if it's safe to manually update x264 and x265 in RB? x264 has had a few updates recently and I'd like to start using them.

You can try replace it (dont complain if it dosnt, but if encoding start then it works). The GCC AVX2 build from the master bench should work.

http://msystem.waw.pl/x265/

[guest]

Anyone know if it's safe to manually update x264 and x265 in RB? x264 has had a few updates recently and I'd like to start using them.

As GZZ mentioned...I did a lot of "manual" updates a couple of weeks ago, as many of the RB components have had updates in the time it's been since the last official update, well over 2 months ago, now.

But with x264 & x265, the .exe files that Atak provides are named differently to the .exe you would get from GZZ's reference page, and the file size's will also be different, however, if you re name them to how they are named in RB, then just overwrite them (maybe keep the originals as a backup, jic), and again, as GZZ said, if it starts to encode, then it works :).

Update:- I just downloaded the latest, (x265-3.4+12-geff9_gcc101-AVX2) and I would think if you simply renamed the x265-10b.exe to x265_x64.exe, in the "Tools/x265" folder, you should be good to go.

Good luck :rolleyes:

[GZZ]

Update:- I just downloaded the latest, (x265-3.4+12-geff9_gcc101-AVX2) and I would think if you simply renamed the x265-10b.exe to x265_x64.exe, in the "Tools/x265" folder, you should be good to go.

Good luck :rolleyes:


Use the X265.exe and do a x265.exe --version and check if it contains the 8+10+12 bit compile.

e:\RipBot264v\Tools\x265>x265_x64.exe --version (Below is the new build 3.4+12)
x265 [info]: HEVC encoder version 3.4+12-geff904199
x265 [info]: build info [Windows][GCC 10.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

Compare the data with the original to make sure its build with the same settings. GCC version is ofcourse newer.

[guest]

Use the X265.exe and do a x265.exe --version and check if it contains the 8+10+12 bit compile.

e:\RipBot264v\Tools\x265>x265_x64.exe --version (Below is the new build 3.4+12)
x265 [info]: HEVC encoder version 3.4+12-geff904199
x265 [info]: build info [Windows][GCC 10.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

Compare the data with the original to make sure its build with the same settings. GCC version is ofcourse newer.

Fair enough, but if you were only using 10bit, wouldn't the 10b.exe do the job ??

Good info, tho :)

[GZZ]

Fair enough, but if you were only using 10bit, wouldn't the 10b.exe do the job ??

Good info, tho :)

it would, but if you do a 8bit encoding using x265 it will properly fail.

[Ryushin]

It's strange to me that Atak hasn't been around much lately. I wonder if something happened to him in his life? He could also be getting burnt out with this project.

I hope he doesn't give up on this project though. I use it every day.

Atak, if you ever feel like you want to shelve this project, please put it up on Github or something like that so that it does not die.

[guest]

It's strange to me that Atak hasn't been around much lately. I wonder if something happened to him in his life? He could also be getting burnt out with this project.

I hope he doesn't give up on this project though. I use it every day.

Atak, if you ever feel like you want to shelve this project, please put it up on Github or something like that so that it does not die.

Hey Ryushin, actually you haven't posted on this forum much lately, either :)

Good to know that you're using RB everyday, I haven't encoded anything for months, but I keep it updated, myself.

Yes, it's a bit of a mystery, his last post was 22/06, nearly a month back, there's been no updates of any kind for 2.5 months, and unless you are able to update some of the "important" components of RB yourself, then you're stuck. :mad:

However, he has been fairly "busy" on his Windows 7 forum, his last post there was about a week ago..so maybe he's happy were RB is, and is more centred on keeping the past alive, by spending his time on Windows 7.

Who knows, he might be working on a totally revamped build, I guess we'll never know. But a current update or comment on this forum would be nice, just so we know "where he's at" :D

[jlpsvk]

i have come to a strange problem...

when encoding 1917 with HDR10+ metadata, encode gets only 171168 frames instead of 171176. when encoding without HDR10+ metadata json, everything is OK. using latest LigH's build (3.4+9).

used the same JSON with NVENC and all good... so not JSON metadata file problem... x265 or RipBot's fault?

[guest]

i have come to a strange problem...

when encoding 1917 with HDR10+ metadata, encode gets only 171168 frames instead of 171176. when encoding without HDR10+ metadata json, everything is OK. using latest LigH's build (3.4+9).

used the same JSON with NVENC and all good... so not JSON metadata file problem... x265 or RipBot's fault?

So even tho it's missing 8 frames, does it playback OK ??

Try (x265-3.4+12-geff9_gcc101-AVX2) (link is a couple of post back from this) GZZ #18619

[jlpsvk]

So even tho it's missing 8 frames, does it playback OK ??

Try (x265-3.4+12-geff9_gcc101-AVX2) (link is a couple of post back from this) GZZ #18619

yes... it plays fine... but when i try to mux with Dolby Vision, it makes problem. It must have the same amount of frames as EL+RPU.

[GZZ]

i have come to a strange problem...

when encoding 1917 with HDR10+ metadata, encode gets only 171168 frames instead of 171176. when encoding without HDR10+ metadata json, everything is OK. using latest LigH's build (3.4+9).

used the same JSON with NVENC and all good... so not JSON metadata file problem... x265 or RipBot's fault?

if you are already on 3.4+9 and it works, then keep it. No reason to use time on a build that is almost identical. The only reason we updated was because the version included with Ripbot was on version 3.2 or 3.3.

[jlpsvk]

if you are already on 3.4+9 and it works, then keep it. No reason to use time on a build that is almost identical. The only reason we updated was because the version included with Ripbot was on version 3.2 or 3.3.

it works... but there is a problem...

when i want to mux it to dvhe.04, muxer will fail, as BL has different number of frames as EL+RPU... so it is a problem.. without HDR10+ metadata, encode has the same exact frame numer... so problem would be in x265, whe used with HDR10+ JSON

[Atak_Snajpera]

Is frame number correctly detected in ripbot?
Is frame number correctly displayed in x265 during encoding?

[jlpsvk]

Is frame number correctly detected in ripbot?
Is frame number correctly displayed in x265 during encoding?

yes and yes. but output is not correct. :( it doesn't matter which GUI i use... :( always few frames missing at the end. without HDR10+ JSON everything is OK, encoded with the same JSON but with nVidia GPU, frames are OK.

[blublub]

Hi

What could be the reason why the Encoding server won't start up correctly? In 9 out of 10 reboots the encodingserver process shows in taskmanager but I do not see the tray icon and whenever this happens the encoding client can't connect.

thx for any help

[Atak_Snajpera]

Hi

What could be the reason why the Encoding server won't start up correctly? In 9 out of 10 reboots the encodingserver process shows in taskmanager but I do not see the tray icon and whenever this happens the encoding client can't connect.

thx for any help

Some application running in background (from MSI/Gigabyte/Logitech and so on) blocks encodingserver.exe. Known issue. There is nothing I can do about that because that is not my fault.

[blublub]

OK, thx. I do have MSI Afterburner running, I guess that's it - sorry to ask if it's a known issue

[Ryushin]

Atak, can an option be added for a number of threads to open for cropping or to limit it based on memory. Using auto cropping with 4K will use up 16GB of memory and Windows will kill other processes, including the Encoding Client.

I'm having to use manual cropping for 4K if I don't want processes killed.

[SKPN]

I'm having a slight issue with colors, specifically skin tones. For some reason, when I encode with RipBot, it's altering the colors slightly on the video, and I cannot figure out why.

Here is an example:
https://imgsli.com/MjAwMTM

The encoded video makes the skin look slightly orange. Other colors are affected as well, but the skin is the most noticeable. I'm not using any settings that would change the colors, so I'm not sure what the deal is.

[Atak_Snajpera]

I'm having a slight issue with colors, specifically skin tones. For some reason, when I encode with RipBot, it's altering the colors slightly on the video, and I cannot figure out why.

Here is an example:
https://imgsli.com/MjAwMTM

The encoded video makes the skin look slightly orange. Other colors are affected as well, but the skin is the most noticeable. I'm not using any settings that would change the colors, so I'm not sure what the deal is.

Post mediainfo report from original file and encoded one.

[SKPN]

Post mediainfo report from original file and encoded one.

Original
Video
ID : 1
ID in the original source medium : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 24 min 21 s
Bit rate mode : Variable
Bit rate : 4 412 kb/s
Maximum bit rate : 9 000 kb/s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.426
Time code of first frame : 00:59:59:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 769 MiB (92%)
Language : English
Default : No
Forced : No
Original source medium : DVD-Video

Encoded
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L3@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 24 min 21 s
Bit rate : 1 477 kb/s
Width : 632 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.162
Stream size : 257 MiB (79%)
Writing library : x265 3.2+34-8e6db24c1517:[Windows][GCC 9.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=+ / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=632x480 / interlace=0 / total-frames=1797 / 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=30 / keyint=300 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=16 / min-cu-size=8 / no-rect / no-amp / max-tu-size=16 / 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=9 / 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=16 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / 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 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / 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 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

[LigH]

DVD video usually has color primaries BT.601, as usual for "vintage" media with SD resolutions. Between BT.601 and BT.709, you will experience some green/red shift: see http://avisynth.nl/index.php/Colorimetry

The simple solution should be to tell the encoder to flag its encoded output as BT.601 (or Rec601).

[guest]

DVD video usually has color primaries BT.601, as usual for "vintage" media with SD resolutions. Between BT.601 and BT.709, you will experience some green/red shift: see http://avisynth.nl/index.php/Colorimetry

The simple solution should be to tell the encoder to flag its encoded output as BT.601 (or Rec601).

Would that be possible with RB ??

Either a Custom Script or modding one ???

[archiel]

Over the last week the Output Speed option has started giving problems. If I use any setting other than default then

The FPS on the main screen does not change
The Duration on the main screen does not change
Once encoding is started a 'info.txt does not exist' error is generated


After which the script goes directly to the final re-encode and shows 'Error: The file 'H:\Temp\RipBot264temp\job2\video.265' could not be opened for reading: open file error.'

Re-setting Output Speed to default allow the program to run.

I use this option where I have used MkvCutter to edit and re-encode the start of a video. As it re-encodes at 24 fps regardless of the speed of original, I need to use the Output Speed to prevent the audio and video being out of sync.

I have tested on the same video, before and after using MkvCutter, in each case RipBot264 runs normally if Output Speed is default and fails for any other setting.

[guest]

Over the last week the Output Speed option has started giving problems. If I use any setting other than default then

The FPS on the main screen does not change
The Duration on the main screen does not change
Once encoding is started a 'info.txt does not exist' error is generated


After which the script goes directly to the final re-encode and shows 'Error: The file 'H:\Temp\RipBot264temp\job2\video.265' could not be opened for reading: open file error.'

Re-setting Output Speed to default allow the program to run.

I use this option where I have used MkvCutter to edit and re-encode the start of a video. As it re-encodes at 24 fps regardless of the speed of original, I need to use the Output Speed to prevent the audio and video being out of sync.

I have tested on the same video, before and after using MkvCutter, in each case RipBot264 runs normally if Output Speed is default and fails for any other setting.

Good luck...

Have you heard of VideoRedo or AviDemux ??

https://www.videohelp.com/software/sections/video-editors-h264-avc

[archiel]

Good luck...

Have you heard of VideoRedo or AviDemux ??

https://www.videohelp.com/software/sections/video-editors-h264-avc

While I realise I can look at other solutions, I have been using RipBot264 with the Output Speed option for many years without any difficulty. What I am more interested in is how this can be fixed so that it works as intended.

[guest]

While I realise I can look at other solutions, I have been using RipBot264 with the Output Speed option for many years without any difficulty. What I am more interested in is how this can be fixed so that it works as intended.

That's why I said "Good Luck"....

There's not a lot going on with RB, atm, unfortunately.

[Ripmann]

Another minor potential improvement idea:

When you enter the AviSynth menu and immediately exit it without changing the settings (I do it all the time to double check I didn't forget to setup denoising, etc.), the program still hangs for a while with the "Please Wait...Gathering Information..." tooltip. Usually it's quick, but in some cases the waiting process can take a while.

Theoretically (and again, without knowing the internal workings of the program), it should be very easy to set up a quick boolean flag code for tracking changes and allow exiting the menu without any delays or updates if no changes were made. Not sure if you want to bother with this one, but as a loyal and dedicated user of your software I'll just keep throwing every minor flaw or room for improvement I can find out there in case they may interest you.

[guest]

Another minor potential improvement idea:

When you enter the AviSynth menu and immediately exit it without changing the settings (I do it all the time to double check I didn't forget to setup denoising, etc.), the program still hangs for a while with the "Please Wait...Gathering Information..." tooltip. Usually it's quick, but in some cases the waiting process can take a while.

Theoretically (and again, without knowing the internal workings of the program), it should be very easy to set up a quick boolean flag code for tracking changes and allow exiting the menu without any delays or updates if no changes were made. Not sure if you want to bother with this one, but as a loyal and dedicated user of your software I'll just keep throwing every minor flaw or room for improvement I can find out there in case they may interest you.

Did you happen to read the previous post(s) ???

[blacksapprow]

New x266 codec is coming, :)

https://www.extremetech.com/extreme/312421-new-vvc-h-266-codec-is-a-step-towards-8k

I hope ripbot will get that add on soon....

[LigH]

Any H.266 / VVC codec is not automatically "x266". These x26# brands are usually related to the VideoLAN network (http://www.videolan.org/projects/).

[blacksapprow]

@LigH this one is from fraunhoffer and not related with network. Follow the link above, (I have mistyped as x266, but of course this is H.266....)

Meanwhile not only H.266 codec, latest Magix Vegas Pro 18 bring Colorization to films. I don't know is that possible for Ripbot to include. It needs fixing with bar adjustments, but at mobile phones, this is done automatically & immediately with chromatix application. Maybe that way, can be a future add on for ripbot, I hope!

[LigH]

Well, hold your horses then ... Fraunhofer created the VVC codec, yes. But it is only a reference encoder so far. Made to create correct output. Not made to be usably performant. Before using this codec for serious work, you will have to wait for optimized implementations. It doesn't make sense to wait weeks for a conversion of a movie.

[colinhunt]

Hey Atak_Snajpera, I finally took the time to give RipBot264 a shot, and I'm loving it. I actually got goosebumps seeing 1080p video being encoded in hevc at 160 fps :) Thanks for creating this awesome software.

One question (or feature request): does/can RipBot support image sequences, as in thousands of PNG/TIF files? Googling didn't give me an answer.

edit: did a bit more googling and stumbled on ImageSource() in an .avs script. Let's see what happens...

[yuryna]

@Atak_Snajpera
Any news about 3 pass support?

Now a question,
how do you choose the breaking point of chunks to distribute among all the client?

It's randomly chosen (i don't think so),
it just mathematically chosen (Total frames / some formula)
fixed number (the chunk is always N frames)?

I think it would be nice to make the chunks lenght basing on "scene change detection".

In this way the distributed chunks would be much more compression/optimized by the x264 which will not find itself in a "scene change" situation with only 5 frames to encode (because the remaining frames of the same scene have been distributed to other client).

The final compression would be more safe and optimized thanks to distribution of key frames (and all that follow) inside the same scene.

What do you think about it?

[Atak_Snajpera]

I think it would be nice to make the chunks lenght basing on "scene change detection".
That would only create HUGE bottleneck because you would have to analyze whole movie before starting encoding. My workaround is to start chunk at key-frame detected in source file (hence chunks have irregular number of frames). Not perfect but still better than starting chunk at some "random" frame.

[yuryna]

start chunk at key-frame detected in source file

Wise solution.

For the bottlenek you could make it just a selectable option,

in order to satisfy the deep-quality-researcher too (who don't mind encoding time (like myself? eheh :))).

I think it would be a good compromise (the "choice" is always a good added-value).

[blacksapprow]

@LigH

Don't worry, H.266 can't come so quick, and we are upgrading our systems generally within 5 years. But, if a film size shortens %50, I may love it. Because hard drives are really expensive. 2 piece of 10GB hard drive, equals to a good graphics card. This one will provide only 1 piece of 10GB in a way. Encoding took 6,5 times but playing only needs 1,5 times processing power. For me, this is not bad....

[LigH]

Did you mean 10 TB?

[slalom]

@Atak

there is a problem when downloading a poster

[userx]

Hello!

Not sure what happens here:
In DE mode chunks always restart after 100%.
I recently got an update to W10 2004 but i temporary disabled DE mode. Latest nvidia driver is installed.



439|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.2:1000 -> [98.3%] 1462/1488 frames, 126.43 fps, 2888.16 kbps, eta 0:00:00;CHUNK=1;CPU=92;RAM=58;DECODER=23;ENCODER=43;OTHER=26;ENCODING_PRIORITY=low;
440|CLIENT -> SERVER| OK
441|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
442|CLIENT <- SERVER| OK
443|CLIENT <- SERVER| ENCODING_FINISHED
444|CLIENT -> SERVER| OK
445|CLIENT -> SERVER| GET_ENCODING_SUMMARY
446|CLIENT <- SERVER| OK
447|CLIENT <- SERVER| ENCODING_SUMMARY=192.168.1.2:1000 -> ERROR;CHUNK=1;CPU=92;RAM=55;DECODER=0;ENCODER=0;OTHER=92;ENCODING_PRIORITY=low;
448|CLIENT -> SERVER| OK
449|CLIENT -> SERVER| STANDBY
450|CLIENT <- SERVER| OK
451|CLIENT <- SERVER| SERVER_IDLE
452|CLIENT -> SERVER| OK
453|CLIENT -> SERVER| ENCODE_CHUNK_1=\\PC\RipBot264temp\job1\Chunks\1.cmd

I noticed I have to switch the OPENCL device to NONE to use the DE mode.
0.0 Device name : GeForce GTX 970
Hardware version : OpenCL 1.2 CUDA
Software version : 452.06
OpenCL C version : OpenCL C 1.2
Compute units : 13

1.0 Device name : Intel(R) HD Graphics 4600
Hardware version : OpenCL 1.2
Software version : 20.19.15.4835
OpenCL C version : OpenCL C 1.2
Compute units : 20

Some time ago, i had the same problem with my AMD Radeon 7700 but it seems Capeverde is not well supported or something else. Now i'm not able to use my Nvidia card.
Does anybody have an idea what happens?