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

[FuzzyNutz]

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.

[ReinerSchweinlin]

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.

[brumsky]

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?

[Pino72]

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.

[brumsky]

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.

[slalom]

Same here, veeeery long delays, the network at 97% (gigabit)

[BLKMGK]

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 :D

https://i.postimg.cc/ZqJVKM0B/openCL.jpg

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.

[BLKMGK]

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.

[Pino72]

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.

[ReinerSchweinlin]

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)

[duffbeer]

Has anyone else tried MDegrain2 since the update to LSmash? On my PC, the encoded output is OK for the first few minutes and then it becomes a slideshow of about 2fps.

[BLKMGK]

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)

In my case the LWI files used to be in the source directory but now I can no longer find where they're being stored on disk, perhaps this is why they rebuild with each chunk? Jobs that should complete in under an hour easily are taking quite a bit longer. A queue that should've completed overnight is a fraction of the way complete - d'oh! Even looking at task manager and disk stats I cannot see where the LWI file is being created...

https://i.postimg.cc/zXdJXT37/image.png

[ReinerSchweinlin]

I just looked and can´t find it either.. Strange...

edit: ahhhhhh :

appdata/local/temp/encodingserver1



... there i found some on one of the machines (which takes up a few seconds for the index files.)

I´ve noticed, that the "master machine" (which is one of the ones in the swarm needing about 5min to build the index files compared to around 20 sec) had about 50% to 80% GPU load on the csrss.exe while the index lwmi was building...

Just checked another machine (small 4 Core Celeron with 64bit win10), which does exactly the same - high GPU load on csrss while the index was built... This machine also takes minutes on the same 20min file I am encoding to build the index file.

Checked third machine: Dual Xeon 5660 - no GPU... this one was done in 5 seconds...


another thing: The video file always is copied completely into the TEMP directory - renamed to video.mkv. (The setting is "off" in the settings). Maybe this is on purpose and good for jobs where the source is stored on a usb-hd or slow SMD share - but doing a lot of jobs from a local harddrive I´d guess it would be enough to not copy the whole video - it fills up the temp drive a lot (and after all, we have all these nice indexes now...)

[ReinerSchweinlin]

Update:

Tested another PC - old Core2Duo - no GPU: This one also takes a long time to build the index - not much difference to the master machine (i5 kaby Lake)... So "having a GPU" can´t be the issue :)

It seems, the dual-xeon is so much faster since it has A LOT of cache build in, so it can index much faster - just guessing here.

[Atak_Snajpera]

Some tips from me.
1) Make sure you have been fully updated and ALL your remote PC have latest version of EncodingServer.exe running
https://i.imgsafe.org/ac/ac34cb063c.png
2) Start with new fresh job

Compressed index file is stored in JOB folder as video.mkv.lwi.7z. This file is next automatically decompressed on fly to %TEMP%/encodingserverX by EncodingServer.exe. Then EncodingServer modifies cachefile="" in X.avs file with proper path to extracted index file.
I did this to save few seconds on my slow LAN100/Wi-FI N network (real transfer is only ~10MiB/s). If Index file is 30MiB then I save 3s from starting procedure. In order to save few extra seconds I also compressed ffmpeg.exe with UPX (20MiB vs 60MiB).

[byteshare]

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.
I think you misunderstood me. I deal with the subs and audio outside of RipBot (another application) and then mux it all with a back to the encoded file from RipBot.

[byteshare]

I think you may have misunderstood my problem. The issue I was referring to are with the encoded output file.
Encoding speed seems a little slower but the biggest problem is when I play back a file that was encoded with 1.25 using MDegrain2. The first 10-20 mins play back OK but then it plays at roughly 2fps. The audio is not affected and continues to play correctly.
I have tried the same source files on 1.24.1 and there is no problem so I believe it has something to do with LSmash.

The other big problem since 1.25 is that it takes roughly 2 minutes to auto crop. Generating a new preview frame also takes at least 1 minute. If I do exactly the same thing with 1.24.1 it crops in about 3-4 seconds.

It would be useful to know if anyone else has these issues. I've never had any serious issues with auto updates in the past, but this is the first time I'm going to have to ignore the latest version as it's virtually unusable in it's current form.
1.24.1 still works perfectly for me.

I've been using RipBot since 2012 and I think it's fantastic but the latest update seems totally broken to me.

Anyone else experiencing cropping speed problems and MDegrain2 problems with v1.25?

I tested a VC-1 source and it was perfect but AVC or MPG2 cannot be encoded with MDegrain2 since the last update.

I'm happy to accept there may be a problem with my specific installation but 1.24 works perfectly.
Is there anything else I should do after the auto update has applied 1.25?

Very simple avs file

x = ImageSource("testchart1.jpg", 0, 0, fps=24, use_DevIL = true, info=false, pixel_type = "RGB48")
x=ConvertToPlanarRGB(x)
x = z_ConvertFormat(x,resample_filter="bicubic", pixel_type="RGBPS", colorspace_op="rgb:srgb:709:f=>rgb:709:709:f")
x=ConvertToYV12(x)
x = Loop(x,120)
x

is added to RipBot264. It goes to

and never comes back. Windows10, RipBot 1.25.0 with all updates done. AVSMeter processes file without problems.
Problem is not important for me. Just FYI.


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

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.


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?

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.


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)


Has anyone else tried MDegrain2 since the update to LSmash? On my PC, the encoded output is OK for the first few minutes and then it becomes a slideshow of about 2fps.

Quoted all of that since it seems some have not updated RipBot since the 1.25 update. If your LSmash files are not being stored in the job folder and you're not seeing .7z files for LSmash you need to update.
-Close RipBot Open, wait for the update to download files, close, reopen and the update will be installed. You might need to do this more than once if you didn't wait long enough.

Once you're on the most recent update you should then see if this fixed any of your issues.
-Sidenote. It would be helpful to change the point releases with these updates such as 1.25.xx, ie 1.25.02 or something

I did some testing in between 1.25 and the most recent update:
https://forum.doom9.org/showthread.php?p=1881866#post1881866
I'll need to do more testing myself to see if:
-Any of the filter combination issues I was having got fixed
-Extracting a frame is faster
-Auto Crop is faster
-See any weird frames jumping around (but audio in sync when it stops) on some files when using QTGMC that I hadn't seen until LSmash.

[ReinerSchweinlin]

I think you misunderstood me. I deal with the subs and audio outside of RipBot (another application) and then mux it all with a back to the encoded file from RipBot.
Yes, that was perfectly clear :) Thanx for the offer! For now I will first deal with those files having only one language - maybe Ripbot will be able to handle it in the future - if not, I will gladly come back to your offer.

@Atak
Thanx. Of course, everything is up to date :) At least a few hours ago. Started ripbot on every machine three times, waited 5 minutes in between to fully catch all updates - then started to investigate..

I think I found the issue of some machines doing very slow "indexing" mentioned above:

Close the encoding server windows (which is displaying the "indexing" procedure from 0 to 100%) - this did the trick for me - all machines now only take some seconds - the slower ones having the lowest cpu/bandwith... Machines which took minutes before now are starting after a few seconds..

Nice :)

So it seems the screen-output of ther encoding server window is causing this?

[byteshare]

Thanx. Of course, everything is up to date :) At least a few hours ago. Started ripbot on every machine three times, waited 5 minutes in between to fully catch all updates - then started to investigate..
Core should be Version: 2019.08.17
With the above version:
-Extracting a frame is faster
-Auto Crop is faster

Still need to test:
-Any of the filter combination issues I was having got fixed
-See any weird frames jumping around (but audio in sync when it stops) on some files when using QTGMC that I hadn't seen until LSmash.

[ReinerSchweinlin]

@byteshare
Yes, we are on the same page, ah version :)

Did some more testing - while encoding some old anime, I noticed this:

source video (resized to fit width of the target for better comparison)

https://forum.doom9.org/attachment.php?attachmentid=16946&stc=1&d=1566241893
encoded video (q22, slow, no filter, resized to match 720p, HEVC, 10 Bit)
https://forum.doom9.org/attachment.php?attachmentid=16945&stc=1&d=1566241893

Its not exactly the same frame, but that doesn´t matter..

Notice the 1 pixel dots between the soft noise in the picture - and in the middle of the white "snake-like" thing...

These artefacts seem to come from resizing, I have seen them quite a lot when encoding animes..

[byteshare]

@byteshare
Yes, we are on the same page, ah version :)

Did some more testing - while encoding some old anime, I noticed this:

source video (resized to fit width of the target for better comparison)

https://forum.doom9.org/attachment.php?attachmentid=16946&stc=1&d=1566241893
encoded video (q22, slow, no filter, resized to match 720p, HEVC, 10 Bit)
https://forum.doom9.org/attachment.php?attachmentid=16945&stc=1&d=1566241893

Its not exactly the same frame, but that doesn´t matter..

Notice the 1 pixel dots between the soft noise in the picture - and in the middle of the white "snake-like" thing...

These artefacts seem to come from resizing, I have seen them quite a lot when encoding animes..

Link the images from an image hosting site rather than uploading directly to this forum, such as Imgur.com

That said what are you using to resize the video? Have you tried: nnedi3_resize16
Also, are you using other filters?

[slalom]

Some tips from me.
1) Make sure you have been fully updated and ALL your remote PC have latest version of EncodingServer.exe running
https://i.imgsafe.org/ac/ac34cb063c.png
2) Start with new fresh job

Compressed index file is stored in JOB folder as video.mkv.lwi.7z. This file is next automatically decompressed on fly to %TEMP%/encodingserverX by EncodingServer.exe. Then EncodingServer modifies cachefile="" in X.avs file with proper path to extracted index file.
I did this to save few seconds on my slow LAN100/Wi-FI N network (real transfer is only ~10MiB/s). If Index file is 30MiB then I save 3s from starting procedure. In order to save few extra seconds I also compressed ffmpeg.exe with UPX (20MiB vs 60MiB).
I downloaded and extracted the files from the first page
I ran that to update to the latest files, checked the files with yours
I removed all jobs from previous version
I copied the updated folder everywere and added 5 jobs

Same thing, massive network usage

[BLKMGK]

Some tips from me.
1) Make sure you have been fully updated and ALL your remote PC have latest version of EncodingServer.exe running
https://i.imgsafe.org/ac/ac34cb063c.png
2) Start with new fresh job
<snip>

started with a fresh job, all CRC are correct, i see indexes being built on each client after each block. i'm currently only running 2x clients with remote access. I'm not sure what to try, these files are small and arent using filters. In 8 hours i processed 4 30min long 720p video that would normally process in under 3mins each :scared:

ill try a fresh install when i can lay hands kn the boxes in person, happy to provide anything to troubleshoot though. Still would love to solve my GPU issue filtering too!

[brumsky]

I made sure all CRCs matched on both of my machines.

I am still getting high network usage and now the encoding server shows it is creating the index file. Here is print out of it - if it helps.

https://pastebin.com/WB2ACdfg

thoughts??

[FuzzyNutz]

Quoted all of that since it seems some have not updated RipBot since the 1.25 update. If your LSmash files are not being stored in the job folder and you're not seeing .7z files for LSmash you need to update.
-Close RipBot Open, wait for the update to download files, close, reopen and the update will be installed. You might need to do this more than once if you didn't wait long enough.

Once you're on the most recent update you should then see if this fixed any of your issues.
-Sidenote. It would be helpful to change the point releases with these updates such as 1.25.xx, ie 1.25.02 or something

I did some testing in between 1.25 and the most recent update:
https://forum.doom9.org/showthread.php?p=1881866#post1881866
I'll need to do more testing myself to see if:
-Any of the filter combination issues I was having got fixed
-Extracting a frame is faster
-Auto Crop is faster
-See any weird frames jumping around (but audio in sync when it stops) on some files when using QTGMC that I hadn't seen until LSmash.

RipBot264 updated today, yet it's still producing videos with flickering frames or "frames jumping around".

[BLKMGK]

I've erased everything, dropped back to v1.24, and turned off auto-updating for now :( It seems like others are experiencing the same issues with index building I was so I'll wait a bit, hopefully address filtering via GPU not working on clients (for me) later. I suspect the fix won't be super difficult to solve the indexing but I've got a stack of videos waiting for me and cannot proceed at such a slow pace...

[userx]

Hello
After last update I'm not able to start a DE job. On local and remote machine EncodingServer runs into
Encoding started...
""\\USERX-MASTER\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\USERX-MASTER\RipBot264temp\job1\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | "\\USERX-MASTER\Ripbot264temp\tools\x264\x264_x64.exe" --seek 0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --opencl --opencl-device 0 --opencl-clbin "C:\Users\UserX\AppData\Local\Temp\x264_lookahead_1.clbin" --pass 1 --bitrate 3000 --stats "\\USERX-MASTER\RipBot264temp\job1\Chunks\1.stats" --fps 24000/1001 --force-cfr --min-keyint 24 --keyint 240 --frames 1440 --sar 1:1 --level 4.1 --aud --nal-hrd vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --b-pyramid none --ref 5 --stdin y4m --output NUL -"
y4m [error]: bad sequence header magic
x264 [error]: could not open input file


Has anybody an idea to fix it?

[byteshare]

RipBot264 updated today, yet it's still producing videos with flickering frames or "frames jumping around".
Are you using filters? I've seen the issue with QTGMC.
I'm not having that issue with AVC/HEVC source either without filters or with LSFmod or FastLineDarkenMod.
I need to test with more filters besides QTGMC.
I've erased everything, dropped back to v1.24, and turned off auto-updating for now :( It seems like others are experiencing the same issues with index building I was so I'll wait a bit, hopefully address filtering via GPU not working on clients (for me) later. I suspect the fix won't be super difficult to solve the indexing but I've got a stack of videos waiting for me and cannot proceed at such a slow pace...
I'm not having the issue...so maybe something more specific to the default startup commands for the encoding servers?
I'm using:
/port 1000 /minimize /priority low /restart-if-no-progress 8

[byteshare]

Hello
After last update I'm not able to start a DE job. On local and remote machine EncodingServer runs into
Encoding started...
""\\USERX-MASTER\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i
"\\USERX-MASTER\RipBot264temp\job1\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - |
"\\USERX-MASTER\Ripbot264temp\tools\x264\x264_x64.exe" --seek 0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --opencl --opencl-device 0 --opencl-clbin
"C:\Users\UserX\AppData\Local\Temp\x264_lookahead_1.clbin" --pass 1 --bitrate 3000
--stats "\\USERX-MASTER\RipBot264temp\job1\Chunks\1.stats" --fps 24000/1001
--force-cfr --min-keyint 24 --keyint 240 --frames 1440 --sar 1:1 --level 4.1 --aud
--nal-hrd vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --b-pyramid none --ref 5
--stdin y4m --output NUL -"
y4m [error]: bad sequence header magic
x264 [error]: could not open input file


Has anybody an idea to fix it?
Are you able to browse to the share and see the file? Could be an issue with the share.

[ReinerSchweinlin]

Link the images from an image hosting site rather than uploading directly to this forum, such as Imgur.com

That said what are you using to resize the video? Have you tried: nnedi3_resize16
Also, are you using other filters?
thanx for your reply!

I´d rather leave them in the forum - external Image hosting tends to ditch pictures after a while - several older threads are almost unusable because people put the images on imageshack - now they are gone...

Or is there a particular reason why it´s not recommended to save them directly in the forum?

I used the default resize funktion in Ripbot. Looking at the Avisynthscript, it is spline resize - I am not at the pc right now, so I´d have to check exactly, but I think I remember it was spline36, using some plugin for multihtreading.... The default one.. didn´t change anything. no custom scripts.

No, no filters, just resizing.

[Atak_Snajpera]

thanx for your reply!

I´d rather leave them in the forum - external Image hosting tends to ditch pictures after a while - several older threads are almost unusable because people put the images on imageshack - now they are gone...

Or is there a particular reason why it´s not recommended to save them directly in the forum?

I used the default resize funktion in Ripbot. Looking at the Avisynthscript, it is spline resize - I am not at the pc right now, so I´d have to check exactly, but I think I remember it was spline36, using some plugin for multihtreading.... The default one.. didn´t change anything. no custom scripts.

No, no filters, just resizing.

Your post will be forgoten because approval may take weeks.

[BLKMGK]

<snip>

I'm not having the issue...so maybe something more specific to the default startup commands for the encoding servers?
I'm using:
/port 1000 /minimize /priority low /restart-if-no-progress 8

I don't modify the commandline for launch at all. I do use port 1000, low priority, and for restart I use the GUI buttons from the encoding client but generally leave restart alone except when I'm encoding something with KNLMeansCL since this only ever encodes blocks on my host machine and not clients. At least two clients have OpenCL1.2 capable cards installed and configured but reject blocks anyway. The videos encode on those machines standalone fine though :confused:

For now I'm back in business with the older client. When the current round of jobs is completed I'll backup my files and attempt again with a newly updated client. I've got an AMD client offline right now I'll need to twiddle anyway so that will be a good chance to try it.

[FuzzyNutz]

Are you using filters? I've seen the issue with QTGMC.
I'm not having that issue with AVC/HEVC source either without filters or with LSFmod or FastLineDarkenMod.
I need to test with more filters besides QTGMC.


No filters. The occurrences can make up less than 1% of a movie's total timeline. Unless you've watched every second of every video you've produced, you can't be certain it's not happening to you, too.

[duffbeer]

Please can we get rid of LSmash. It's causing sooooo many problems. Nothing wrong before the update.

[byteshare]

I don't modify the commandline for launch at all. I do use port 1000, low priority, and for restart I use the GUI buttons from the encoding client but generally leave restart alone except when I'm encoding something with KNLMeansCL since this only ever encodes blocks on my host machine and not clients. At least two clients have OpenCL1.2 capable cards installed and configured but reject blocks anyway. The videos encode on those machines standalone fine though :confused:
If you have time please consider testing since if the dev doesn't get help testing on other systems they won't be able to fix problems they can't find. For example, I'm not having those issues so I couldn't give the dev feedback.

No filters. The occurrences can make up less than 1% of a movie's total timeline. Unless you've watched every second of every video you've produced, you can't be certain it's not happening to you, too.
Fair, of the 12+ encodes I've watched completely (different sources) and the ~100 or so I've skipped through I haven't seen an issue like that. I did find a source that had the audio/video out of sync but muxing in the time codes fixed that.

Please can we get rid of LSmash. It's causing sooooo many problems. Nothing wrong before the update.
It was to fix some issues with AC1 I think but other programs like staxrip uses lsmash so it isn't an issue by its self. Personally, all of my initial issues have been ironed out.

[stax76]

It was to fix some issues with AC1 I think but other programs like staxrip uses lsmash so it isn't an issue by its self. Personally, all of my initial issues have been ironed out.

StaxRip use this defaults:

If Check(AviSynthFilterPreferences, "AviSynth Source Filter Preferences", 3) Then
AviSynthFilterPreferences = New StringPairList
AviSynthFilterPreferences.Add("default", "FFVideoSource")
AviSynthFilterPreferences.Add("264 h264 avc", "LWLibavVideoSource")
AviSynthFilterPreferences.Add("265 h265 hevc hvc", "LWLibavVideoSource")
AviSynthFilterPreferences.Add("d2v", "MPEG2Source")
AviSynthFilterPreferences.Add("dgi", "DGSource")
AviSynthFilterPreferences.Add("dgim", "DGSourceIM")
AviSynthFilterPreferences.Add("mp4 m4v mov", "LSMASHVideoSource")
AviSynthFilterPreferences.Add("ts m2ts mts m2t", "LWLibavVideoSource")
AviSynthFilterPreferences.Add("wmv", "DSS2")
AviSynthFilterPreferences.Add("vdr", "AviSource")
End If

If Check(VapourSynthFilterPreferences, "VapourSynth Source Filter Preference", 5) Then
VapourSynthFilterPreferences = New StringPairList
VapourSynthFilterPreferences.Add("default", "ffms2")
VapourSynthFilterPreferences.Add("264 h264 avc", "LWLibavSource")
VapourSynthFilterPreferences.Add("265 h265 hevc hvc", "LWLibavSource")
VapourSynthFilterPreferences.Add("avs vdr", "AVISource")
VapourSynthFilterPreferences.Add("mp4 m4v mov", "LibavSMASHSource")
VapourSynthFilterPreferences.Add("ts m2ts mts m2t", "LWLibavSource")
VapourSynthFilterPreferences.Add("d2v", "d2vsource")
VapourSynthFilterPreferences.Add("dgi", "DGSource")
End If

The default for mkv is still ffms2!

[userx]

Are you able to browse to the share and see the file? Could be an issue with the share.

After last update it seems to work again but EServer take looooong time to create lwi file.
Before this changes, the encoding would have been finished in the meantime.
My setup consists of 5 local server and 3 remote server. On both machines the CPU isn't on full load (~50%) during 5 simultan lwi-jobs. It looks like this changes significant slows down the whole process. 1h45 instead of ~35 min

[ReinerSchweinlin]

Your post will be forgoten because approval may take weeks.
ah ok, thank you, that makes sense. When I posted them, I was able to see them, so I didn't notice. Will put them somewhere "safe" externaly...

[ReinerSchweinlin]

After last update it seems to work again but EServer take looooong time to create lwi file.
Before this changes, the encoding would have been finished in the meantime.
My setup consists of 5 local server and 3 remote server. On both machines the CPU isn't on full load (~50%) during 5 simultan lwi-jobs. It looks like this changes significant slows down the whole process.

Have you tried closing the server window while the LWI file is created?

[userx]

Have you tried closing the server window while the LWI file is created?

close=kill server or minimize? What would be the difference?
without server the jop won't run. (?)

[ReinerSchweinlin]

close=kill server or minimize? What would be the difference?
without server the jop won't run. (?)
ah yes.. minimize :)

[byteshare]

StaxRip use this defaults:

If Check(AviSynthFilterPreferences, "AviSynth Source Filter Preferences", 3) Then
AviSynthFilterPreferences = New StringPairList
AviSynthFilterPreferences.Add("default", "FFVideoSource")
AviSynthFilterPreferences.Add("264 h264 avc", "LWLibavVideoSource")
AviSynthFilterPreferences.Add("265 h265 hevc hvc", "LWLibavVideoSource")
AviSynthFilterPreferences.Add("d2v", "MPEG2Source")
AviSynthFilterPreferences.Add("dgi", "DGSource")
AviSynthFilterPreferences.Add("dgim", "DGSourceIM")
AviSynthFilterPreferences.Add("mp4 m4v mov", "LSMASHVideoSource")
AviSynthFilterPreferences.Add("ts m2ts mts m2t", "LWLibavVideoSource")
AviSynthFilterPreferences.Add("wmv", "DSS2")
AviSynthFilterPreferences.Add("vdr", "AviSource")
End If
Nice find but I wonder why they only use LSmash with mp4, m4v, and mov?

After last update it seems to work again but EServer take looooong time to create lwi file.
Before this changes, the encoding would have been finished in the meantime.
My setup consists of 5 local server and 3 remote server. On both machines the CPU isn't on full load (~50%) during 5 simultan lwi-jobs. It looks like this changes significant slows down the whole process. 1h45 instead of ~35 min
Have you tried updating and clearing out your temp jobs and re-adding jobs?
I haven't noticed that issue with the most recent version. Does it only happen when the chunks are being created when you first start a new job and once it gets going it is fine?
I keep my encoding server window minimized but haven't seen that issue.
I just tried starting a fresh new job and now I see what you're saying...I guess I haven't monitored that part as closely.

[BLKMGK]

<snip>
I just tried starting a fresh new job and now I see what you're saying...I guess I haven't monitored that part as closely.

Does it create a new index after every chunk? On each client? I'll try it again here after a few movies have been completed (single machine only since I'm filtering) and the deck is cleared but index creation previous killed really my speeds.:eek: A single creation of an index is no biggie and expected but not over and over...

[userx]

ah yes.. minimize :)

It doesn't differ. The lwi-process is pretty slow. Why it's switch to this mechanism? What are the benefits? Is there a possibility to switch back to the 'old' bahaviour?

Nice find but I wonder why they only use LSmash with mp4, m4v, and mov?
Have you tried updating and clearing out your temp jobs and re-adding jobs?
I haven't noticed that issue with the most recent version. Does it only happen when the chunks are being created when you first start a new job and once it gets going it is fine?
I keep my encoding server window minimized but haven't seen that issue.
I just tried starting a fresh new job and now I see what you're saying...I guess I haven't monitored that part as closely.

It's a fresh created Job, so I don't have re-added and cleaned someting.
Every chunk has a (slow) lwi-job before it starts, which slows the whole process.

https://i.imgur.com/LPT6KU6.png
https://i.imgur.com/cPAiAsN.png

[byteshare]

Does it create a new index after every chunk? On each client? I'll try it again here after a few movies have been completed (single machine only since I'm filtering) and the deck is cleared but index creation previous killed really my speeds.:eek: A single creation of an index is no biggie and expected but not over and over...

Yeah, on each chunk

It doesn't differ. The lwi-process is pretty slow. Why it's switch to this mechanism? What are the benefits? Is there a possibility to switch back to the 'old' bahaviour?

It's a fresh created Job, so I don't have re-added and cleaned someting.
Every chunk has a (slow) lwi-job before it starts, which slows the whole process.

the LSmash has some benefits but I thought they were only for a specific codec and not x265/x264

[LigH]

Please can we get rid of LSmash. It's causing sooooo many problems. Nothing wrong before the update.

No. :p Problems are to be solved, not to despair of them. :sly: Once solved, you will love the result. :cool:

[LigH]

Nice find but I wonder why they only use LSmash with mp4, m4v, and mov?

LSMASH*Source works only with containers compatible to the ISO base media file format (https://en.wikipedia.org/wiki/ISO_base_media_file_format), but relies on their internal keyframe index chunk and doesn't create a separate index file.

For all other containers, you need LwLibav*Source which is much more flexible, but creates an additional index file to be able.

[byteshare]

LSMASH*Source works only with containers compatible to the ISO base media file format (https://en.wikipedia.org/wiki/ISO_base_media_file_format), but relies on their internal keyframe index chunk and doesn't create a separate index file.

For all other containers, you need LwLibav*Source which is much more flexible, but creates an additional index file to be able.
Ah, okay. If we're already creating a .lwi from the source video (the whole thing) is there any reason we should need to create another .lwi file for chunks of the same video rather than just use the main .lwi file at different points in the file?
Or is there a reason there is an advantage to doing it that way?
Just thinking if we have to create individual .lwi files for DE mode might as well skip that until we're encoding if the source.lwi file isn't going to be used.

No. :p Problems are to be solved, not to despair of them. :sly: Once solved, you will love the result. :cool:
Good point

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.
I've been looking at this more (batching more than 1 audio stream & more than 1 sub).
It would be nice if the batch mode could handle more than one stream because I was looking to simplify my process rather than having so many steps.
-Main reason for muxing subs from source with a batch file is so I can keep the MKV title info but mostly for anime since that tends to have the most important context info.
-I wouldn't mind using the internal RipBot audio encoders for items with more than one audio track if they were accounted for. I was realizing I was doing all of my sources' audio externally just for consistency for when I need to run a batch file to mux things back together.

[george84]

RipBot264 newest version on Windows 10.

When I exit RipBot264 then it still exists in list of task manager. I have to abort it to make a restart.

When I want to Minimize, then I can only do so in main menu at upper left of window. That means I can click Minimize and it disappears. It still exists in task manager but with CTRL/Tab I can't get it back.

I have a 4K screen.

[byteshare]

RipBot264 newest version on Windows 10.

When I exit RipBot264 then it still exists in list of task manager. I have to abort it to make a restart.

When I want to Minimize, then I can only do so in main menu at upper left of window. That means I can click Minimize and it disappears. It still exists in task manager but with CTRL/Tab I can't get it back.

I have a 4K screen.

Are you running Logitech Software. See post here: https://forum.doom9.org/showpost.php?p=1879997&postcount=17029

Alternatively update Logitech Software here: https://forum.doom9.org/showpost.php?p=1880045&postcount=17034

Hope this helps..