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

[MCFish]

ill donate again ...;)

[byteshare]

Ok then BRACE YOURSELF! AUTO-UPDATE IS COMING!
Holding on to my butt ;)
Atak_Snajpera : thank you agin for this great job.

Could you be pleased to add these feature :

able to decode mxf files
adding custom timecode on mp4 or the timecode of the source

??

... to encode files from DSLR / Camera to lower resolution / proxy file but with the same timecode of the sources

0gg / augur.
I've been using a batch export time code (source) and import time code (encoded file); for when I need time codes. I usually don't need them if I'm not doing anything with QTGMC (de-interlace tool)
My camera uses MP4 and .ts files so I haven't used mxf files before, but I haven't needed to use time codes for those files (yet).

[howzz]

good job. see. put everyone's heads together and we can solve anything.

i'll donate some money to the cause come this fri pay day.

[Ronski]

Thanks Atak, working for me again as well - I had a zero in my IP address. I also sent a donation yesterday, thanks once again for all the hard work.

[guest]

Ok then BRACE YOURSELF! AUTO-UPDATE IS COMING!

Let's give it up for Atak....he's a Bloody Legend !!!

Well done, as we knew it would be, when you say "I give up" we don't really believe it. :)

It was a community effort of some of the RB users out there.

I'd just like to say that some things were said, that should have been a lot more tactful, but some of us express themselves differently to others.

I'll take note of the critisicm against me, and the comments I made, however I was also surprised with the support of some, for some suggestions I made, so it's not all bad.

We're all here to help with the ongoing improvement of this awesome free app, and I know that I won't stop using it, I have spent a lot of time & money setting up a range of systems so as to get the best benefit & performance out of RB, that I can, so I guess I was frustrated by the sudden unexpected DE problems, as DE, IS the awesome function of RB.

So hopefully we can move forward.....

So again Atak, thank you very much..........

PS:- I just wanted to add, that I just tested RB, (pre this latest fix), by changing my LAN's IP address from 192.168.0.5, to 192.168.1.5, and it worked, but now it's been fixed, that isn't an issue anymore. :)

[Dhry]

Outstanding! Thank you for resolving this issue Atak. Looking forward to the autoupdate.

Dhry

[t3nzin]

Thanks for the update Atak! Also, not sure if anyone else has reported it yet but RipBot is still prompting for the pinterf branch rather than the official Avisynth+ repo that merged his changes and is now on 3.4.0. Not a big thing just a small quality of life change for a future update :)

[Atak_Snajpera]

Auto-update core 2019.11.19

Added: support for mxf files (Material Exchange Format)

[mcjordan]

What about AviSynth v3.4?
https://github.com/AviSynth/AviSynthPlus/

When I starting RipBot I've a message like this:
AviSynth+ MT x64 not installed!

[Ryushin]

I'm not sure if it's just me or not. I've tried to trouble shoot this and I have not found anything that changes it's behavior.

I had to move back to spinning platters (six SAS 10K 2.5" drives, in a ZFS raidz2 with a 10GB SSD SLOG Write Cache) as the SSDs I had would not trim running behind LSI HBA. I'm waiting for Western Digital's new SA500 NAS SSDs to become available to purchase and I'll try that again.

Essentially it's taking 20-30 minutes of Starting.... before a chunk begins to encode, for each chunk. So after it finishes a chunk, another 20-30 minutes has to go by for it to do the next one. I have three encoding servers running.

There seems to be a lot of disk access on the drive containing the ripbot264temp folder.
https://i.postimg.cc/DJGCGtpX/Rip-Bot264-Disk-Access.png (https://postimg.cc/DJGCGtpX)

I'm encoding 4K rips from discs.

I've tried installing a fresh version of RipBot264 and let it perform all it's updates and there does not seem to be any difference. I've tried pulling in fresh jobs and there is no difference.

I've run disk benchmarks of the VM running RipBot264 and for spinning platters, it's not too bad and this is while the system was a little busy:
https://i.postimg.cc/LYr8CZVW/Rip-Bot264-Disk-MBs.png (https://postimg.cc/LYr8CZVW)
https://i.postimg.cc/hzJG10Vx/Rip-Bot264-Disk-IOPS.png (https://postimg.cc/hzJG10Vx)

I've added a 8 core 16 thread E5-2650 V2 chip, so I shoudn't be CPU bound anymore.

Is there anything else I can provide? I'm at a loss right now.

[Atak_Snajpera]

1) Abort your encoding
2) Double click on IndexStreams_RunAll.cmd for each job causing this problem
3) Restart encoding

It is a side effect of (good) changes in lsmash index structure. (2x size reduction). What you see is a reindexing process caused by incorrect (old) index file version (15 vs 16) stored in job folder.

[guest]

Updated Core (20-11-19), & ES (v1.16.1), Avisynth 3.4 & ffmpeg.

:thanks:

[Ryushin]

Couple of things.

Just had a machine update and when an encoding server starts it complains about "AviSynth+ MT x64 not installed!". Running as administrator, I ran Tools\Avisynth\install.cmd and it does not seem to make a difference. I tried Tools\Avisynth\Avisynth+\uninstall.cmd and installed again and that did not make a difference, it still complains. I'll dig into this a bit later.


I tried the IndexStreams_RunAll.cmd and it did not make any difference. Though, I did discover something interesting. When the very long slow "Starting...." of chunks, or the 10-20 minutes of "Gathering Information" to pick a second audio stream or leaving the Avisynth Menu. It only occurs if RipBot264 demuxes from a ripped 4K disc. If I use MakeMKV to make a mkv of the 4K source, and then pull that into RipBot264, everything behaves normally and takes seconds to complete. Only extra bit is for the EncodingClient to copy the large mkv before starting. So at least that is a workaround for now.

[Atak_Snajpera]

Couple of things.

Just had a machine update and when an encoding server starts it complains about "AviSynth+ MT x64 not installed!". Running as administrator, I ran Tools\Avisynth\install.cmd and it does not seem to make a difference. I tried Tools\Avisynth\Avisynth+\uninstall.cmd and installed again and that did not make a difference, it still complains. I'll dig into this a bit later.


I tried the IndexStreams_RunAll.cmd and it did not make any difference. Though, I did discover something interesting. When the very long slow "Starting...." of chunks, or the 10-20 minutes of "Gathering Information" to pick a second audio stream or leaving the Avisynth Menu. It only occurs if RipBot264 demuxes from a ripped 4K disc. If I use MakeMKV to make a mkv of the 4K source, and then pull that into RipBot264, everything behaves normally and takes seconds to complete. Only extra bit is for the EncodingClient to copy the large mkv before starting. So at least that is a workaround for now.
Latest version of EncodingServer.exe is v1.16.1

[Ryushin]

Just had a machine update and when an encoding server starts it complains about "AviSynth+ MT x64 not installed!". Running as administrator, I ran Tools\Avisynth\install.cmd and it does not seem to make a difference. I tried Tools\Avisynth\Avisynth+\uninstall.cmd and installed again and that did not make a difference, it still complains. I'll dig into this a bit later.


Uninstalled Avisynth software package that I had installed. Copied the RipBot264 from the working machine over to the problem one and everything came up fine.

[userx]

Hello
I've a mkv-file which has 1 video, 2 audio and 37 subtitle tracks. After demuxing i get an Error:
FFVideoSource: No video track found
(D:\Temp\RipBot264temp\job2\getinfo.avs, line 2)

I don't want to keep all the subtitles. Is there a workaround or a fix for this issue?

[guest]

Hello
I've a mkv-file which has 1 video, 2 audio and 37 subtitle tracks. After demuxing i get an Error:
FFVideoSource: No video track found
(D:\Temp\RipBot264temp\job2\getinfo.avs, line 2)

I don't want to keep all the subtitles. Is there a workaround or a fix for this issue?

You could give MKVToolNix a try....

[userx]

You could give MKVToolNix a try....

Thanks for the hint but maybe to prevent future requests the track limit could be raised.

[Atak_Snajpera]

Forget about buggy ffvideosource. Use lsmash.

[userx]

Use lsmash.
I'm using FFMS2 due to i run into issues if use LSMASH.
Encoding client runs into error:
....video.mkv.ffindex_track00.kf.txt does not exist. Autoclosing

[stax76]

Forget about buggy ffvideosource. Use lsmash.

What's the biggest issue right now? FFVideoSource is still the default in staxrip.

[Atak_Snajpera]

What's the biggest issue right now? FFVideoSource is still the default in staxrip.

Ffvideosource is not frame accurate for example

https://i.imgsafe.org/a3/a32816de27.png

[stax76]

What's the most common scenario where frame accuracy is needed?

[slalom]

Hello
I've a mkv-file which has 1 video, 2 audio and 37 subtitle tracks. After demuxing i get an Error:
FFVideoSource: No video track found
(D:\Temp\RipBot264temp\job2\getinfo.avs, line 2)

I don't want to keep all the subtitles. Is there a workaround or a fix for this issue?
I get that message all the time
Use MKV Merge and reduce subtitles <30

[Atak_Snajpera]

What's the most common scenario where frame accuracy is needed?

When you use a lot of Trim function. for example Trim(100,200)+Trim(300,400)+Trim(600,700)

[Ryushin]

I tried the IndexStreams_RunAll.cmd and it did not make any difference. Though, I did discover something interesting. When the very long slow "Starting...." of chunks, or the 10-20 minutes of "Gathering Information" to pick a second audio stream or leaving the Avisynth Menu. It only occurs if RipBot264 demuxes from a ripped 4K disc. If I use MakeMKV to make a mkv of the 4K source, and then pull that into RipBot264, everything behaves normally and takes seconds to complete. Only extra bit is for the EncodingClient to copy the large mkv before starting. So at least that is a workaround for now.

Atak, have you had time to look at this and see if it is a bug or something unique to me? If it is a bug and you're working on it, I'll leave my 15 or so 4K jobs there to hopefully have a fix soon. If your cannot confirm it or don't have time to look at it, let me know and I'll start converting those disc rips to mkv files, delete and re-add them to RB. Thanks much.

[Atak_Snajpera]

I do not have access to 4k BD at all...
However I would like to compare lsmash indexes (.lwi files) for mkv created by makemkv and ripbot.

[Ryushin]

I do not have access to 4k BD at all...
However I would like to compare lsmash indexes (.lwi files) for mkv created by makemkv and ripbot.

Ask and ye shall receive:
https://cloud.chrisdos.com/index.php/s/2BykG9ER9RrxM2E

BTW, detecting boarders took seconds from the MakeMKV 4K compared to 10-20 minutes from the demuxed version.

[Atak_Snajpera]

What happens if you take that video.mkv from job folder and mux with mkvtoolnix to new mkv? Does it also cause the same problem?

[BLKMGK]

Curious about SeekTester, is this why you index the files and pull them apart prior to compression and then remux them?

I have an alternate cluster encoding program I've been working on for Linux with a friend and we don't pull files apart or reindex them as you do but it passes your test program so I'm curious. This program is a ways from being mature enough to release and cannot presently use filters the way RipBot does but it does build pieces of files across many computers and then combine them so it's not completely different. The added steps have always been confusing to me for this reason:confused:

[Ryushin]

What happens if you take that video.mkv from job folder and mux with mkvtoolnix to new mkv? Does it also cause the same problem?

I muxed the RB extracted video.mkv along with all the contents except the video from the Casino Royal MakeMKV mkv and made a new mkv which I imported into RipBot. Everything was still speedy with the new mkv.

Did the index files look the same?

[byteshare]

Ffvideosource is not frame accurate...
Something just clicked when you said this and showed the image with errors. When you say frame accurate you don't mean timing, but rather frames completely just get skipped when they are not "accurate"?
I haven't played with GPU decoding much but if that is more accurate than LSmash I'd even use that on the machines I can use it on.

[userx]

I get that message all the time
Use MKV Merge and reduce subtitles <30

I solved it by this way.
But if the recomendation is to use lsmash instead of FFMS2 there is still an issue corresponding with ...video.mkv.ffindex_track00.kf.txt which seems not to get created.

[Atak_Snajpera]

Are you sure you have latest version? Other people do not report this issue.
Btw. I'm using lsmash all the time. Ffms2 is dead for me.

[Atak_Snajpera]

Curious about SeekTester, is this why you index the files and pull them apart prior to compression and then remux them?

I have an alternate cluster encoding program I've been working on for Linux with a friend and we don't pull files apart or reindex them as you do but it passes your test program so I'm curious. This program is a ways from being mature enough to release and cannot presently use filters the way RipBot does but it does build pieces of files across many computers and then combine them so it's not completely different. The added steps have always been confusing to me for this reason:confused:

Seektester Has nothing to do with de mode. Frame accurate seeking is crucial in De mode so i wrote that tool to establish which source filter is the most reliable. Lsmash is super stable while ffms2 is not.

[Atak_Snajpera]

I muxed the RB extracted video.mkv along with all the contents except the video from the Casino Royal MakeMKV mkv and made a new mkv which I imported into RipBot. Everything was still speedy with the new mkv.

Did the index files look the same?

No they are different because video.mkv is just a raw .265. eac3to can only demux hevc streams. For some unknown reason lsmash has problem with raw hevc. Could you upload first 5GB of video.mkv. Use dgsplit. Do not use mkvtoolnix. I would like to see If i also get that huge delay.

[Ryushin]

No they are different because video.mkv is just a raw .265. eac3to can only demux hevc streams. For some unknown reason lsmash has problem with raw hevc. Could you upload first 5GB of video.mkv. Use dgsplit. Do not use mkvtoolnix. I would like to see If i also get that huge delay.

Link to file: https://cloud.chrisdos.com/index.php/s/fG7fHFoGPt5YTQN

Though, there might be at least one other thing going on. When I have a 4K source, I select two audio tracks. Most of the time the first track is a AC3 core from a TrueHD track, and the second track is a demux of the same TrueHD track. After the job has been created and I click to add the second track, the Gathering Information takes about 10-20 minutes. The MakeMKV job takes about 30-60 seconds.

[Atak_Snajpera]

Ok. So the problem may not be related with HEVC stream but with TRUE-HD. Interesting...
BTW. can you check if .lwi file for true-hd is already created in job folder before you select second audio (True-hd)

[Ryushin]

Ok. So the problem may not be related with HEVC stream but with TRUE-HD. Interesting...
BTW. can you check if .lwi file for true-hd is already created in job folder before you select second audio (True-hd)

I made a new job and it did make a .lwi file for the TrueHD stream. Is it normal that the .lwi for TrueHD will be 400MB in size? The TrueHD stream itself is 2100MB. The video .lwi file is only 14MB in size.

While pulling in the job, and it is saying "Gathering Information..." for 10-20 minutes, ffprobe is running during this time. Then "Extracting Frame..." takes another 5-10 minutes.

[Atak_Snajpera]

I made a new job and it did make a .lwi file for the TrueHD stream. Is it normal that the .lwi for TrueHD will be 400MB in size? The TrueHD stream itself is 2100MB. The video .lwi file is only 14MB in size.

While pulling in the job, and it is saying "Gathering Information..." for 10-20 minutes, ffprobe is running during this time. Then "Extracting Frame..." takes another 5-10 minutes.

Yes it is "normal". It was even worse in previous version of lsmash
https://forum.doom9.org/showthread.php?p=1889725#post1889725

Can you send me whole True-hd stream? The longest sample I currently have is only 10min long?

[Ryushin]

Yes it is "normal". It was even worse in previous version of lsmash
https://forum.doom9.org/showthread.php?p=1889725#post1889725

Can you send me whole True-hd stream? The longest sample I currently have is only 10min long?

Here is a full stream (from a different movie though as it was smaller):
https://cloud.chrisdos.com/index.php/s/YPB3HpNitCoxL3r

[guest]

Link to file: https://cloud.chrisdos.com/index.php/s/fG7fHFoGPt5YTQN

Though, there might be at least one other thing going on. When I have a 4K source, I select two audio tracks. Most of the time the first track is a AC3 core from a TrueHD track, and the second track is a demux of the same TrueHD track. After the job has been created and I click to add the second track, the Gathering Information takes about 10-20 minutes. The MakeMKV job takes about 30-60 seconds.

I'd just like to chime in here, and add my 2 cents worth..

I have a LOT of 4K mkv's with TrueHD audio, and I run them thru MkvToolNix (sometimes tsmuxer) to rip out everything except the video, and then if need be, I will run that thru RB.

I then extract & convert the THD, and process any subtitles.

Once that's done, it all goes back together with MkvToolNix.

[Atak_Snajpera]

Are you looking for ultimate encoding machine? ;)
https://i.postimg.cc/N0bzsVWr/Untitled-1.png

[Ronski]

Are you looking for ultimate encoding machine? ;)

Impressive results, but wouldn't that be the 3990X with 64 cores 128 threads, although not yet available.

PS. Mine was 21.2 i7-5820K @4.5Ghz, although your benchmark reports the stock speed.

[BLKMGK]

Missed out on a 3950 to add to my 3900 today :( That clustered with my couple of other machines would be sick - I'll find one eventually! :) I cannot imagine a Threadripper but the price is just a hair too much methinks!

Edit: My 3900X@4.1GHz, optimizing not really complete as I'm still figuring out AMD, came in at 56.7FPS FWIW

[LigH]

@Ronski: Then better run several jobs in parallel, instead of wasting so many threads on only one; e.g. 8 jobs each 8 cores, that would be impressive. And possibly hard to keep cool...

[guest]

@Ronski: Then better run several jobs in parallel, instead of wasting so many threads on only one; e.g. 8 jobs each 8 cores, that would be impressive. And possibly hard to keep cool...

I've been waiting to see if someone else comments on this...

You can't be talking about RB running parallel jobs, as you can't have more that once instance of RB going at any one time, on the same PC.

Also, RB only does 1 job at a time.

Am I missing some well hidden secret setting !!! (or is it something you can do this with VM's)

[tkwou]

Hi I just updated Ripbot264. I haven't used it for a couple weeks. The Distributed Encoding wasn't working, only on the Host computer. I then updated all the other computers but I still couldn't get the Distributed Encoding to work. It just kept connecting and disconnecting with all the other computers. Finally I checked each computer and realized that Encoding Server never updated on any of the other computers. They all remained on 1.14.0.0. I finally manually updated each one to 1.16.0.0 from the Host computer and everything is up and running again. Not sure what went wrong on all the other computers.

[guest]

Hi I just updated Ripbot264. I haven't used it for a couple weeks. The Distributed Encoding wasn't working, only on the Host computer. I then updated all the other computers but I still couldn't get the Distributed Encoding to work. It just kept connecting and disconnecting with all the other computers. Finally I checked each computer and realized that Encoding Server never updated on any of the other computers. They all remained on 1.14.0.0. I finally manually updated each one to 1.16.0.0 from the Host computer and everything is up and running again. Not sure what went wrong on all the other computers.

Yes, DE went thru a bit of a bad patch a week or so ago...

But you still don't seem to be completely up to date.., Server is 1.16.1.0

[tkwou]

Thanks, something is also broken in 2-pass in v1.25.0. The "job1_EncodeVideoPass2.cmd" is blank. The process stops after the first pass.