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. |
|
|
Thread Tools | Search this Thread | Display Modes |
27th January 2016, 12:33 | #14101 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
Hardware decoding won't give you noticeable speed up because encoding process is a real bottleneck here. Basically decoding process is waiting for x264/x265 encoder.
Take a look a this example using software decoding Source is VC-1 and encoding was done using veryslow preset. Decoding process consumes only ~3% of cpu time on Xeon E5-2690 2.9Ghz.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 27th January 2016 at 13:39. |
27th January 2016, 19:06 | #14102 | Link | |
Registered User
Join Date: Jan 2007
Posts: 28
|
Quote:
The main point I was trying to show, however, is that Ripbot doesn't handle previously indexed files properly. After further testing: (1) If any AVS script loading any of FFMS2.dll, DGDecodeNV.dll or DGAVCDecode.dll and the video referenced is the appropriate file or index file (FFmpeg source for .mkv/DGSource for .dgi/AVCSource for .dga), Ripbot will encode the file locally and will not re-index the file. (2) If the workaround from my first post is used (editing the ripbot automated avs script when the video file (.mkv with vc1/.mkv with vc1/.mkv with 264) itself is loaded into ripbot to import the avs script), the following occurs: (A) FFMS: VC1 must be in MKV, otherwise local encoding. If in MKV, re-indexes with FFMS and encodes with distributed encoding using FFMS2 decoding and the OLD FFMSIndex file (the one referenced in the original AVS; I can only assume based on the avs scripts). (B) DGDecodeNV: VC1 must be in MKV, otherwise local encoding. If in MKV, re-indexes with FFMS and encodes with distributed encoding using DGDecodeNV (got this working with server paths and checked the decoding method by using GPU-Z; GPU load went up during encode and also tested with a non-Nvidia GPU PC as a server which would not start its chunk of the encode as expected since it does not have nvcuvid.dll to do the actual decoding). (C) DGAVCDecode: 264 must be in MKV, otherwise local encoding. If in MKV, re-indexes with DGAVCIndex and encodes with distributed encoding using the OLD DGAVCIndex file (the one referenced in the original AVS; I can only assume based on the avs scripts). It seems odd that the workaround above produces the correct result in the end when all is said and done (distributed encoding with a preconfigured AVS script and pre-indexed MKV file using FFMS/DGAVCDecode/DGDecodeNV), but that the MKV has to be the file actually loaded into ripbot (VC1/264 only encode locally), the avs script within ripbot has to be changed (which takes time), and the file is re-indexed even though it doesn't use the index created by ripbot. Possible Solutions: - Allow distributed encoding with AVS scripts directly. This should remove the re-indexing problem as well as the need to put the files in MKVs, though this may require Ripbot to grab the path to the DGI/DGA/FFMSIndex files from the AVS script in order to calculate chunks. - Allow DGI/DGA/FFMSIndex files as inputs. Doing should also look through the folder the files are loaded from and set the internal video script to match the AVS script with the same name as the index file. Loading in an index file as an input can also trigger a "flag" within Ripbot not to re-index the file but to instead look within the index that was inputted. This should also remove the requirement to have the file in an .mkv since the index files and avs files are the ones being loaded and analyzed and then piped into x264 (which can handle the index files as inputs). If the reindexing issue above could be addressed, that would be awesome. Without reindexing and if the "copy to temp folder" can be replaced with a "move to temp folder" option, I would be able to incorporate Ripbot distributed encoding almost seamlessly into my automation scheme; I would simply have to pipe in the AVS scripts or Index files manually into Ripbot before letting the automation take over again (using a file watch of some sort for the outputs from Ripbot). TL;DR: (1) DGDecodeNV works in distributed encoding, but the file is reindexed with FFMS (vc1) or DGAVCIndex (264) before the encode even though DGDecodeNV is used. Possible solutions are allowing distributed encoding with avs files, or allow index files as inputs with flags to not reindex. (2) Please create a toggle/option to move files to the TEMP folder instead of copy. Last edited by jthekk2; 27th January 2016 at 19:09. Reason: added the TL;DR |
|
28th January 2016, 21:00 | #14103 | Link |
Registered User
Join Date: Dec 2015
Posts: 2
|
Socket Error # 10054
getting an error from my client computer during distributed encoding
Socket Error # 10054 Connection reset by peer And I can't stop the encode as it just brings up the error again. What could be causing it? |
28th January 2016, 21:08 | #14104 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
Firewall ? Probably something is blocking connection.
Quote:
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 28th January 2016 at 21:11. |
|
30th January 2016, 18:05 | #14106 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
Are you sure that you are working on correctly decrypted source?
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
3rd February 2016, 08:51 | #14110 | Link | |
Registered User
Join Date: Nov 2015
Posts: 7
|
Quote:
|
|
3rd February 2016, 10:54 | #14111 | Link | |
Registered User
Join Date: Jun 2010
Location: NSW, Australia.
Posts: 366
|
Quote:
It does sound like it might be a "ripping" problem, what are you using ? What differences are there between the 2 pc's ? |
|
3rd February 2016, 20:02 | #14112 | Link | |
Registered User
Join Date: Nov 2015
Posts: 7
|
Quote:
About a year ago, I ripped a blu-ray from my library (Monsters Inc) using MakeMKV and Ripbot together. It worked great then. Today I re-ripped this same blu-ray with MakeMKV, and it seemed to be fine. However, Ripbot isn't showing chapters, video, audio, or subtitles in the "select stream" dialog. All of that said, I did some more digging and found an old MakeMKV rip of a different blu-ray that I ripped about 5 months ago. Ripbot was able to work on it fine on my old computer, and it seems like it's working on my new computer as well. Basically everything I ripped before September 2015 is working, and everything after isn't. Maybe it wasn't the computer switching, but a coincidental update? Or maybe I forgot to install something crucial? Lots of correlating here, but not a lot of causation. |
|
3rd February 2016, 21:48 | #14113 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
When window pops-up go to temp folder and check what you have in following files
Blu-Ray_structure_info.txt Blu-Ray_title1_info.txt
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
3rd February 2016, 22:08 | #14114 | Link | |
Registered User
Join Date: Nov 2015
Posts: 7
|
Quote:
1) 00800.mpls, 00012.m2ts, 1:37:55 - Chapters, 16 chapters - h264/AVC, 1080p24 /1.001 (16:9) - DTS Master Audio, English, multi-channel, 48kHz 2) 00812.mpls, 0:20:14 [280+281+282+283].m2ts - Chapters, 4 chapters - h264/AVC, 1080p24 /1.001 (16:9) - AC3, English, stereo, 48kHz ---- Blu-Ray_title_info.txt says (beneath the command line stuff): The format of the source file could not be detected. <ERROR> |
|
4th February 2016, 11:30 | #14116 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
ste8s
Like I said before most likely source was not correctly decrypted by makemkv.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
4th February 2016, 18:58 | #14117 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
Code:
Update 2016.02.04 Added: KNLMeansCL denoiser (requires GPU with OpenCL 1.2 support) Changed: Levels (PC->TV and TV->PC) separated from colors section
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
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 |
Display Modes | |
|
|