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

[Dhry]

Ripbot takes forever analyzing an MKV file I'm trying to transcode, and then throws this error into the JobsRejected.txt file:

LWLibavAudioSource: failed to open resampler.
(F:\Temp\RipBot264temp\job1\getinfo.avs, line 4)

Looks like this section of the avs file is:

4
5 #VideoSource
6 LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
7 video=LWLibavVideoSource("<my filename>.mkv",cachefile="F:\Temp\RipBot264temp\job1\<my filename>.mkv.lwi",prefer_hw=3)

Any thoughts on how to fix?

[slalom]

When file EncodingProgress.Pass1 or EncodingProgress.Pass2 in Chunks folder is missing then you lose whole progress. That file is being updated every time chunk gets encoded.
If someone can't avoid that, it would be nice to be able to select the remaining chunks (manually, like 64 to 95) for example right click, partial encode

and then run 2 cmds, CombineAllChunks & jobX_MuxFiles to get the job done

4K 10bit takes a lot of hours to complete!

[ReinerSchweinlin]

Hi,

thanx once again for your wonderful peace of software :)

Any chance of supporting AMD Hardware-decoders?

[guest]

When file EncodingProgress.Pass1 or EncodingProgress.Pass2 in Chunks folder is missing then you lose whole progress. That file is being updated every time chunk gets encoded. For your unstable PC I guess I would have to implement some backup system...

Regarding crashing ffmpeg.exe. I've just checked the code in EncodingServer.exe and crash window will always be automatically closed regardless of switches used. It would be much easier if you just manually executed /Chunks/1.cmd from shared folder and then expand details. Look for FAULTY MODULE: line

How come when ever there’s a problem with something to do with the RipBot process, you blame the user’s computer ???

I’m not too impressed with you're suggesting that my PC in faulty.

The PC I'm using for this is a Ryzen 9 3950X, not over clocked, a descent amount of RAM, SSD’s & Nvme’s for the main temp & processing drives for RB, I have to say that the ONLY thing faulty, is your software.

It happens on every PC I use, when encoding BIG x265 encodes.

I have been using RipBot264 for many, many years, and I have tried to help you sort out some problems along the way, and for most encoding, RipBot is pretty much the “top of the heap”, for anything up 1080p !!!

Once you start getting into movie length x265 encodes, with even basic filters, it’s really not up to the task (in my opinion).

The allure of Distributed Encoding is exclusive to RB, but I believe there is a lot more than needs to be engineered into it, so it handles LONG x265 encodes, which in some case can be days in the process, and it HAS to be super reliable.

When you are not willing or able to let the DE process run it’s course in one hit, due to power cost’s, etc, there HAS to be a very reliable resume function.

I have approached a some other RipBot user’s, and they have said that the DE process does have problems with long encodes, and the resume function does not always work, and the encoding already done, is lost, and that can be many, many hour’s…for nothing.

So it’s not just my “faulty pc”, it must be everybody’s faulty pc’s.

I sincerely challenge you to somehow get a movie length x265, HEVC, UHD (whatever you want to call it) file, and load it into what ever system you’ve got, give it an Mdegrain1 filter, and DE, and see how you go, stressing that you have to stop (Abort) it randomly…I can almost guarantee, it WILL fail.

Another thing that is very miss leading is the ETA counter when doing x265 encodes, with DE.

If it displays that it’s going to take, say 8 hours, then it’s more like 24…you test it, you’ll see what I mean. It’s fine with everything else, but not x265, so you really have no idea how long it’s going to take…you just have to let it go. :(

As far as I am aware, you are running Windows 7 on a single Xeon E5-2690 (not too sure), so that IS going to take a LONG, LONG time !!
It’s about the least you can do, to prove that it’s not our faulty pc’s.

So just quoting your reply to me :-

When file EncodingProgress.Pass1 or EncodingProgress.Pass2 in Chunks folder is missing then you lose whole progress. That file is being updated every time chunk gets encoded. For your unstable PC I guess I would have to implement some backup system...

So what causes those .pass files to go missing ??? …oh wait, it’s because RipBot didn’t shutdown properly !!

Maybe YOU need to implement some redundancy, during the process.

Regarding crashing ffmpeg.exe. I've just checked the code in EncodingServer.exe and crash window will always be automatically closed regardless of switches used. It would be much easier if you just manually executed /Chunks/1.cmd from shared folder and then expand details. Look for FAULTY MODULE: line

And how do you test your code ?? I bet it’s not on x265 files, or Windows 10 !!

So, I’m not trying to piss you off, I am trying to get you to understand that there are problems that need to be at least checked & tested thoroughly, due to the amount of time the process takes.

Us user’s want to get the encodes done with as little drama as possible, not be chasing faults & time wasting re starts of the encoding process.

[Atak_Snajpera]

If you are so confident that resume does not work most of the time then check if encodingprogress.pass1 is still present before and after you click abort. Your rants are meaningless for me if you do not provide any valuable feedback. (You didn't even bother to check why ffmpeg.exe crashed!)I'm not a fortune teller for god sake! (yet).

[Ryushin]

I’m not too impressed with you're suggesting that my PC in faulty.

The PC I'm using for this is a Ryzen 9 3950X, not over clocked, a descent amount of RAM, SSD’s & Nvme’s for the main temp & processing drives for RB, I have to say that the ONLY thing faulty, is your software.

It happens on every PC I use, when encoding BIG x265 encodes.

Once you start getting into movie length x265 encodes, with even basic filters, it’s really not up to the task (in my opinion).

The allure of Distributed Encoding is exclusive to RB, but I believe there is a lot more than needs to be engineered into it, so it handles LONG x265 encodes, which in some case can be days in the process, and it HAS to be super reliable.

I sincerely challenge you to somehow get a movie length x265, HEVC, UHD (whatever you want to call it) file, and load it into what ever system you’ve got, give it an Mdegrain1 filter, and DE, and see how you go, stressing that you have to stop (Abort) it randomly…I can almost guarantee, it WILL fail.

Another thing that is very miss leading is the ETA counter when doing x265 encodes, with DE.

If it displays that it’s going to take, say 8 hours, then it’s more like 24…you test it, you’ll see what I mean. It’s fine with everything else, but not x265, so you really have no idea how long it’s going to take…you just have to let it go. :(


I don't think it's fair to blame Atak and Ripbot264 about x265. x265 is a whole new beast compared to x264. For me, with my settings, x265 takes four times longer to encode than x264. Add 4K to that and a 4K movie takes 16 times longer to encode than a HD using x264. I've encoded over 400 4K movies with great success. Though I'm not aborting my jobs and resuming for the most part. My jobs run straight through.

If you need jobs to complete within a certain time frame, you might have to add more CPU power to your mix or battery (LiFePO4) backup so the servers can keep running when the solar is not producing.

About reliability. My servers are rock solid. Run ECC memory, ZFS, etc. The Win10 VM that runs RipBot264 sits on top of Linux running KVM/LibvirtD. I don't have any issues except that occasional bug when click "Done" the job gets stuck and I have to abort RB. When I have to abort, about 1 in 10 times RB will have the job start over. I really don't have hardly any issues with RB and I'm very happy to have it.

[guest]

If you are so confident that resume does not work most of the time then check if encodingprogress.pass1 is still present before and after you click abort. Your rants are meaningless for me if you do not provide any valuable feedback. (You didn't even bother to check why ffmpeg.exe crashed!)I'm not a fortune teller for god sake! (yet).

I'll tell you why I didn't check ffmpeg...as soon as I saw that it was starting from scratch, I stopped it, and deleted the job !!!

What's the point, it'll probably happen again :(

When situations like this arise, most of us users have no idea what course of action to take, but you do, as you created it, so none of us, are fortune tellers, or mind readers !!

So it's hard to provide you with the "feedback" that you would like.

[Ryushin]

I wanted to add that RB is the only program I know that can even resume an encode, at least in DE mode. I think in single threaded mode even RB will start over from scratch.

That being said, I do think resuming aborted jobs could work a bit better as that should work 100% of the time. For one of my clients, I deal with very large movie jobs, often larger than 1TB in size. Because this is commercial works, corruption could be hard to detect without using MD5 sums for the files.

Atak, perhaps when a chunk is finished, a MD5 sum is recorded in <chunk#>.md5 file. Upon recovering a job, if there are any .md5 files, they are compared with the chunk and if missing or incorrect, that chunk is encoded again. Then a master file has a list of the the number of chunks and that should not have to change. I'm more than willing to wait for a few cpu/storage cycles to resume a job.

[chainring]

FWIW, I've processed hundreds of 4K HDR movies with RipBot, all with x265 and the vast majority in DE mode. Failures are the exception, not the rule from what I've experienced. Four Windows 10 machines, all Dell and I make sure all updates are current before starting an encode party. When there is a failure; more like a stall, it's been older movies and generally ones where I'm taming grain with MDegrain. Those can sometimes be a royal pain since it'll stall the queue.

[slalom]

I wanted to add that RB is the only program I know that can even resume an encode, at least in DE mode. I think in single threaded mode even RB will start over from scratch.

That being said, I do think resuming aborted jobs could work a bit better as that should work 100% of the time. For one of my clients, I deal with very large movie jobs, often larger than 1TB in size. Because this is commercial works, corruption could be hard to detect without using MD5 sums for the files.

Atak, perhaps when a chunk is finished, a MD5 sum is recorded in <chunk#>.md5 file. Upon recovering a job, if there are any .md5 files, they are compared with the chunk and if missing or incorrect, that chunk is encoded again. Then a master file has a list of the the number of chunks and that should not have to change. I'm more than willing to wait for a few cpu/storage cycles to resume a job.
I'll give you a scenario, abort a job, add 2 other jobs, edit them and restart encoding (the aborted one, doesn't have to be 4K/h265)

MD5 sums is a very good idea! Don't know much about that but I hear it

I do little 4K by choice, and I use mainly MDegrain1 or nothing so I don't loose much time to cry for

[guest]

I don't think it's fair to blame Atak and Ripbot264 about x265. x265 is a whole new beast compared to x264. For me, with my settings, x265 takes four times longer to encode than x264. Add 4K to that and a 4K movie takes 16 times longer to encode than a HD using x264. I've encoded over 400 4K movies with great success. Though I'm not aborting my jobs and resuming for the most part. My jobs run straight through.

If you need jobs to complete within a certain time frame, you might have to add more CPU power to your mix or battery (LiFePO4) backup so the servers can keep running when the solar is not producing.

About reliability. My servers are rock solid. Run ECC memory, ZFS, etc. The Win10 VM that runs RipBot264 sits on top of Linux running KVM/LibvirtD. I don't have any issues except that occasional bug when click "Done" the job gets stuck and I have to abort RB. When I have to abort, about 1 in 10 times RB will have the job start over. I really don't have hardly any issues with RB and I'm very happy to have it.

It wasn't until I read your post that I realised that I had made a significant oversight in my "rant".

It seemed like I was wholey & soley blaming x265, when that wasn't my point...I know I should have written 4K encodes (as they are x265 by default, generally)..anyway, the main thing behind the whole post was DE's problems with LONG 4K encodes.

[guest]

So, my post has sparked some interesting discussion, pro's & con's, which is all good.

Some possible very worthwhile suggestions have been made.

Here's another suggestion (for the future), what if the current RipBot264 was re-configured to ONLY process 4K (and upwards) movies !!!

It could have all the x264 & batch options ripped out, an error checking process on DE, the ETA meter synced, and that's it.

It could be called RipBot4K, or RipBotUHD...anyway you get my drift.

[Atak_Snajpera]

No .

[ReinerSchweinlin]

Last digit indicates how many previous and next frames are taken for analysis. More means stronger denoising and more stable output.
MDegrain aims for fine detail retention while knlmeanscl is much more aggressive. My recommendation is as follows. Use MDegrain first and then knlmeanscl if you still need to remove any grain leftovers.

thanx for clarifying :)
Am I correct that older versions had "degrain 2" as option, so chossing degrain 2 gives the exact same results as older ones ? (I am asking because I started a Series of encodes which is around 40% finished and I would like to keep the settings..)

What happened to "adaptive" in the KNLMEANS Tab? (Just curious on this one)

I am just exploring some openCL Stuff on a VEGA64 and was wondering, if it would be possible to support the AMD Video Decoder in Ripbot.

[whiskey]

Anybody else still has issues removing lots of files at once from the batch window? Despite having all files selected it only removes one, then I have to de-select another one just to remove one more...

[guest]

No .

I know you probably don't want to hear much more about this, but I'm hoping you didn't misunderstand what I was suggesting.

Due to your emphatic "No" !!

I was not suggesting for a second that you "gut" RipBot264, what I thought was a "twin" app, based on RipBot, but it ONLY did 4K x265 (and above) file encoding. :cool:

[ReinerSchweinlin]

Anybody else still has issues removing lots of files at once from the batch window? Despite having all files selected it only removes one, then I have to de-select another one just to remove one more...
I remember using the "del" key to quickly get rid of a lot of entries.

[slalom]

thanx for clarifying :)
Am I correct that older versions had "degrain 2" as option, so chossing degrain 2 gives the exact same results as older ones ? (I am asking because I started a Series of encodes which is around 40% finished and I would like to keep the settings..)
It is exactly the same
Anybody else still has issues removing lots of files at once from the batch window? Despite having all files selected it only removes one, then I have to de-select another one just to remove one more...
No issues here

[GZZ]

It wasn't until I read your post that I realised that I had made a significant oversight in my "rant".

It seemed like I was wholey & soley blaming x265, when that wasn't my point...I know I should have written 4K encodes (as they are x265 by default, generally)..anyway, the main thing behind the whole post was DE's problems with LONG 4K encodes.

What is a long 4k encode ?

I have done close to 300 UHD 4K encoding to MKV with ripbots. I have done it with MDegrain 1, 2 and a few with 3. By long you mean in number of frames (duration) and for that I done The Deer Hunter and The Bridge On The River Kwai have taking looooong time because of MDegrain2 filter and I havent had a failure with encoding. Doing DE on 2 machines. Machine 1: Ryzen 3700x, Machine 2:Intel Core I7 8700K (none of the them is overclocked). All HDD is SSD.

I cant reconize a failure and I would like to know a title that fails for you, if the fail isnt repeatable and its random, then I would suspect hardware issues or network problems. Network problems is the thing that can give must issues and be hard to troubleshoot. I had a unstable USB network dongle once and it was a pain in the but, it could fail if I "overloaded" it with copy jobs.

[guest]

What is a long 4k encode ?

I have done close to 300 UHD 4K encoding to MKV with ripbots. I have done it with MDegrain 1, 2 and a few with 3. By long you mean in number of frames (duration) and for that I done The Deer Hunter and The Bridge On The River Kwai have taking looooong time because of MDegrain2 filter and I havent had a failure with encoding. Doing DE on 2 machines. Machine 1: Ryzen 3700x, Machine 2:Intel Core I7 8700K (none of the them is overclocked). All HDD is SSD.

I cant reconize a failure and I would like to know a title that fails for you, if the fail isnt repeatable and its random, then I would suspect hardware issues or network problems. Network problems is the thing that can give must issues and be hard to troubleshoot. I had a unstable USB network dongle once and it was a pain in the but, it could fail if I "overloaded" it with copy jobs.

Hi GZZ,

I would classify a long 4K encode anything approaching 3 hours, and over, more that 180 + chunks !!!

I was doing The Hobbit - An Unexpected Journey, extended version, using MDegrain1.(3 hours 4 minutes, I believe)

I had it setup on my Ryzen 3950X (as the client), and had a couple of servers helping along, a 3930K, Xeon E5-2697 v2, and dual Xeon E5-2690.

Now I have to say that I was NEVER intending on doing this in one "session", so I was going to have to rely on the resume function, that is sort of the DE process.

So I got thru approx 80 - 90 chunks the first day, Ripbot shutdown OK, next time, it resumed, so I did another 40 +/- chunks, using different "servers", but when it was time to shutdown for the day, I waited until the processing chunks were done, and then close them individually, then when I went to close down RipBot, it just froze, "not responding", and stayed that way for quite some time, until eventually I just had to kill it....I just knew that next time, there will be a resuming problem...

So next time, sure enough, it had "forgotten" where is was up to (approx 120 chunks had been done), and it started from chunk #1 !!!

Because it had started processing I thought there was no real course of action to be taken, so I just stopped it in disgust, and deleted the job.

Some would say that this might be my fault by not doing it in "one hit", but I refuse to do that due to electricity costs.

So for reliability of the resumption of DE, it needs to be some how backed up, or error checked during the process, so this doesn't happen.

Now I can't tell you what files I have problems with, as it's random !!

I would like to ask you about the ETA counter....do you find that it's "slow" when doing 4K encodes ??? I find that what ever it display's, you need to multiply that by about 3, (eg: a 6 hours displayed ETA, is closer to about 18), by the time the encode if done.

OK, so how long do your looooong encodes take, with your hardware setup ??

Do you do your encode in one hit ??

See, if no one else has to stop their encodes, they have no idea what I'm on about, and I am made out to be the "bad guy" !!!

[GZZ]

Hi GZZ,

I would classify a long 4K encode anything approaching 3 hours, and over, more that 180 + chunks !!!

I was doing The Hobbit - An Unexpected Journey, extended version, using MDegrain1.(3 hours 4 minutes, I believe)

I had it setup on my Ryzen 3950X (as the client), and had a couple of servers helping along, a 3930K, Xeon E5-2697 v2, and dual Xeon E5-2690.

Now I have to say that I was NEVER intending on doing this in one "session", so I was going to have to rely on the resume function, that is sort of the DE process.

So I got thru approx 80 - 90 chunks the first day, Ripbot shutdown OK, next time, it resumed, so I did another 40 +/- chunks, using different "servers", but when it was time to shutdown for the day, I waited until the processing chunks were done, and then close them individually, then when I went to close down RipBot, it just froze, "not responding", and stayed that way for quite some time, until eventually I just had to kill it....I just knew that next time, there will be a resuming problem...

So next time, sure enough, it had "forgotten" where is was up to (approx 120 chunks had been done), and it started from chunk #1 !!!

Because it had started processing I thought there was no real course of action to be taken, so I just stopped it in disgust, and deleted the job.

Some would say that this might be my fault by not doing it in "one hit", but I refuse to do that due to electricity costs.

So for reliability of the resumption of DE, it needs to be some how backed up, or error checked during the process, so this doesn't happen.

Now I can't tell you what files I have problems with, as it's random !!

I would like to ask you about the ETA counter....do you find that it's "slow" when doing 4K encodes ??? I find that what ever it display's, you need to multiply that by about 3, (eg: a 6 hours displayed ETA, is closer to about 18), by the time the encode if done.

OK, so how long do your looooong encodes take, with your hardware setup ??

Do you do your encode in one hit ??

See, if no one else has to stop their encodes, they have no idea what I'm on about, and I am made out to be the "bad guy" !!!


I havent had an issue with stopping after a specfic chunk. I just disable the servers in Encoding Client and when all chunk is stopped I click the Abort button the Ripbot264 window, DONT close the Encoding Client by clicking the X. If I then restart the job (dont do any editing or change any settings as it will restart all the chunks), then it have worked just fine for me. But normally I do one movie encoding at a time.

I think we have talked about a function to pause DE or abort it when all currently encoding chunk finish, so you can press abort and it will ask you to abort after currently encoding chunk or just abort now and lose currently encoding chunks. That would be a nice feature. Also a big fat Pause button in the Encoding Client to just pause/unpause current encoding, when you need processing power for something else.

I have done all these with MD1
The Hobbit - An Unexpected Journey (Extended Cut).mkv 27.212.789.907
The Hobbit - The Desolation of Smaug (Extended Cut).mkv 25.732.263.184
The Hobbit - The Battle of the Five Armies (Extended Cut).mkv 21.143.328.869
The Lord of the Rings - The Return of the King (Extended Cut).mkv 30.316.006.034
The Lord of the Rings - The Fellowship of the Ring (Extended Cut).mkv 24.249.621.328
The Lord of the Rings - The Two Towers (Extended Cut).mkv 22.888.413.941

its the final size and I didnt have any issues at all. CRF 18, x265, HDR, copping, no resize and MD1. Chunk size is 2 min. So that gave me around 130 chunks for Return of the king extended edition. My encoding speed in DE with 2 machines and this kind of movie is around 4-5 fps. So it took well over 20 hours and close to a full day. I believe return of the king extended edition is the longest movie you will properly encounter.

X265 settings from MKV:
x265 3.4+22-ga988fbbac:[Windows][GCC 10.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=3840x1608 / interlace=0 / total-frames=2869 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / 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 / hist-scenecut=0 / 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 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) / cll=636,103 / 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.03 / no-opt-cu-delta-qp / no-aq-motion / 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 / decoder-max-rate=0

About the ETA counter I find it estimate is ok, you have to do a few chunks for the ETA to settle, specially because the first chunk is sometimes fast because of black frames, logos without any noise and when the movies starts in chunk 2-3 and then it settles correctly. The ETA is based on Avg time of each chunk, thats why its off with just a few chuncks. On 4K movies it can take time, as one chunk might take 10-20 min to encode. So getting 3-4 chunks encoded will take 1 hour. I cant see you can do any better, except for collecting avg. time from other encodings with simular settings, but that will be to overdo it.

[guest]

I havent had an issue with stopping after a specfic chunk. I just disable the servers in Encoding Client and when all chunk is stopped I click the Abort button the Ripbot264 window, DONT close the Encoding Client by clicking the X. If I then restart the job (dont do any editing or change any settings as it will restart all the chunks), then it have worked just fine for me. But normally I do one movie encoding at a time.

Thanks for the great reply :)

I generally try and stop the chunks, as they finish, before I shut down, just in case, or you'd lose that part of the chunk, if you just quit.

Thing is, when you Abort you get a pop up warning, which is a bit misleading, but you've gotta do, what ya gotta do.

I think we have talked about a function to pause DE or abort it when all currently encoding chunk finish, so you can press abort and it will ask you to abort after currently encoding chunk or just abort now and lose currently encoding chunks. That would be a nice feature. Also a big fat Pause button in the Encoding Client to just pause/unpause current encoding, when you need processing power for something else.

Yes, that would be a great new feature, I'm sure several builds / years ago, there was a couple of different ways to shut down, but that was reduced to one :(

I have done all these with MD1
The Hobbit - An Unexpected Journey (Extended Cut).mkv 27.212.789.907
The Hobbit - The Desolation of Smaug (Extended Cut).mkv 25.732.263.184
The Hobbit - The Battle of the Five Armies (Extended Cut).mkv 21.143.328.869
The Lord of the Rings - The Return of the King (Extended Cut).mkv 30.316.006.034
The Lord of the Rings - The Fellowship of the Ring (Extended Cut).mkv 24.249.621.328
The Lord of the Rings - The Two Towers (Extended Cut).mkv 22.888.413.941

its the final size and I didnt have any issues at all. CRF 18, x265, HDR, copping, no resize and MD1. Chunk size is 2 min. So that gave me around 130 chunks for Return of the king extended edition. My encoding speed in DE with 2 machines and this kind of movie is around 4-5 fps. So it took well over 20 hours and close to a full day. I believe return of the king extended edition is the longest movie you will properly encounter.

So those numbers I hi lighted in red is the finished size, in mb or something, so just over 30Gb, correct ??

And you use 2 minute chunks...

Not sure why I use 1 minute chunks, probably the impression that it's doing them faster, I guess.

I'll let you know what my fps is, when I'm game to try a 4K encode again.

I did a couple 1080p movies today, x264 to x265, mdg2, took about 1 1/2 hours @ about 50 fps. No DE issues...:)

About the ETA counter I find it estimate is ok, you have to do a few chunks for the ETA to settle, specially because the first chunk is sometimes fast because of black frames, logos without any noise and when the movies starts in chunk 2-3 and then it settles correctly. The ETA is based on Avg time of each chunk, thats why its off with just a few chunks. On 4K movies it can take time, as one chunk might take 10-20 min to encode. So getting 3-4 chunks encoded will take 1 hour. I cant see you can do any better, except for collecting avg. time from other encodings with similar settings, but that will be to overdo it.

Yeah, schools out on that one, I have had issues with it, ever since I started doing 4K encodes, I just don't think it catches up properly, at all :(

[Ryushin]

I use CQ18 for all my encodes. The real issue in quality and size is removing the grain.

For example, I just re-did the Harry Potter series as that was one of my first 4K encodes back when they first came out and I was never happy with its size. I did do CQ18 with that as well, but no degraining.

Here is the comparison on just the video size, without the soundtrack.
Before (CQ18 no degraining)
19G Harry_Potter_1_The_Sorcerers_Stone_2001_4K.mkv
18G Harry_Potter_2_The_Chamber_of_Secrets_2002_4K.mkv
23G Harry_Potter_3_The_Prisoner_of_Azkaban_2004_4K.mkv
20G Harry_Potter_4_The_Goblet_of_Fire_2005_4K.mkv
18G Harry_Potter_5_The_Order_of_The_Phoenix_2007_4K.mkv
17G Harry_Potter_6_The_Half-Blood_Prince_2009_4K.mkv
17G Harry_Potter_7_The_Deathly_Hallows_Part1_2010_4K.mkv
18G Harry_Potter_7_The_Deathly_Hallows_Part2_2011_4K.mkv

After (CQ18 MDegrain2 (thSAD 100-150))
5.98G (MD2-150) Harry_Potter_1_The_Sorcerers_Stone_2001_4K.mkv
5.30G (MD2-150) Harry_Potter_2_The_Chamber_of_Secrets_2002_4K.mkv
8.31G (MD2-150) Harry_Potter_3_The_Prisoner_of_Azkaban_2004_4K.mkv
5.49G (MD2-150) Harry_Potter_4_The_Goblet_of_Fire_2005_4K.mkv
5.20G (MD2-100) Harry_Potter_5_The_Order_of_The_Phoenix_2007_4K.mkv
5.57G (MD2-100) Harry_Potter_6_The_Half-Blood_Prince_2009_4K.mkv
6.54G (MD2-100) Harry_Potter_7_The_Deathly_Hallows_Part1_2010_4K.mkv
7.65G (MD2-150) Harry_Potter_7_The_Deathly_Hallows_Part2_2011_4K.mkv

My wife commented that the new encodes looked a lot better. Just removing that smidgen of grain transforms the video. CQ18 should give you the same picture quality as the original source while the video is playing. If you want to err on the side of more quality, use CQ16.

If I remember correctly, I think I did MDegrain2 with a thSAD of 150 on each Lord of the Rings. Some of these I ran through 2-3 times with different thSAD settings ranging from 100-200 to see what the size turns out to be. My final size (using MKVToolNix to stitch (append) them together into one file)

Lord_of_the_Rings_1_Fellowship_of_the_Ring_2001_EE_4K.mkv 12.9GB
Lord_of_the_Rings_2_Two_Towers_2002_EE_4K.mkv 12.5GB
Lord_of_the_Rings_3_Return_of_the_King_2003_EE_4K.mkv 16.8GB

Just tuning the MDegrain thSAD values can result in a huge decrease in size.

[ReinerSchweinlin]

It is exactly the same
Thanx, that asnwer helped a lot.

[GZZ]

So those numbers I hi lighted in red is the finished size, in mb or something, so just over 30Gb, correct ??

Not sure why I use 1 minute chunks, probably the impression that it's doing them faster, I guess.


Yes, the size is in Byte, so divide it by 30.316.006.034 / 1024 (kb) / 1024 (mb) / 1024 (gb) = Size in GB: ~28GB

If your computers in your DE cluster has the same speed, then using larger chunks will save a little bit of time starting new chunks. But if the slow machine has the last chunk (which is always bigger), then it might take longer then using smaller size chunks. I use 2 min as its a fine ratio for me and limits the number of chunks by half compared to 1 min.

For 1080p encoding, I use 2 DE Servers on each machine (4 encoding in total), I start the DE server with low priority, it satuates the CPU and gives med around 65 FPS on a 1080p encoding without filter, CRF18, X265.

[Ripmann]

Well, GPU encoding uses the available GPU's in your system, generally slower, but it allows for the use of different filters...

Hope this helps a little.

Thanks, it did. So I just want to make sure I got it correctly: if I switch to an equivalent CPU without integrated graphics, my GPU encoding time will increase since it usually uses both integrated and dedicated cards at the same time? I didn't know that. I always assumed it was using the discrete card only.

[guest]

Thanks, it did. So I just want to make sure I got it correctly: if I switch to an equivalent CPU without integrated graphics, my GPU encoding time will increase since it usually uses both integrated and dedicated cards at the same time? I didn't know that. I always assumed it was using the discrete card only.

TBH, I don't use GPU for anything...

What you'll need to do is check what devices are shown under the "OpenCL" tab, and edit your switches to enable what you've got.

At the bottom of the "OpenCL" screen, it will show what device is available for certain functions, if you have the left device displayed, then that will assist during normal encoding (I think), but if you choose GPU decoding or filtering, then that device will be used to process.

I think that's when the switches come into play, when you have multiple GPU's, or you want to be specific in it's use.

Might be a bit of trial & error for you at first.

[LigH]

Using a GPGPU may accelerate the calculation when the algorithm gains a lot from massive parallelism, much more than uploading the video frames from main RAM to video RAM and downloading the results cost overhead.

[slalom]

@Atak

Download poster doesn't work again

[tormento]

6c966b28-e0dd-48f6-b1c7-a56e8a275ec0
What does this ini file do and where should I put it?

[Ryushin]

Based on what I've been reading, FFMPEG should be able to encode 5.1 E-AC3. Can this be add as an option to RB? Based on what I've been reading compression is similar to AAC and E-AC3 can be decoded by modern AVRs which makes it a good replacement for me instead of using for AC3 and AAC.

[tormento]

Based on what I've been reading, FFMPEG should be able to encode 5.1 E-AC3. Can this be add as an option to RB? Based on what I've been reading compression is similar to AAC and E-AC3 can be decoded by modern AVRs which makes it a good replacement for me instead of using for AC3 and AAC.
Yup, I jumped from THD/DTSHD -> AC3 to EAC3 format but I kept the 640kbps that I used in AC3.

[Ryushin]

Yup, I jumped from THD/DTSHD -> AC3 to EAC3 format but I kept the 640kbps that I used in AC3.

That sounds like a good idea. Though I want to keep 3D audio, so I have to keep the full THD+Atmos and DTS:X tracks. But for those shows that have DTS-HD in 5.1, it would be better to use E-AC3 at 640K, and for the streaming versions I create I'll use E-AC3 at 320K instead of AAC.

I looked and I could find no free tools that could do 7.1 channel E-AC3.

[guest]

What does this ini file do and where should I put it?

Hi tormento, you're fairly new here....

OK, the .ini file stores all the start up & running settings for RipBot, you don't generally edit it directly (but you can), as the majority of the settings are in the GUI, and saved to the .ini.

I'm pretty sure it has to be in the main Ripbot folder !!!

The file & folder structure as extracted from the downloaded .7z file.

[SKPN]

I'm having an issue on one of my two PCs. I had everything working perfectly, but recently reformatted both PCs. I've got Ripbot working on one (PC1), but I cannot get it to work on the other (PC2). When launching a job from PC1, it is not able to connect to PC2 for distributed encoding. When launching from PC2, it connects to PC1 for distributed encoding, but PC2 never does any work. I can't figure out what the issue is, as all the settings appear to be correct.

Not sure if it makes a difference, but when I launch Ripbot on PC1, the encoding server also launches automatically and appears in my taskbar. When I launch on PC2, the encoding server does not appear in the taskbar, but it does appear in Task Manager.

Any help on this would be greatly appreciated. PC2 is my more powerful PC, so I really want to get this resolved quickly.

[guest]

I'm having an issue on one of my two PCs. I had everything working perfectly, but recently reformatted both PCs. I've got Ripbot working on one (PC1), but I cannot get it to work on the other (PC2). When launching a job from PC1, it is not able to connect to PC2 for distributed encoding. When launching from PC2, it connects to PC1 for distributed encoding, but PC2 never does any work. I can't figure out what the issue is, as all the settings appear to be correct.

Not sure if it makes a difference, but when I launch Ripbot on PC1, the encoding server also launches automatically and appears in my taskbar. When I launch on PC2, the encoding server does not appear in the taskbar, but it does appear in Task Manager.

Any help on this would be greatly appreciated. PC2 is my more powerful PC, so I really want to get this resolved quickly.

I recently had a similar problem, and what I did was a fresh setup on ALL the offending PC's, clean copy of RipBot, updated all it could find using Auto update, checked that the IP settings were correct, etc, etc, and it's all "happy" again :)

Network settings are the most important for DE, so just go thru and double check EVERYTHING !!!!

Also, I do have a similar problem with the server icon not showing in the taskbar...you might need to manually open it, then add more as needed...

[tormento]

Hi tormento, you're fairly new here....
Well, my first post in this thread is 12th June 2009, 17:51 :D
OK, the .ini file stores all the start up & running settings for RipBot
I asked as in the release there is a "updater.ini" while the extracted file is "update.ini", therefore my question.

[guest]

Well, my first post in this thread is 12th June 2009, 17:51 :D

I asked as in the release there is a "updater.ini" while the extracted file is "update.ini", therefore my question.

OK, fair enough :)

Yep, EVERYTHING needs to be kept / left in the main Ripbot folder.

[slalom]

Not sure if it makes a difference, but when I launch Ripbot on PC1, the encoding server also launches automatically and appears in my taskbar. When I launch on PC2, the encoding server does not appear in the taskbar, but it does appear in Task Manager.

Any help on this would be greatly appreciated. PC2 is my more powerful PC, so I really want to get this resolved quickly.
Go to Settings, DE Tab, DE mode should be ON

[guest]

Go to Settings, DE Tab, DE mode should be ON

Hey...:)

Yep, I thought of that too, but he mentions that Encoding Server is running, just no taskbar icon, and I guess no connection.....

And I get that on one PC quite regularly....just need to start it manually.

Probably something simple :)

[Atak_Snajpera]

I'm having an issue on one of my two PCs. I had everything working perfectly, but recently reformatted both PCs. I've got Ripbot working on one (PC1), but I cannot get it to work on the other (PC2). When launching a job from PC1, it is not able to connect to PC2 for distributed encoding. When launching from PC2, it connects to PC1 for distributed encoding, but PC2 never does any work. I can't figure out what the issue is, as all the settings appear to be correct.

Not sure if it makes a difference, but when I launch Ripbot on PC1, the encoding server also launches automatically and appears in my taskbar. When I launch on PC2, the encoding server does not appear in the taskbar, but it does appear in Task Manager.

Any help on this would be greatly appreciated. PC2 is my more powerful PC, so I really want to get this resolved quickly.

Disable GeForce Experience spying service or any software which works in background (MSI, Logitech and so on). Safe mode should also fix this issue. Basically other application on your system blocks encodingserver.exe.

[ReinerSchweinlin]

Hi,

maybe my question got lost:
Would it be possible to enable GPU Decoding for AMD GPUs? At the moment, its "CPU or GPU" and if seems only nvidia or intel decoding is possible. Would be cool to have AMD Decoders available, too and make it selectable (like the OPENCL Options).
Thanx!

[Atak_Snajpera]

Hi,

maybe my question got lost:
Would it be possible to enable GPU Decoding for AMD GPUs? At the moment, its "CPU or GPU" and if seems only nvidia or intel decoding is possible. Would be cool to have AMD Decoders available, too and make it selectable (like the OPENCL Options).
Thanx!

No because open source community is not very well encouraged by AMD to do anything in that regard. Blame AMD.
By the way. You are not missing a lot in terms of encoding time. Maybe up to 3%-5% if you do not do any filtering in avisynth.

[gonca]

Rigaya keeps this up to date
https://github.com/rigaya/VCEEnc/releases

[Atak_Snajpera]

Rigaya keeps this up to date
https://github.com/rigaya/VCEEnc/releases

Encoder != Decoder

[gonca]

Aware of that but it can also decode to feed the encoder
If the OP wants to encode with AMD it would work

[SKPN]

Disable GeForce Experience spying service or any software which works in background (MSI, Logitech and so on). Safe mode should also fix this issue. Basically other application on your system blocks encodingserver.exe.

Thank you! I don't know why it wasn't working though; I had GeForce Experience running prior to reformatting and everything worked fine. Strange.

Thanks for your help!

[ReinerSchweinlin]

No because open source community is not very well encouraged by AMD to do anything in that regard. Blame AMD.
By the way. You are not missing a lot in terms of encoding time. Maybe up to 3%-5% if you do not do any filtering in avisynth.
Thanx for getting back!
I am aware that the speed difference isn´t that huge :) I was under the impression, that since ffmpeg seems to incorporate some means of using the AMD decoders, that it would be as simple as "switching it on and make a selector for AMD/NVIDIA/Intel decoders". I stumbled across this in the ffmpeg wiki:

"AMD UVD/VCE

AMD UVD is usable for decode via VDPAU and VAAPI in Mesa on Linux. VCE also has some initial support for encode via VAAPI, but should be considered experimental.

On Windows, UVD is accessible via standard DXVA2/D3D11VA APIs, while VCE is supported via AMF. "

So my amater brain thought: Use DXVA..... But I now learned that this is not good and found this post:

http://forum.doom9.org/showthread.php?p=1921757&highlight=amd#post1921757

Learned something new today. Thanx.

[ReinerSchweinlin]

Rigaya keeps this up to date
https://github.com/rigaya/VCEEnc/releases
Yes, I know. I also stumbled acros this:
https://bluesky-soft.com/en/AsVideoConv.html
(in regard of AMD De/encoding), but haven´t gotten it to run on my vega 64 so far... (Yes, I heard that AMD Encoders are shitty, I am used to RTX Encoders, but since this VEGA happens to be here, I thought I`ll play around a little..) But thats OT for Ripbot :)

[guest]

Based on what I've been reading, FFMPEG should be able to encode 5.1 E-AC3. Can this be add as an option to RB? Based on what I've been reading compression is similar to AAC and E-AC3 can be decoded by modern AVRs which makes it a good replacement for me instead of using for AC3 and AAC.

Originally Posted by tormento
Yup, I jumped from THD/DTSHD -> AC3 to EAC3 format but I kept the 640kbps that I used in AC3.
That sounds like a good idea. Though I want to keep 3D audio, so I have to keep the full THD+Atmos and DTS:X tracks. But for those shows that have DTS-HD in 5.1, it would be better to use E-AC3 at 640K, and for the streaming versions I create I'll use E-AC3 at 320K instead of AAC.

I looked and I could find no free tools that could do 7.1 channel E-AC3.

I have been "playing" around with E-AC3 for that last couple of days, and have stumbled across several app's that can convert to this format.

Of course they're all based on FFMPEG (which RB uses), so it should be pretty straight forward to have this as part of the audio options.

Like converting TrueHD, and FLAC to E-AC3.

Even tho FFMPEG can't yet utilize 7.1, most TV's only run up to 5.1, so that's 2 channels not required.

I did a test with Handbrake to convert THD 7.1 to E-AC3 5.1 at the same bitrate of 1536K, and it worked just fine, and Handbrake is FFMPEG based !!!

Also, there is a reasonably simple way of converting with eac3to, as well, and RipBot uses that.

So if this was added to RipBot, it would be nice to be able to choose up to 1536K, or 1509K, and not be limited to the 640K of AC3.