Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 10th May 2016, 22:18   #14381  |  Link
thahandy
Registered User
 
Join Date: Sep 2008
Posts: 27
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 )
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.

Last edited by thahandy; 10th May 2016 at 22:21.
thahandy is offline   Reply With Quote
Old 11th May 2016, 16:42   #14382  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
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
Atak_Snajpera is offline   Reply With Quote
Old 12th May 2016, 05:57   #14383  |  Link
thahandy
Registered User
 
Join Date: Sep 2008
Posts: 27
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

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

Last edited by thahandy; 12th May 2016 at 06:04.
thahandy is offline   Reply With Quote
Old 16th May 2016, 07:44   #14384  |  Link
Markstar
Guest
 
Posts: n/a
Output too small / big?

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.

Thank you in advance for your help!
  Reply With Quote
Old 16th May 2016, 11:30   #14385  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
show us your x264 command line.

Is quality worse than before?
Atak_Snajpera is offline   Reply With Quote
Old 16th May 2016, 13:33   #14386  |  Link
Markstar
Guest
 
Posts: n/a
Quote:
Originally Posted by Atak_Snajpera View Post
show us your x264 command line.
The AVC encoder setting command is:

Code:
--profile high10 --preset slow
Quote:
Is quality worse than before?
I feel like it is, definitely when comparing relatively similar file sizes (when I eventually get it there).
  Reply With Quote
Old 17th May 2016, 08:00   #14387  |  Link
jthekk2
Registered User
 
Join Date: Jan 2007
Posts: 28
Atak, any input on my suggestion for an option for a "move" instead of "copy" for distributed encoding? (see below)

Quote:
Originally Posted by jthekk2 View Post
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.

Last edited by jthekk2; 17th May 2016 at 08:03.
jthekk2 is offline   Reply With Quote
Old 17th May 2016, 22:03   #14388  |  Link
thahandy
Registered User
 
Join Date: Sep 2008
Posts: 27
Quote:
Originally Posted by jthekk2 View Post
Atak, any input on my suggestion for an option for a "move" instead of "copy" for distributed encoding? (see below)
Quote:
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?)

Last edited by thahandy; 17th May 2016 at 22:09.
thahandy is offline   Reply With Quote
Old 18th May 2016, 02:50   #14389  |  Link
jthekk2
Registered User
 
Join Date: Jan 2007
Posts: 28
Quote:
Originally Posted by thahandy View Post
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.

Last edited by jthekk2; 18th May 2016 at 02:53.
jthekk2 is offline   Reply With Quote
Old 19th May 2016, 14:01   #14390  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Code:
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!

Last edited by Atak_Snajpera; 19th May 2016 at 14:08.
Atak_Snajpera is offline   Reply With Quote
Old 19th May 2016, 16:07   #14391  |  Link
jthekk2
Registered User
 
Join Date: Jan 2007
Posts: 28
Quote:
Originally Posted by Atak_Snajpera View Post
Code:
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.
jthekk2 is offline   Reply With Quote
Old 19th May 2016, 23:10   #14392  |  Link
slalom
Registered User
 
slalom's Avatar
 
Join Date: Jan 2010
Posts: 456
@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?
__________________
E5 2697 v2 @ 3.0GHz on P9X79 Deluxe 24GB
Xeon E5-2680 v2 @ 3.1GHz 16GB
Sony Vaio VPC-F13Z1E/B
slalom is offline   Reply With Quote
Old 20th May 2016, 10:32   #14393  |  Link
burt123
Registered User
 
burt123's Avatar
 
Join Date: Jun 2010
Location: NSW, Australia.
Posts: 366
Quote:
Originally Posted by Atak_Snajpera View Post
Code:
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.
burt123 is offline   Reply With Quote
Old 20th May 2016, 18:48   #14394  |  Link
Ronski
Registered User
 
Join Date: Oct 2010
Posts: 61
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
Ronski is offline   Reply With Quote
Old 20th May 2016, 19:30   #14395  |  Link
Zetti
Registered User
 
Join Date: Dec 2015
Posts: 306
#Atak_Snajpera

Why is there still needed FFDshow and not LAV Filters??
Zetti is offline   Reply With Quote
Old 22nd May 2016, 02:12   #14396  |  Link
burt123
Registered User
 
burt123's Avatar
 
Join Date: Jun 2010
Location: NSW, Australia.
Posts: 366
Quote:
Originally Posted by Ronski View Post
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
burt123 is offline   Reply With Quote
Old 22nd May 2016, 04:01   #14397  |  Link
apostolis21
Registered User
 
apostolis21's Avatar
 
Join Date: Jan 2015
Posts: 8
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?

Last edited by apostolis21; 22nd May 2016 at 04:06.
apostolis21 is offline   Reply With Quote
Old 23rd May 2016, 13:12   #14398  |  Link
tim_ettinger
Registered User
 
Join Date: May 2016
Location: Virginia
Posts: 3
Interframe with RipBot264

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.
tim_ettinger is offline   Reply With Quote
Old 23rd May 2016, 13:25   #14399  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
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.
Atak_Snajpera is offline   Reply With Quote
Old 23rd May 2016, 13:42   #14400  |  Link
tim_ettinger
Registered User
 
Join Date: May 2016
Location: Virginia
Posts: 3
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.
tim_ettinger is offline   Reply With Quote
Reply

Tags
264, 265, appletv, avchd, bluray, gui, iphone, ipod, ps3, psp, ripbot264, x264 2-pass, x264 gui, x264_64, x265, xbox360

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.