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

[lemaireus]

@ Slalom: "YOU can do that manually
Run CombineAllChunks.cmd in Chunks folder to get your video"

I wouldn't know where to find the 'chunks' folder. The RibBot264 temp folder is where I get the video.265 file, and that gets deleted as soon as the job ends with an error and the next job in the queue begins.

@ Atak: "@lemaireus
Can you show me how corrupted chapter file looks like?"

I had to delete the corrupt chapter files to process the video for the file I was encoding. Will post that file the next time I run into this error.

[slalom]

@ Slalom: "YOU can do that manually
Run CombineAllChunks.cmd in Chunks folder to get your video"

I wouldn't know where to find the 'chunks' folder. The RibBot264 temp folder is where I get the video.265 file, and that gets deleted as soon as the job ends with an error and the next job in the queue begins.
Chunks folder is under jobxxx folder where xxx is the number of the job

So stop Ripbot and check that path jobxxx/Chunks

see my path "E:\Temp\RipBot264temp\job562\Chunks"

Run CombineAllChunks.cmd in Chunks folder to get your video

Then run mkvmerge with that one and the original video to get your result

[Atak_Snajpera]

slalom not everybody is using de mode.

[lemaireus]

@ slalom: "Run CombineAllChunks.cmd in Chunks folder to get your video"

Atak's right: I'm not using distributed encoding.

[slalom]

ok guys!

[lemaireus]

I got lucky in the second encoding attempt: got hold of the video.265 file from the RipBot264temp folder before the next job in the queue could start. Muxed that with the audio and was thus able to save 12 hours of work.

The 'chapters-original' file has this message: "Error: (mkvextract) This file could not be opened or parsed." The 'chapters' file shows the same message. The second encoding attempt, in which I manually deleted the 'chapters-original' file and kept a blank 'chapters' file in an attempt to avoid getting an error, also resulted in an 'ERROR' but, as I said, fortunately the video.265 file hadn't yet been deleted or overwritten. I took that video.265 and muxed it with the audio and chapters from the source file and was thus able to get the desired output.

In two previous instances I have run into chapter errors of a different kind. In those cases the 'chapters-original' file had the chapters perfectly fine, but the 'chapters' file copied that information in a format that was different from the 'chapters-original' file. I do not have the videos for those files anymore so I cannot recreate the error. In both of those cases I got the encode done by manually copying information from 'chapters-original' to 'chapters'.

It would be good to have a workaround for this kind of an issue in the next version of RipBot. A minor chapter error really shouldn't end in destroying 12 hours of otherwise perfectly fine encoding work.

[Atak_Snajpera]

Like I said before I need those files from second case (original and modified) I won't do anything if you do not upload both files.

[lemaireus]

@ Atak: "Like I said before I need those files from second case (original and modified) I won't do anything if you do not upload both files."

That is perfectly sensible. I don't have the files for the 'second case' scenario, but when--and if--I run into the same problem again, I'll get back to you with the pertinent files. Until then let's hope that these may have been mkvtoolnix bugs which Mosu might have taken care of at some stage.

[slalom]

Try to extract and post chapters.txt
like this

CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 01
CHAPTER02=00:12:26.912
CHAPTER02NAME=Chapter 02
CHAPTER03=00:23:13.100
CHAPTER03NAME=Chapter 03
CHAPTER04=00:30:15.522
CHAPTER04NAME=Chapter 04
CHAPTER05=00:39:09.972
CHAPTER05NAME=Chapter 05
CHAPTER06=00:50:01.164
CHAPTER06NAME=Chapter 06
CHAPTER07=01:03:05.615
CHAPTER07NAME=Chapter 07
CHAPTER08=01:10:40.110
CHAPTER08NAME=Chapter 08
CHAPTER09=01:20:56.101
CHAPTER09NAME=Chapter 09
CHAPTER10=01:30:15.660
CHAPTER10NAME=Chapter 10
CHAPTER11=01:38:19.268
CHAPTER11NAME=Chapter 11
CHAPTER12=01:46:47.150
CHAPTER12NAME=Chapter 12

there must be a syntax error

[lemaireus]

@ slalom: you are right, it must be a syntax error. But I do not have that video anymore which gave me that error.

The error regarding which I posted a message yesterday was an mkvtoolnix error, which wasn't able to read the 'chapters' in the source video. That is a random error generated most likely by a corrupt chapters file in the source video. This was the first error of its kind with me.

The problem that has recurred with me about four times is of a kind where the original chapters file does not get copied exactly as it is, but with some differences. In order to produce that error I need a video file which gives me that error in the first place. It must have been more than a month when I got that error the last time, so that video is gone. I'll post the relevant chapters files only when I run into the same issue again with another file.

[AMiR9!WV]

@Amir
What happens if you run ENCODE_AUDIO_1.cmd in console?

can't find it in windows

[Viper714]

I have, hopefully, a quick questions.

Why is it that some movies of the same duration have a larger file size than others?

I am not talking about small size difference, but large difference. Sometimes over a 50% size difference using the exact same settings for encoding (CQ 20, 1080p, and audio set at core ripping). Here is an example:


Bridge of Spies.mkv 02:21:19 8,032,010 KB
Mocking Jay P2.mkv 02:16:57 3,340,076 KB


Very strange, for me at least...
:thanks:

[Atak_Snajpera]

Constant Quality mode adjusts bitrate on fly according to selected CRF value and complexity of video. Basically some movies are easier to compress than others.

For example
Clean Anime will have much lower file size than very noisy movie (300).

You can notice similar behaviour when you compress files with ZIP/RAR/... Some files will compress well (.txt) and some may not compress at all (.jpg).

[LeetDonkey]

Hello

I've run into an odd thing on two different PCs running windows 10

- Setup a job
- Enable distributed encoding
- Check that ripbot264temp is properly shared
- Start job

When I click start job the network share of ripbot264temp is removed and ripbot264 fails at indexing the file.

Now If I'm quick and manage to reshare the ripbot264temp directory while ripbot is copying tools, it will proceed to encode in a normal way right until the next item in the queue and the share will be removed again automatically.

I've tried searching the thread but I haven't found anything that could help me.

Does anyone have any idea what's going on?

[lemaireus]

Ripbot was probably updating or checking for updates today when my computer crashed due to a power failure. Since then I have been getting the following error each time I start Ripbot:

http://s32.postimg.org/vfma4okd1/Integer_Value_Error.jpg (http://postimage.org/)

Any ideas on how to get rid of this red flag? I have restarted and rebooted several times but the message refuses to go away.

[slalom]

Yes, delete old files, re-download the app

Connect a UPS if you can

[lemaireus]

Thanks, Slalom, I was look for a less radical solution, but looks like nothing else will work. Copied the entire folder afresh and things are fine once again.

[slalom]

What was so radical??

[lemaireus]

In referring to a less 'radical' solution, I was thinking along the lines of editing the 'update_log' or 'updater.ini' to remove the red flag. Copying the entire folder afresh is practically a fresh install. Howsoever that be, the problem is solved, so thank you for the suggestion.

[Pulp Catalyst]

Is there any chance of getting a better deinterlacer, Yadif is ok, but in fairness with so much hardware potential today, it's very old.

a good combination that i like (without getting into complex things like QTGMC)

would be Yadifmod & NNEDI3.

i still want to 25 > 50fps option, but with a much better deinterlacer, Yadif might be FAST, but the quality that NNEDI3 gives is to good to miss.

Thanks,

[jthekk2]

Atak, is there any way to include a setting to have the first pass handled by one machine for the entire file and then split the file (and stats file) into chunks for distributed encoding? I've been testing with the current distributed encoding but am seeing massive bitrate drops in high action scenes where the scene fell into different chunks. I'm hoping that a first pass pre-chunking would allow for proper bitrate determination relative to the file as a whole before encoding. This will obviously bottleneck the process to the speed of the server doing the first pass, but is more ideal since it yields a better encode in the end.

I think It would be better if you increased chunk size from 1 min to old 10 min value. This method would be much faster than first pass on single machine.

I'll give it a try but the problem would still remain if the action scene falls at the 10 minute mark and is split and the second chunk has an otherwise low level of action (so lower average bitrate). Also, since most shows aren't exactly a multiple of 10, the last chunk will always be smaller and might present the same issue. Unless I'm missing something and there is some error handling for that.

Last chunk is always the biggest. Otherwise We could end up with 1 frame chunk ;).
Longer chunk sizes should help in better bitrate distribution (less aggressive)Finally got a chance to test this out, and increasing to 600 second chunks seem to have definitely done the trick with regard to the bitrate distribution issue I was having (seeing the bitrate fall dramatically during a fight scene was very distracting!). I'll likely test further to find some middle ground between 60 and 600 so distributed encoding would yield greater benefits.

The only issue I have now is that RipBot forces a copy of the original file to the shared folder which is actually on the same drive as the original file (e.g. a copy from D:\Videos\TEMP to D:\Temp\RipBot264temp\job1). I already have the relevant streams demuxed onto my harddrive through a batchfile/eac3to with the video being dumped into an mkv (whether h264 or vc1) to be encoded through RipBot. RipBot proceeds to copy the file to the shared folder (D:\Temp\Ripbot264temp\job1). The copy takes a while depending on the filesize of the mkv; a move would be almost instantaneous. I understand that this protects against file loss, but is there any way to set things so that it just moves the original file instead of a copy? I realize this only saves a few minutes time-wise in the grand-scheme of things, but those few minutes add up when it's 2-3 minutes to copy each file and the program is encoding 22-24 files in the job queue. Maybe an option could be added to switch the copy to a move with a pop-up warning that doing so could result in loss of the original file?

[slalom]

Some people don't have the file demuxed, or in the same drive as the temp folder, so, generally your suggestion does not apply for everyone

My point of view

[jthekk2]

Some people don't have the file demuxed, or in the same drive as the temp folder, so, generally your suggestion does not apply for everyone

My point of viewA few things on this, mostly because I might not have been clear on circumstances where this would be used.

1) From my testing, a file is demuxed when added to the RipBot queue, not after the queue has been started. It is also only demuxed if it is in a format that cannot be indexed (e.g. a .ts) or if audio is being processed and muxed. A raw video stream in an mkv container holding only a raw avc video and no audio is not demuxed but is copied once the encode is started. The copy I am concerned with is the copy that occurs if the file needs to be copied only so it can be indexed and then be seen by multiple computers for distributed encoding. If the above mentioned raw avc in mkv is encoded without distributed encoding, there is no copy file step to the RipBot temp folder but if anything needed to be demuxed it would have already been demuxed when added.
2) This was asking for an option to be enabled to allow for disabling the copy that specifically occurs before Distrusted Encoding which occurs only if the file does not need to be demuxed but needs to be indexed (e.g. the copy after the start button is hit and tools are copied to the share folder but before the file is indexed---a copy that occurs only so the file sits in the share folder so that it is viewable by other systems). You are right that in most cases a user might not use this, but it would only be available in the rare case where the original file needs to be copied to the shared folder for DE. If it needs to be demuxed, the option should be unavailable and grayed out or invisible
3) The option could have a self check that sees if the file is on the same drive as the temp folder. If it is and the option is enabled, then a move is done instead of the copy. Since the temp folder is specified by drive and the input folder path will have a drive letter, this is a simple check to see if the drive letters match. If they don’t, the option is unavailable and would be grayed out or something.
4) The option would have a warning that enabling it could cause the demux and/or encode to not work properly. E.g. Use only if you know what you’re doing. This wouldn’t be a global option but a per file option selectable when adding a file to the job queue. Again, if it is only used in the instance where the file needs to be copied before an index only it shouldn’t even break anything for local encoding and would only speed up distributed encoding by moving a potentially needless copy. The ONLY risk is that the original file may be lost. Other “all-in-one” encoding solutions for other uses (e.g. MCEBuddy for Windows Media Center recordings) have an option to skip copying the files to the temp “working folder” that have a warning - demuxes and remuxes still occur though.

[slalom]

3) Better to suggest the source file not be moved. It should be used in it's current location, so the "check to see if the drive letters match" is not needed nor mandatory

[jthekk2]

3) Better to suggest the source file not be moved. It should be used in it's current location, so the "check to see if the drive letters match" is not needed nor mandatoryIf the source file isn't moved then distributed encoding would fail since servers wouldn't be able to see the file according to a correct network path served by the main pc. When there is no distributed encoding, the program does just this - the source file is not copied to the temp folder and is encoded in place with the encoded mkv being created in the temp folder and then moved to the output folder. What I am attempting is to parallel this behavior for distributed encoding by moving the source file such that the servers can see it in the share folder. The move is only useful if the temp folder and source file are on the same drive, otherwise a copy is necessary. I'm sure a safety check could also be written that will move the source file out of the temp folder to an "original" or "archive" folder before deleting the temp folder when the job is finished.

Basically, the "move" option will only work in the instance where all of the following are met:
1) If distributed encoding was not enabled, the job would not require the file to be copied to the temp folder and would be encoded from its current location.
2) The source file and the temp folder are located on the same drive.
3) Distributed encoding is used.

Scenario:
As an example, take an MKV file with ac3 audio and avc video as the source file, the following happens:

Process 1: Distributed Encoding Disabled
1) Hit add > select MKV file
2) File is added, the audio stream and subtitles are demuxed into the temp folder. The video stream is NOT demuxed. Video/audio info fills into the proper areas. Audio is set to copy, subtitle stream is selected but set to not default/forced.
3) Hit "OK", then "Start"
4) Pass 1 starts immediately, followed by Pass 2.
5) Audio/Subtitles/Video are muxed into MKV file.

Process 2: Distributed Encoding Enabled
1) Hit add > select MKV file
2) File is added, the audio stream and subtitles are demuxed into the temp folder. The video stream is NOT demuxed. Video/audio info fills into the proper areas. Audio is set to copy, subtitle stream is selected but set to not default/forced.
3) Hit "OK", then "Start"
4) Ripbot tools are copied to the temp folder
5) Source file is copied to the temp folder
6) Pass 1 starts, followed by Pass 2
7) Audio/Subtitles/Video are muxed into MKV file.

There is absolute no difference between the two processes above except that one is distributing the video encoding. However, the file copy in step 5 of the DE Process takes up 2-3 minutes that could be used for encoding. With multiple files, this can amount up to an hour or more if say a TV season is being backed up. That's an hour that could be used for encoding.

[thahandy]

Error: The file 'D:\Temp\RipBot264temp\video.264' could not be opened for reading: open file error.

You mind pointing out when you have this error with distributed encoding enabled:
(which means it skipped the encoding and trying the mux the file together to final file.)

YOU NEED TO MAKE A NETWORK SHARE TO RipBot264temp

Took me ages to figure out what RipBot was doing, causing to create this message. :angry:

[Ronski]

I have to agree it is annoying having a copy of the file created, would it not be better to just share the source location as well?

I use ssd's in my new system, as I suspect a lot of others do. Making an additional copy of the file will be eating into the life of SSD drives. I alway rip the blu ray with Make MKV, then extract just the video for ripbot to work with. Then I manually mux everything back in how I want it with MKV Toolnix. It may be not be the best way, but it's the way I've found that works best for me.

[jthekk2]

I have to agree it is annoying having a copy of the file created, would it not be better to just share the source location as well?

I use ssd's in my new system, as I suspect a lot of others do. Making an additional copy of the file will be eating into the life of SSD drives. I alway rip the blu ray with Make MKV, then extract just the video for ripbot to work with. Then I manually mux everything back in how I want it with MKV Toolnix. It may be not be the best way, but it's the way I've found that works best for me.Correct me if I'm wrong, but a move between folders with the same root drive letter doesn't actually move the file on the disk. It simply moves the "link" within the OS that points to the location of the file on the physical HDD/SSD (e.g. what sector). If the move is between different drives or partitions, then it copies the physical file from the sectors of drive/partition 1 to the sectors of drive/partition2 and deletes from drive/partition1 to finish the move. If the network location of a folder is used, the computer thinks the transfer is to a different drive and copies instead of moves.

TL;DR: a move of a large file within a drive shouldn't affect the health of your SSD as it is insignificant compared to the activity a read/write performs during a file copy.

Also, should you be encoding files on the SSD...a HDD is almost never a bottleneck (the CPU usually is), and encoding performs substantial writes and will kill your SSD quicker. Maybe keep the encoding process on the SSD but the files on the HDD?

Also, making the source location "shared" would be difficult if files are added from wherever. Much easier to just move it to the temp directory that's already shared and move it back after the encode finishes before anything is deleted from the temp folder. Ripbot itself cannot share a folder so you'd have to manually share each folder instead of only needing to share one folder.

[thahandy]

While Ripbot is running as administrator it can easily setup a share and set the rights by it self.

The thing is with windows share in 7/8/10 is the type of share. There is the classic share(advanced share) and the "homegroup" share.

I think by using FTP or other (custom) file transfer protocol, you'll get the same results without using share.
Server will be downloading chunk, encode it and send it back to host. Repeat.

commands to create advanced share

net share Docs=E:\Documents /grant:everyone,FULL

net share E:\Documents /delete

icacls "E:\Documents" /grant Everyone:F <---- important for "guest" users accessing the share


Also about adding files. Why the the audio/subtitles needs to be extracted from the source file?
Is eac3to or other type app. not good enough to get the info?
Not able to add files to batch and let it extract/encode/whatever when u start the batch so u don't have to worry about waiting....

/another issue
after copying the files to the network share (u mean demuxing the video file to the folder) its running this command:
"\\USER\Ripbot264temp\Tools\AviSynth plugins\ffms\ffmsindex.exe" -f -k "D:\Temp\RipBot264temp\job1\video.mkv"
why not use D:\Temp instead \\USER?

[Atak_Snajpera]

I think by using FTP or other (custom) file transfer protocol, you'll get the same results without using share.
Server will be downloading chunk, encode it and send it back to host. Repeat.
No thanks. Windows share method is a lot easier than transfering data via some custom made protocol. Change for change and nothing more. You know that saying "If ain't broken ,don't fix it" ;)


While Ripbot is running as administrator it can easily setup a share and set the rights by it self.


EncodingClient automatically shares RipBot264temp folder.

It does that at the very beginning.

Code
if DirectoryExists('\\'+form1.JvComputerInfoEx1.Identification.LocalComputerName+'\Ripbot264temp\')=true then ExecuteConsole('net share Ripbot264temp /DELETE /Y','netshare'); //stop sharing Ripbot264temp (user might change temp location)
ExecuteConsole('net share Ripbot264temp='+Copy( form1.Edit1.Text,0,Pos('\job',form1.Edit1.Text)-1 )+' /grant:Everyone,full','netshare'); //share Ripbot264temp
ExecuteConsole('cacls '+Copy( form1.Edit1.Text,0,Pos('\job',form1.Edit1.Text)-1 )+' /T /E /G Everyone:f','cacls');

"\\USER\Ripbot264temp\Tools\AviSynth plugins\ffms\ffmsindex.exe" -f -k "D:\Temp\RipBot264temp\job1\video.mkv"
why not use D:\Temp instead \\USER?

Something wrong with UNC path?

[thahandy]

So, what is causing the shares are not working on my side. I need to enable this when its copying the files manually twice. (add share, set folder permission, add share again :confused: )
The only thing I can think of is the share wizard i have changed to advanced.
Any debug options?

the default UNC path are working fine.

[Atak_Snajpera]

I see that you are using icacls while I use older cacls. Can you check this command on your pc ?
cacls D:\Temp\RipBot264temp /T /E /G Everyone:f

[thahandy]

The post about icacls where just an example. I used the folder property's to set it.

But back to your question. The command does not work in the first place.
It seems its a language issue. Because if I translate "everyone" to "iedereen" (dutch) the command works like a charm ;)
I guess thats why the share is not created :D

Seems U can use SID to fix this.
http://www.iatarstudio.com/blog/set-permissions-with-cacls-independent-on-language/

[Markstar]

Hi,
I've been using RipBot for years (and other tools before that), but for a couple of months now I'm struggling with unreliable file sizes.

Usually my movie backups were around 1.5 - 2.5GB (720p, CRF 20, [HI10 x.x] SLOW . DEFAULT) - obviously depending on the usual factors like length, noise, movements, etc. - but then they started to be too small (~1.0GB). Sometimes I could fix that by playing with the settings without changing anything significant (or anything at all) and then re-encoding, sometimes I would just select a lower CRF value.

However, now I my file sizes are too big (3.5+ GB) and if I select a higher the CRF value (e.g. 22), the video looks crappy. I have tried more that 10 movies, all with the same result.

Is there anything that has changed in the new versions that could account for this? I'm at a loss - I'm running the same system for years and have not changed anything as far as I can tell. :confused:

Thank you in advance for your help! :o

[Atak_Snajpera]

show us your x264 command line.

Is quality worse than before?

[Markstar]

show us your x264 command line.The AVC encoder setting command is:

--profile high10 --preset slow

Is quality worse than before?I feel like it is, definitely when comparing relatively similar file sizes (when I eventually get it there).

[jthekk2]

Atak, any input on my suggestion for an option for a "move" instead of "copy" for distributed encoding? (see below)

What I am attempting is to parallel the non-distributed behavior for distributed encoding by moving the source file such that the servers can see it in the share folder. The move is only useful if the temp folder and source file are on the same drive, otherwise a copy is necessary. I'm sure a safety check could also be written that will move the source file out of the temp folder to an "original" or "archive" folder before deleting the temp folder when the job is finished.

Basically, the "move" option will only work in the instance where all of the following are met:
1) If distributed encoding was not enabled, the job would not require the file to be copied to the temp folder and would be encoded from its current location.
2) The source file and the temp folder are located on the same drive.
3) Distributed encoding is used.

Scenario:
As an example, take an MKV file with ac3 audio and avc video as the source file, the following happens:

Process 1: Distributed Encoding Disabled
1) Hit add > select MKV file
2) File is added, the audio stream and subtitles are demuxed into the temp folder. The video stream is NOT demuxed. Video/audio info fills into the proper areas. Audio is set to copy, subtitle stream is selected but set to not default/forced.
3) Hit "OK", then "Start"
4) Pass 1 starts immediately, followed by Pass 2.
5) Audio/Subtitles/Video are muxed into MKV file.

Process 2: Distributed Encoding Enabled
1) Hit add > select MKV file
2) File is added, the audio stream and subtitles are demuxed into the temp folder. The video stream is NOT demuxed. Video/audio info fills into the proper areas. Audio is set to copy, subtitle stream is selected but set to not default/forced.
3) Hit "OK", then "Start"
4) Ripbot tools are copied to the temp folder
5) Source file is copied to the temp folder
6) Pass 1 starts, followed by Pass 2
7) Audio/Subtitles/Video are muxed into MKV file.

There is absolute no difference between the two processes above except that one is distributing the video encoding. However, the file copy in step 5 of the DE Process takes up 2-3 minutes that could be used for encoding. With multiple files, this can amount up to an hour or more if say a TV season is being backed up. That's an hour that could be used for encoding.

[thahandy]

Atak, any input on my suggestion for an option for a "move" instead of "copy" for distributed encoding? (see below)

Process 2: Distributed Encoding Enabled
1) Hit add > select MKV file
2) File is added, the audio stream and subtitles are demuxed into the temp folder. The video stream is NOT demuxed. Video/audio info fills into the proper areas. Audio is set to copy, subtitle stream is selected but set to not default/forced.
3) Hit "OK", then "Start"
4) Ripbot tools are copied to the temp folder
5) Source file is copied to the temp folder
6) Pass 1 starts, followed by Pass 2
7) Audio/Subtitles/Video are muxed into MKV file.


I think you forgetting a few, after figuring out why there was no share.. on my case.

Process 2: Distributed Encoding Enabled
1) Hit add > select MKV file
2) File is added, the audio stream and subtitles are demuxed into the temp folder. The video stream is NOT demuxed. Video/audio info fills into the proper areas. Audio is set to copy, subtitle stream is selected but set to not default/forced.
3) Hit "OK", then "Start"
4) Ripbot tools are copied to the temp folder
5a) Video file is demuxed to the temp folder
5b)scanning video files for key(I) frames (from this part the share bust be working, but not yet used for distributed encoding)
5c)create Distributed jobs matching the key(I) frames (1min/job by default)
6a) Pass 1 starts, followed by Pass 2
6b)when done encoding, merge encoded files to one file.
7) Audio/Subtitles/Video are muxed into MKV file.

Tbh. you don't want to move the source file. What if the job is interrupted. People will looking or complain about it because the file isn't moved back.
It seems this is the way to do it when it comes to distributed encoding.
But what I don't like it the demuxing of the audio and subtitles when u add a file, I see no reason

Atak_Snajpera can you explain why you demux the audio/subtitles? (or demux at all?)

[jthekk2]

I think you forgetting a few, after figuring out why there was no share.. on my case.

Process 2: Distributed Encoding Enabled
1) Hit add > select MKV file
2) File is added, the audio stream and subtitles are demuxed into the temp folder. The video stream is NOT demuxed. Video/audio info fills into the proper areas. Audio is set to copy, subtitle stream is selected but set to not default/forced.
3) Hit "OK", then "Start"
4) Ripbot tools are copied to the temp folder
5a) Video file is demuxed to the temp folder
5b)scanning video files for key(I) frames (from this part the share bust be working, but not yet used for distributed encoding)
5c)create Distributed jobs matching the key(I) frames (1min/job by default)
6a) Pass 1 starts, followed by Pass 2
6b)when done encoding, merge encoded files to one file.
7) Audio/Subtitles/Video are muxed into MKV file.

Tbh. you don't want to move the source file. What if the job is interrupted. People will looking or complain about it because the file isn't moved back.
It seems this is the way to do it when it comes to distributed encoding.
But what I don't like it the demuxing of the audio and subtitles when u add a file, I see no reason

Atak_Snajpera can you explain why you demux the audio/subtitles? (or demux at all?)My point is that for a user who knows what they are doing, step 5a aka "the copy" (you have listed it as "demux" but it is 100% a copy of the entire file as there is NO video demux or copy in non-distributed and the file that is copied over is 100% the original file, audio and subs included - verified with MediaInfo) is unnecessary. The I-frame keying will happen regardless of whether the original file is copied or moved. If the job is prone to being interrupted, you actually have the benefit of DE which saves progress up to the chunk that it is up to. You can just resume and then when it finishes you can have the original moved out (the "move" back to the original folder could be keyed to only occur if the encode is successful, e.g. 100%). If your encodes are failing for some other reason than power loss to the PC, you should check what you're doing before enabling the "move" feature. Regardless, ripbot264 doesn't delete files in the temp folder if it crashes or if there is power loss so there is no risk of losing any files and with DE you don't really lose too much progress on the encode either. All I'm asking for is an option to increase efficiency for those who know what they're doing - it doesn't even have to be in the GUI, a line in the INI that activates the file would suffice and would avoid unwary users from activating it (a "DO NOT TOUCH UNLESS YOU KNOW WHAT YOU ARE DOING" disclaimer could be notated before the option in the INI).

The audio and the subtitles have to be demuxed for processing (even if only copying the files) so they can be muxed back into the final product. The video doesn't need to be demuxed if it is in a format that can be piped into x264/hevc directly. If the MKV when added has no audio or subtitles (which will be the case with the majority of the files I will actually pipe into ripbot), there is NO demuxing of any streams when adding the files and selecting the profile for encoding.

[Atak_Snajpera]

Added: hidden option to move mkv to shared folder. Following lines must be added manually to EncodingClient.ini

[hidden settings]
MoveMKVtoSharedFolder=1

Added: Updater automatically fixes corrupted updater.ini file
Fixed: Downmix 4.0 to 2.0 didn't work
Changed: In order to avoid language issues Encoding Client will share ripbot264temp folder using following command line

icacls "...\RipBot264temp" /T /C /Q /Grant:R *S-1-1-0:(OI)(CI)F

I recommend deleting Temporary Internet Files. Otherwise updater may use cached files!
http://i.cubeupload.com/HHiFzB.png

[jthekk2]

Added: hidden option to move mkv to shared folder. Following lines must be added manually to EncodingClient.ini

[hidden settings]
MoveMKVtoSharedFolder=1
Thanks so much for the hidden option! Just tested it with a re-encode of a small 500 frame test file and with The Godfather Epic that I DVR'd off HBO a few months ago (avoiding copying a 42+ GB file was awesome) and went straight to encoding, and it works like a charm!

The option moves the source file to the shared folder once the DE process (encoding client window) starts up and moves the source file back to the original folder once the encoding is done.

[slalom]

@Atak
about aspect ratio
I've met 2/1 ratio like House of Cards (1920x960)
and a 2.8/1 on some old movies

Could you add those two ratios for a proper 1920x1080?

[guest]

Added: hidden option to move mkv to shared folder. Following lines must be added manually to EncodingClient.ini

[hidden settings]
MoveMKVtoSharedFolder=1

Added: Updater automatically fixes corrupted updater.ini file
Fixed: Downmix 4.0 to 2.0 didn't work
Changed: In order to avoid language issues Encoding Client will share ripbot264temp folder using following command line

icacls "...\RipBot264temp" /T /C /Q /Grant:R *S-1-1-0:(OI)(CI)F

I recommend deleting Temporary Internet Files. Otherwise updater may use cached files!



Is there a new update available ??? I haven't been able to get it, if there is, and I've done the clean up.

[Ronski]

Thanks for adding the move option, but I don't seem to be getting a new update either, I've also done the clean up. Update log shows an update check has been done, zip file downloaded but no updates required. Ripbot shows version V1.19.3

[Zetti]

#Atak_Snajpera

Why is there still needed FFDshow and not LAV Filters??

[guest]

Thanks for adding the move option, but I don't seem to be getting a new update either, I've also done the clean up. Update log shows an update check has been done, zip file downloaded but no updates required. Ripbot shows version V1.19.3

Finally got the update, approx 96Mb of new Ripbot goodness :)

[apostolis21]

Hi Atak, I am facing the following issue. I load a ts file which is 314000 frames long. At the main window ripbot recognizes the total frame number of the file but when I start the encoding only 35000 frames are being encoded (and this is also the number I am getting at the counter). It has happened with two different ts files and it seems like a minor bug? Any help with that?

I use Ripbot 1.19.3

EDIT: When I choose 'No audio' option ripbot starts to encode all frames so something is wrong with the audio file or the audio encoding process, any ideas?

[tim_ettinger]

I have been using RipBot for several years, and have also been playing with the interframe script. Here's where I am now with the script I add to RipBot:

cores=24
SetMTMode(3,cores)
PluginPath="C:\Program Files (x86)\AviSynth\plugins\"
LoadPlugin(PluginPath+"svpflow1.dll")
LoadPlugin(PluginPath+"svpflow2.dll")
Import(PluginPath+"InterFrame2.avsi")
SetMTMode(2)
InterFrame(GPU=True, Tuning="Film", Preset="Medium", NewNum=48000, NewDen=1001, Cores=cores)

It still takes a long time to compress. I have been doubling the video bitrate of the files I encode, because it seems that twice as many frames needs twice as much bitrate.

If there is a better way to do what I am doing, please let me know. I have used RipBot for a long time, and appreciate its simplicity and distributed encoding. I don't know a lot about AviSynth scripts or x264 tweaking, and I am not certain I should bother with x265.

[Atak_Snajpera]

Looks ok to me. How many fps do you get in avs meter? I would also measure fps with just two threads. Too many threads may actually slowdown whole process.

[tim_ettinger]

Usually 15 - 25 FPS on the second pass, reading from the RipBot window. I have a dual X5675 computer with SSD and 48GB RAM I do the encoding on, which is why I pushed the cores to 24 - physical cores x2 for hyper threading. It still takes a long time, but I can run it with 2 cores to see what the speeds are.

I haven't used avs meter before, but can probably figure it out.