I've very rarely noticed this when watching an encoding done by RipBot264. This single proc is almost half as fast at encoding as my master server.Įncoding Client 2: Dell R710 with two 4-core sockets running Server 2013 R2, runs 2 RipBot264 threads.Įncoding Client 3: Dell R710 with two 4-core sockets running Server 2013 R2, runs 2 RipBot264 threads. Windows 10 guest with with 42 cores given to it along with 16GB of RAM, runs five RipBot264 threads.Įncoding Client 1: Ryzen 1800x, MSI Gaming Pro board. Master Server 1: Four 12-core Opterrons, 256GB of RAM, running Linux and a Hypervisor (KVM/Libvirt). My distributed encoding is a bit of an odd setup. Going through a frame at a time at 00:15:01,182 shows what looks like a merged frame: The Crucial showed what seems to be a couple of drop frames at pretty much the same time. According to VLC and the "Jumpt to Time" plugin, the corrupted frame happens at 00:15:01,207: It seems with about half of my encodings since then, that I'm finding a dropped or corrupted frames with what I'm assuming is at the end or beginning of a chunk. I'm running 19.6 and I just upgraded a few days ago. I only had problems with TrueHD tracks and this one from the movie Suicide Squad is an example of a TrueHD + Atmos track with 384kbps core. Today I performed the same blu-ray again and RipBot264 did the demuxing correctly, but with that same disc RipBot264 reported this error above and in another attempt was stuck in the "gathering information". Thank you.Īdding to this issue is far more TrueHD tracks have conversion-issue flaws compared to DTS-MA.Ītak, consider changing the job load process to not aboard with an error when TrueHD tracks have issues, but to finish loading the job without the audio. mkv sources, similar to choices we get when loading M2TS files. Also consider an option to preselect audio tracks, including no audio, when loading. I've seen some Atmos with 384kbps cores.Īdding to this issue is far more TrueHD tracks have conversion issues compared to DTS-MA.Ītak, consider changing the job load process to not aboard with an error when TrueHD tracks have issues, but to finish loading the job without the audio. Strangely, some 5.1 and 7.1 TrueHD cores are not 640kbps. Many of us RipBot264 users are aware we can deal with audio conversions outside of RipBot264 with the likes of Eac3to and it's GUIs, but options for TrueHD tracks with issues are often limited to core extractions. You have to wait a while to find out you should have loaded that job without the audio, especially if the source file is M2TS. Choosing to convert to wav or presumably FLAC rather than demuxing can generate similar disappointment. This failure happens at the end of the job load at the gathering info stage. It seems as of v1.19.6, loading jobs involving demuxing TrueHD tracks that have issues of a certain caliber result in a failure. Problems demuxing the movie Suicide Squad. If you have try entering in your "Authentication information under Settings > Distributed Encoding If you haven't already I'd run through the tutorial video: Here's the log file:Ĭ:\>"C:\DVD TOOLS\m2ts utilities\ripbot\EncodingClient.exe" "C:\Temp\RipBot264temp\job1\job1_ta"Ĭ:\>"C:\DVD TOOLS\m2ts utilities\ripbot\tools\mkvtoolnix\mkvmerge.exe" -o "C:\Users\eolus\Desktop\rip\Moonlight 2016 1080p BluRay.mkv" -compression 0:none -title "Moonlight 2016 1080p BluRay" -default-duration 0:24000/1001fps "C:\Temp\RipBot264temp\video.264" -compression 0:none -language 0:eng "C:\Temp\RipBot264temp\job1\Encoded_Audio_1.ac3"Įrror: The file 'C:\Temp\RipBot264temp\video.264' could not be opened for reading: open file error. EDIT: additional server was encoding, everything running smoothly, but at the end of process, the output folder was empty!Ĭannot find the finished file anywhere.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |