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 15th August 2019, 19:38   #17141  |  Link
Ronski
Registered User
 
Join Date: Oct 2010
Posts: 48
Viper714, thank you so much for the reply, disabled the Logitech framework and Ripbot now works. I only have the Logitech software installed for my MX518 mouse (not compatible with ghub), and that seems to work fine without the frame work running.
Ronski is offline   Reply With Quote
Old 17th August 2019, 06:34   #17142  |  Link
howzz
Registered User
 
Join Date: Jun 2008
Posts: 34
i got a bit of an odd question for the author, i noticed that ever since v 1.25, with Lmash decoding i assume, the indexing process takes twice as long than before. i built my encoding machine purposely with all Nvme drives to speed up the demux and index process, but it seems with the latest Lmash update, after the demux, and after index (which btw you can tell that sequential disk read/write are both at max), "gathering information/Extracting Frames" seems to be doing some additional CPU crunching without much disk usage or if at all and that "gathering information/extracting frames" process now takes wayyyyyy longer than before.

i confirmed the performance difference by comparing to v. 1.23.1, which was my fall-back version.

with v. 1.23.1, after demux and index, gathering information only takes about 5 seconds on my Nvme doing HDR H265 source, now with v. 1.25 when it gets to the Gathering Information and extracting frames, it takes like 5~10 or so mins? i checked the task manager while it's doing its thing to find out why it's taking this longer, and looks like it's launching the ffprobe AGAIN to do something. FFProbe was already launched once when demuxing was taking place but why now again?

thoughts?

Last edited by howzz; 17th August 2019 at 10:31.
howzz is offline   Reply With Quote
Old 17th August 2019, 13:30   #17143  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 6,986
What is the size of .lwi file in job folder?
Atak_Snajpera is offline   Reply With Quote
Old 17th August 2019, 20:12   #17144  |  Link
howzz
Registered User
 
Join Date: Jun 2008
Posts: 34
Quote:
Originally Posted by Atak_Snajpera View Post
What is the size of .lwi file in job folder?
about 1.25GB

is that good or bad
howzz is offline   Reply With Quote
Old 17th August 2019, 21:37   #17145  |  Link
howzz
Registered User
 
Join Date: Jun 2008
Posts: 34
i tried v 1.23.1 again, and it doesn't produce .lwi file at all. so i guess v 1.25 is producing this .lwi file that's taking forever. what exactly does it do, and why do we need it? this makes me want to just go back to v 1.23.1 but v. 1.25 has the latest version of X265 (release v30 i beleive) with lots of improvements in the codec.
howzz is offline   Reply With Quote
Old 18th August 2019, 00:06   #17146  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Germany
Posts: 5,722
Quote:
Originally Posted by howzz View Post
i tried v 1.23.1 again, and it doesn't produce .lwi file at all. so i guess v 1.25 is producing this .lwi file that's taking forever. what exactly does it do, and why do we need it? this makes me want to just go back to v 1.23.1 but v. 1.25 has the latest version of X265 (release v30 i beleive) with lots of improvements in the codec.
Source filters like ffms2, l-smash and dgdecnv create a index file before they open a source file, it's used to enable seeking. l-smash has a filter that can open mp4 without creating an index file, sadly not working with mkv.
stax76 is offline   Reply With Quote
Old 18th August 2019, 00:23   #17147  |  Link
howzz
Registered User
 
Join Date: Jun 2008
Posts: 34
Quote:
Originally Posted by stax76 View Post
Source filters like ffms2, l-smash and dgdecnv create a index file before they open a source file, it's used to enable seeking. l-smash has a filter that can open mp4 without creating an index file, sadly not working with mkv.
so does this mean that you can use a player to play the movie and able to do fast seek? if so that's an awesome added feature that i am willing to take the performance hit (waiting for it to create index).

but maybe i misunderstood you.
howzz is offline   Reply With Quote
Old 18th August 2019, 00:44   #17148  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Germany
Posts: 5,722
Quote:
Originally Posted by howzz View Post
so does this mean that you can use a player to play the movie and able to do fast seek? if so that's an awesome added feature that i am willing to take the performance hit (waiting for it to create index).

but maybe i misunderstood you.
It's unrelated to playback, source filters create an index helping them to ensure frame accuracy for random frame access that some filters might do. There are people who understand and can explain this better than me.
stax76 is offline   Reply With Quote
Old 18th August 2019, 00:50   #17149  |  Link
howzz
Registered User
 
Join Date: Jun 2008
Posts: 34
Update:

Strangely. there's a new update that just rolled out a few mins ago. i launched ripbot again and it udpated itself. so i looked into the update log, and looks like either Atak may have enabled a new update for Lmash pushed a new version update to ripbot. either way, Lmash got updated, and now when it gets to Gathering Information/Extracting frames, it does so much faster. i also noticed that it compressed the index with the new update. so instead of the massive 1.25GB index file, .lwi is now 30MB small. and you can tell that when it compressed it because just right after indexing and before Gathering information, you see the ripbot status bar briefly shows Compressing Index. it then quickly proceeds to Gathering information and Extracting Frame and only take 3 or so mins now.

so whatever Atak did. thanks!. or whatever Lmash did, thanks!

==========
2019-08-17 13:38:25 : Update for [lsmash] detected
2019-08-17 13:38:25 : Downloading file http://atak-snajpera.5v.pl/ripbot264update/lsmash.zip to D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip
2019-08-17 13:38:26 : [SUCCESS] File D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip saved!
2019-08-17 13:38:26 : CRC32 value has not changed for [7z]. Update is not required.
2019-08-17 13:38:26 : Downloading finished.
2019-08-17 16:37:34 : =========================[UPDATER ACTIVATED]=========================
2019-08-17 16:37:34 : Installing updates...
2019-08-17 16:37:39 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\core.zip has been correctly extracted!
2019-08-17 16:37:48 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\ffmpeg.zip has been correctly extracted!
2019-08-17 16:37:49 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip has been correctly extracted!
2019-08-17 16:37:49 : Installation complete.
2019-08-17 16:37:55 : Next check after 2019-08-18 13:38:18
2019-08-17 16:38:42 : Next check after 2019-08-18 13:38:18
howzz is offline   Reply With Quote
Old 18th August 2019, 00:58   #17150  |  Link
howzz
Registered User
 
Join Date: Jun 2008
Posts: 34
Quote:
Originally Posted by stax76 View Post
It's unrelated to playback, source filters create an index helping them to ensure frame accuracy for random frame access that some filters might do. There are people who understand and can explain this better than me.
thanks, your explanation actually makes sense to me.
howzz is offline   Reply With Quote
Old 18th August 2019, 08:51   #17151  |  Link
FuzzyNutz
Registered User
 
Join Date: Jun 2016
Location: Canada
Posts: 96
flickering playback

As of the last few days, playback of some of my blu-ray source videos encoded with RB have occasional flickering, where video frames seem to pause or jump back and forward within fractions of seconds. After the incidents, playback returns to normal and the audio is still synced correct.

Last edited by FuzzyNutz; 18th August 2019 at 08:54.
FuzzyNutz is offline   Reply With Quote
Old 18th August 2019, 14:21   #17152  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 210
Quote:
Originally Posted by byteshare View Post
Mostly to keep the mkv title of subs I process subs and audio outside of RipBot and mux it all a back at the end with a batch file. If you want any help with that let me know.
Hey.
Thank you for the offer. I had a closer look into the temp folders... The two audio streams are extracted, audiolist.txt lists two streams and audiostreams.cmd lists to prozess 3 streams.
What´s missing is content in "encodeaudio2.cmd" - it has zero bytes.
ReinerSchweinlin is offline   Reply With Quote
Old 18th August 2019, 20:41   #17153  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 112
I'm having an odd issue with ripbot. It's taking 5-15 minutes to start an encode chunk every time. I already did the update which compresses the lwi file down to around 30MBs.

Something I've noticed is that when the encoding client is starting a new chunk. The system process pegs my network connection - currently 1Gbps. While the disk usage is very low. So it'll start disk usage will hit 20-30MBps then drops to 1-2MB/s while the network is pegged at 800-900 Mb/s. it'll stay like that for quite some time. This is going from a R7 1700 to a AMD 3900x via Gigabit ethernet at the moment.

I've also confirmed the system running the encoding server matches the system process behavior.

I've also tried this on another machine same issue - 16c Xeon v4.

I understand that the lwi file is larger in general which takes it longer to copy. This seems abnormally long given the lwi file uncompressed is usually around 1.3GBs for a 4K movie.

Thoughts?

Last edited by brumsky; 18th August 2019 at 20:49.
brumsky is offline   Reply With Quote
Old 18th August 2019, 20:55   #17154  |  Link
Pino72
Registered User
 
Join Date: Mar 2018
Posts: 7
Same for me, the last days were a nightmare....DE that always worked since months suddenly broken, servers not starting at all, big time delays when rendering chunks like you described, a looooong wait for Autocrop and so on.

I hope these issues get fixed soon since I really think ripbot is the best tool to convert uhd 4K hdr files.

At least since today I am able to use DE again on my two machines and even after aborting he picks up where it left....which also seemed broken a day or two ago. Really strange.
Pino72 is offline   Reply With Quote
Old 18th August 2019, 22:38   #17155  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 112
Digging into this further, I can see that it is reading the video.mkv file. It appears to be transferring the whole file. that is the only thing that makes sense given how small the new lwi files is after compressing.
brumsky is offline   Reply With Quote
Old 18th August 2019, 22:42   #17156  |  Link
slalom
Registered User
 
slalom's Avatar
 
Join Date: Jan 2010
Posts: 332
Same here, veeeery long delays, the network at 97% (gigabit)
__________________
i7-980 @ 4.16GHz 8GB
i5-750 @ 3.36GHz 12GB
Sony Vaio VPC-F13Z1E/B
slalom is offline   Reply With Quote
Old 19th August 2019, 02:31   #17157  |  Link
BLKMGK
Registered User
 
Join Date: Feb 2008
Posts: 136
Quote:
Originally Posted by Atak_Snajpera View Post
If you are going to use KNLMeansCL in DE mode then you must:
1) have decent gpus in all PC's. GeForce 210 is just a crap GPU (Supports up to OpenCL 1.1 [knlmeansCL requires 1.2] and only two compute units!).
2) manually set device id in encoding server if you have more than one GPU. One of your machines has Intel GPU and GeForce 1070 for example.
This will tell encodingserver to use GeForce 1070 (faster)
EncodingServer.exe /knlmeanscl-opencl-device-id 1

In your case It might be a good idea to run one server using Intel GPU and other GeForce 1070 .
EncodingServer.exe /knlmeanscl-opencl-device-id 0
EncodingServer.exe /knlmeanscl-opencl-device-id 1

This way you will be using literally everything what can compute CPU+iGPU+dGPU

If you want you can also try running KNLMeansCL on CPU but be warned it will be veeeeeeeerrrrrrryyyyy slooooooooow.
EncodingServer.exe /knlmeanscl-opencl-device-type CPU
Okay, I've now installed an OpenCL1.2 compatible 1050 Ti card. I can encode on THAT machine with KNLMeansCL just fine but when I attempt to use that as a client with an existing machine that can already handle KNLMeansCL the Encoding Server accepts the job but never actually processes it Here's the OpenCL settings page, note that for jobs not using this filter this client works just fine. Am I missing something? This client was updated as of this afternoon so it's current. This should work right?

P.S. I tried piping the filter to the CPU, it didn't work either sadly, I'd have loved to see how the 3900X handled that



Edit: I may have found something - it looks like the old index files and the new index files may not be playing well together? My GTX 680 card claims OpenCL 1.2 but after a lengthy period of time creating the index it fails to "open file" like my previous attempts and then tries to recreate the index AGAIN :-O I will try this on the machine with the 1050 card as soon as I'm able to gain access to it again.

Last edited by BLKMGK; 19th August 2019 at 02:58.
BLKMGK is offline   Reply With Quote
Old 19th August 2019, 07:22   #17158  |  Link
BLKMGK
Registered User
 
Join Date: Feb 2008
Posts: 136
Whoa! Just threw a brand new unfiltered job into the queue. After EACH block it's rebuilding an index file! It's literally taking longer to build the index file than it is to compress the block - d'oh! This is v1.25 using Encoding Server v1.15.2.0 just updated tonight.
BLKMGK is offline   Reply With Quote
Old 19th August 2019, 10:18   #17159  |  Link
Pino72
Registered User
 
Join Date: Mar 2018
Posts: 7
Funnily, chunks in DE on the remote machine start more or less immediately on the local machine it takes 1-2 minutes....is this supposed to be normal? Did not have the rebuilding of the index luckily.
Pino72 is offline   Reply With Quote
Old 19th August 2019, 10:27   #17160  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 210
I recognized something:

- The new index files are put into the source directory instead of the TEMP dir.
- after encoding and deleting all the jobs, the files still are recognized as "used" by windows.
- on some machines in the local network, the creating of the LWI Files after "Start" takes several minutes (the lokal machine and two others - all others are finished after a few seconds)

Last edited by ReinerSchweinlin; 19th August 2019 at 11:24.
ReinerSchweinlin 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 11:12.


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