View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
ReinerSchweinlin
9th August 2019, 19:51
Hi, is is possible to modify the encoding server to work on a separate network?. specifically I have a few idle pc's that are offsite and would like to utilize them for encoding. We dont want to create a VPN. Is this a request that could be in the future?. RipBot264 works great with the few pc's that we have on the same Lan ??, a few more would definitely help
Thatīs exactly what I do now, it already works with ripbot.
If you have stable connections with static IP, youīre all set.
Home-DSL or similar resets itīs IP adress within 24h in most countries, so youīd have to whip up some dyndns stuff... If the connection brakes down while encoding, in 80% the encode gets stuck, so you have to monitor everything alle the time.
For VPN, you could use almost anything you can think of, ripbot doesnīt care.... I tried hamachi, AVM-Fritzbox VPN, etc....
slalom
9th August 2019, 20:45
Does the encoding server start and stop?
Or do the chunks get made and the chunk list shows and then nothing happens after that?
Any logs?
I had an issue with starting a job, checking a few chunks but not liking the output so I changed the job, but then the first few chunks weren't over written and the job would finish but then started all over again. It was strange. I manually (right click job > clear) cleared the DE progress and it worked. So, anything like that?
Removed the audio and added the file
Job starts to encode
I have three other files to "mute" and add them too
I'll do my job eventually
byteshare
9th August 2019, 22:59
Removed the audio and added the file
Job starts to encode
I have three other files to "mute" and add them too
I'll do my job eventually
I have that issue from time to time where I need to strip the file of everything but the video or it doesn't add to RipBot.
rayers1060
10th August 2019, 00:52
You can do it with a VPN for sure, but if you don't want a VPN have you tried setting public IP addresses for the servers?
That would seem like a security risk IMO.
I must be missing something... The easy part is getting Encoding Client to connect with the remote server (I simply add static address and the port to Distributed Encoding server list) - remote encoding server reports "Client established connection with server" so all is good connecting to server at remote location( remote router port forward is set and working) . once the initial connection is made, the problem is the encoding server by default is looking for a local address of the Encoding Client - see attachment. The fix would be to edit the server with new distinct address & port back to Encoding client location. Or another option is address translation on the remote location Mikrotik Router ( I have yet to try)
Is there another way to get encoding server pointed to another address/port?
https://i.imgur.com/yZAGV4Z.png
byteshare
10th August 2019, 01:22
see attachment
Please try linking the image from an image hosting site such as imgur.com. Attaching photos is not the best method here.
Atak_Snajpera
10th August 2019, 09:55
I must be missing something... The easy part is getting Encoding Client to connect with the remote server (I simply add static address and the port to Distributed Encoding server list) - remote encoding server reports "Client established connection with server" so all is good connecting to server at remote location( remote router port forward is set and working) . once the initial connection is made, the problem is the encoding server by default is looking for a local address of the Encoding Client - see attachment. The fix would be to edit the server with new distinct address & port back to Encoding client location. Or another option is address translation on the remote location Mikrotik Router ( I have yet to try)
Is there another way to get encoding server pointed to another address/port?
https://i.imgur.com/yZAGV4Z.png
Btw. Do you have Access to shared folder from that machine?
userx
10th August 2019, 11:16
@Atak_Snajpera
Have you any recomendation on this (https://forum.doom9.org/showthread.php?p=1881341#post1881341)?
Atak_Snajpera
10th August 2019, 11:49
@Atak_Snajpera
Have you any recomendation on this (https://forum.doom9.org/showthread.php?p=1881341#post1881341)?
1) Outdated drivers
2) No enough VRAM (1GiB)
slalom
10th August 2019, 12:12
I have that issue from time to time where I need to strip the file of everything but the video or it doesn't add to RipBot.
Me too, but just loosing the audio will sufice
rayers1060
10th August 2019, 18:42
Btw. Do you have Access to shared folder from that machine?
I just realized shared folder is not accessible after my initial post. I was able to get address translation from remote location to work correctly. Currently both Encoding server and encoding client can correctly communicate commands between sites. The issue is the shared folder., The Encoding server cannot get chunks - see screenshot. I have other Encoding servers on the Local LAN and all is working well. The remote site cannot connect to the shared folder where the encoding client resides - Any ideas on making shared folder with transparent access??
https://imgur.com/mh6Cc1K
Atak_Snajpera
10th August 2019, 18:51
That's why people say to use VPN. You literally have to be a part of that LAN.
https://forums.tomshardware.com/threads/accessing-local-lan-via-internet.3389046/
userx
11th August 2019, 11:49
1) outdated drivers
2) no enough vram (1gib)
VRAM: 2GB,
Driver:07/2019
As mentioned the second pass is working as desired.
https://i.imgur.com/UhR1G1M.png
ReinerSchweinlin
11th August 2019, 15:14
How can I keep all audio when doing batches? Only one audio stream is copied/encoded.
Viper714
11th August 2019, 16:24
Okay Atak, All the files are uploaded in the same location. Please let me know if you need additional files....
Thanks again!
Atak,
Sorry for the late reply. Been away on business and just got back this past Friday.
I noticed that 1.25 was released. I tried that one and the first thing I noticed on one of my machines, it reported that Haali Splitter was not installed. Strange as it was always installed. Either way i installed it via the link RipBot provided.
I encoded:
The Chronicles of Riddick - Successful
The Chronicles of Narnia Prince Caspian - Successful
Chain Reaction - Successful
So far those three movies look great and are in sync. I will continue with the other movies and let you know. So far it appears promising and you fixed the issue. Curious what you may have changed?
Either way, thank you for your hard work and this great program!!!!
kempodragon
11th August 2019, 19:05
After Ripbot updated itself to the latest version, I did a test on several known files, and got this error: https://imgur.com/a/eKnHn1L . It only shows up on the server screen, not the log, which only says it could not open the file. The previous version encoded them perfectly, so I can only assume this is some sort of bug. I tried to download the newest version and do a fresh install, but the link on the page still only points to version 1.25.
byteshare
12th August 2019, 16:18
How can I keep all audio when doing batches? Only one audio stream is copied/encoded.
In batch mode you've tried setting it to the profile "x.x C O P Y S T R E A M"?
I usually run a batch afterwards that muxes in subs from the source to keep the MKV titles, and the encoded audio from HandBrake since an old version handles audio the way I like, so I might not be the most help.
After Ripbot updated itself to the latest version, I did a test on several known files, and got this error: https://imgur.com/a/eKnHn1L . It only shows up on the server screen, not the log, which only says it could not open the file. The previous version encoded them perfectly, so I can only assume this is some sort of bug. I tried to download the newest version and do a fresh install, but the link on the page still only points to version 1.25.
Try removing the job and recreating it since the update.
Also, try cropping the image :D Or WinKey + Shift + S to do a snip and select only the area you want for a screen grab.
Viper714
13th August 2019, 05:49
I am curious as to what these red indicators are.
https://i.imgur.com/RLzjto9.jpg
I ask because I am seeing some strange actions during encoding. Some chunks are stalling before even starting. It seems to eventually start but it takes about a minute or more. I have six servers active (3 different machines) and four servers are stuck on "starting..." Does not always happen but it is intermittent.
Any ideas??
LigH
13th August 2019, 07:36
No clue, just guessing ... depending on the source filter: An indexing phase?
Atak_Snajpera
13th August 2019, 10:11
Red = normal priority
Green = below normal
Blue = low priority
kempodragon
13th August 2019, 14:04
Byteshare, I already tried removing the job several times with no luck. Imgur.com didn't complain about the file dimensions or size so I decided to be lazy and just post whole screen. Similar problems have happened occasionally after an update so I find that grabbing the latest version and doing a clean install usually solves the problem. The link still only points to 1.24 so I'll have to wait until Atak updates the link. What I find a little strange is that the error message only appears on the server screen, it doesn't get recorded in the log.
Atak_Snajpera
13th August 2019, 16:20
I ask because I am seeing some strange actions during encoding. Some chunks are stalling before even starting. It seems to eventually start but it takes about a minute or more. I have six servers active (3 different machines) and four servers are stuck on "starting..." Does not always happen but it is intermittent.
Any ideas??
Take a look here https://forum.doom9.org/showthread.php?p=1881800#post1881800
Viper714
13th August 2019, 16:36
Take a look here https://forum.doom9.org/showthread.php?p=1881800#post1881800
Thanks Atak. Wow, quite a bit involved to encoding. Hopefully the compression method you recommend will be implemented.
:thanks:
byteshare
13th August 2019, 16:40
Byteshare, I already tried removing the job several times with no luck. Imgur.com didn't complain about the file dimensions or size so I decided to be lazy and just post whole screen. Similar problems have happened occasionally after an update so I find that grabbing the latest version and doing a clean install usually solves the problem. The link still only points to 1.24 so I'll have to wait until Atak updates the link. What I find a little strange is that the error message only appears on the server screen, it doesn't get recorded in the log.
Just open RipBot let it load the updated files, then close and reopen and it will install the updates.
-Do you get that index error with the same file on an older version of RipBot?
-It looks like there is either an issue accessing that file (can you confirm it is there?) or something might be up with the video.
-Try remuxing the file with only the video part and loading that.
duffbeer
13th August 2019, 17:41
Encoding with MDegrain2 seems to be broken since the last major update. The first few minutes are OK but then it becomes a slideshow of about 2 frames per second. I've tried a few different sources (AVC, VC-1, MPG2) but they all do the same thing.
Seems to be since the change to LSmash.
Atak_Snajpera
13th August 2019, 18:24
Encoding with MDegrain2 seems to be broken since the last major update. The first few minutes are OK but then it becomes a slideshow of about 2 frames per second. I've tried a few different sources (AVC, VC-1, MPG2) but they all do the same thing.
Seems to be since the change to LSmash.
That's funny because VC-1 is not being decoded by LSmash but by FFMS2 like in previous version. MDegrain2 has also not been updated.
userx
13th August 2019, 19:22
@Atak_Snajpera
Additional to this (https://forum.doom9.org/showthread.php?p=1881341#post1881341) issue I maybe have found the cause.
When I start a Job on the remote machine (local job), I run into the same problem if i switch 'x264 OpenCL acceleration' to Capeverde but runs without problems if i switch to None.
On a remote-job Encoding Server doesn't consider the None-setting in the 'RipBot264.ini' and want to use OpenCL accelleration.
This issue only occures in 1st-pass. 2nd-pass seems to run with OpenCL-Capeverde.
Is there an other possibility to tell Encoding Server not to use it?
Atak_Snajpera
13th August 2019, 19:28
Yes. Just run Encoding server with wrong device id
Example
EncodingServer.exe /x264-opencl-device-id 9
or you can just refresh job by clicking EDIT and Done
duffbeer
13th August 2019, 19:34
That's funny because VC-1 is not being decoded by LSmash but by FFMS2 like in previous version. MDegrain2 has also not been updated.
Sorry - my mistake. My test sources were AVC and MPG2 but I didn't try VC-1 yet.
I can send samples if it would help.
Atak_Snajpera
13th August 2019, 19:34
Why not?
duffbeer
13th August 2019, 19:38
Why not?
Not had time yet. I tried the same sources encoded with v1.24.1 and they were fine. I can test VC-1 if you want me to?
userx
13th August 2019, 19:45
/x264-opencl-device-id 9
Hero of the day!!
No idea why OpenCL isn't working but that solves my problem.
:thanks:
byteshare
14th August 2019, 05:20
Encoding with MDegrain2 seems to be broken since the last major update. The first few minutes are OK but then it becomes a slideshow of about 2 frames per second. I've tried a few different sources (AVC, VC-1, MPG2) but they all do the same thing.
Seems to be since the change to LSmash.
I've had similar results with AVC/HEVC inputs to 10bit x265 using AVISynth filters such as QTGMC and Megrain2. Without AVIsynth filters speeds seem close enough to the same that I can't tell, so I don' think it could be related to the updated x265.
Using the most recent update (including LSmash update), it seems to slow down the decoding process because extracting a frame is taking way longer when adding a job and using a lot of CPU while doing it.
--Maybe skip that step until someone clicks Edit > AviSynth? Or had Detect boarders on for cropping?
Unless something changed with FFMPEG, but I don't see an update to that since April of this year.
Another thing is I've noticed with filters my second Encoding Server on the same machine is taking way longer to start encoding than the first one, but with only one Encoding Server I'm not getting 100% CPU.
I'm not sure what I could send to help figure this out.
I tried a test with 1.24 vs fully updated 1.25 RipBot.
Same x265 version (one from the newest version of RipBot), same x265 profile, same filters for the same AVIsynth custom script.
For time used just one Encoding Server to encode the same chunk.
Custom: video=QTGMC(video,Preset="slower",FPSDivisor=2,NoiseProcess=0).ConvertBits(16).ConvertToStacked()
.SMDegrain(tr=3,thSAD=400,thSADC=150,refinemotion=false,contrasharp=true,plane=4,pel=2,
prefilter=4,Truemotion=False,chroma=true,hpad=32,vpad=32,str=2,amp=1,lsb_in=true,lsb=true,lsb_out=true)
.ConvertFromStacked().ConvertBits(8).FineDehalo().FastLineDarkenMOD4().LSFmod()(Added line breaks to keep the text from spanning too much on smaller screens.
Results:
confirmed extracting a frame was faster in 1.24
but for FPS of encoding:
1.25 0.20FPS
1.24 0.43FPS
...but, 1.24 was actually much faster than just FPS because the FPS isn't reporting correctly in 1.25 since the encoder isn't actually processing frames the whole time. It looks like the decoder stage is hanging and not passing frames to the encoder as quickly as in 1.24
--Sidenote, in 1.24 it is correctly splitting up the chunks for this file into 58 parts rather than 29 parts (but twice the number of frames roughly) and giving me the option for deinterlace drop down in the AVISynth settings.
Could the decoding slowness have something to do with the changes in the write buffer?
Another update:
So, it seems the extent of this slow down is a lot to do with the filter combintion I'm using as when I try without either SMDegrain or QTGMC the remaining filters are fine, or even when I try different settings such as prefilter 3 for SMD. If I swap SMDegrain for MD2 or Adaptive KNLmeansCL I also don't see the issue.
If I'm getting slow down without other heavy filters/settings it isn't enough to easily detect, but with 1.25 the issue with the above filters is exacerbated for one reason or another.
duffbeer
14th August 2019, 09:27
I've had similar results with AVC/HEVC inputs to 10bit x265 using AVISynth filters such as QTGMC and Megrain2. Without AVIsynth filters speeds seem close enough to the same that I can't tell, so I don' think it could be related to the updated x265.
Using the most recent update (including LSmash update), it seems to slow down the decoding process because extracting a frame is taking way longer when adding a job and using a lot of CPU while doing it.
--Maybe skip that step until someone clicks Edit > AviSynth? Or had Detect boarders on for cropping?
Unless something changed with FFMPEG, but I don't see an update to that since April of this year.
Another thing is I've noticed with filters my second Encoding Server on the same machine is taking way longer to start encoding than the first one, but with only one Encoding Server I'm not getting 100% CPU.
I'm not sure what I could send to help figure this out.
I tried a test with 1.24 vs fully updated 1.25 RipBot.
Same x265 version (one from the newest version of RipBot), same x265 profile, same filters for the same AVIsynth custom script.
For time used just one Encoding Server to encode the same chunk.
Custom: video=QTGMC(video,Preset="slower",FPSDivisor=2,NoiseProcess=0).ConvertBits(16).ConvertToStacked()
.SMDegrain(tr=3,thSAD=400,thSADC=150,refinemotion=false,contrasharp=true,plane=4,pel=2,
prefilter=4,Truemotion=False,chroma=true,hpad=32,vpad=32,str=2,amp=1,lsb_in=true,lsb=true,lsb_out=true)
.ConvertFromStacked().ConvertBits(8).FineDehalo().FastLineDarkenMOD4().LSFmod()(Added line breaks to keep the text from spanning too much on smaller screens.
Results:
confirmed extracting a frame was faster in 1.24
but for FPS of encoding:
1.25 0.20FPS
1.24 0.43FPS
...but, 1.24 was actually much faster than just FPS because the FPS isn't reporting correctly in 1.25 since the encoder isn't actually processing frames the whole time. It looks like the decoder stage is hanging and not passing frames to the encoder as quickly as in 1.24
--Sidenote, in 1.24 it is correctly splitting up the chunks for this file into 58 parts rather than 29 parts (but twice the number of frames roughly) and giving me the option for deinterlace drop down in the AVISynth settings.
Could the decoding slowness have something to do with the changes in the write buffer?
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.
ReinerSchweinlin
14th August 2019, 11:09
In batch mode you've tried setting it to the profile "x.x C O P Y S T R E A M"?
Thanx for your answer.
Yes, of course I did that :) And it only keeps the first audio stream in batch mode. It has always been like this since I started using RipBot. It would be lovely if RipBot could simply keep all streams when doing batches :)
ReinerSchweinlin
14th August 2019, 20:12
Thanx for your answer.
Yes, of course I did that :) And it only keeps the first audio stream in batch mode. It has always been like this since I started using RipBot. It would be lovely if RipBot could simply keep all streams when doing batches :)
I have to add: Often I donīt want to copy the streams, but encode them to something different (1. stream englisch AC3, 2. Stream japanese DTS -> both to AAC HE)... Either way, in batch mode, only the first stream is transcoded....
Ronski
14th August 2019, 20:53
Hi, I have a bit of a weird problem. I've had this happen in the past and I've simply restarted Windows and its been fine, now it does it all the time, my PC did update to v1903 of Windows 10 (64bit) tonight, so not sure if that's any relevance, I've also turned off my antivirus just in case it was that, but made no difference.
I have two encoding servers set to start with Ripbot, neither are visible in the system tray, neither can Ripbot connect to them although it does connect to the instance on my other PC, but if I open task manager they are both there in the process list, if I open another instance of EncodingServer.exe then that also appears in the process list but still not in the tray or on the desktop.
Any thoughts please?
https://live.staticflickr.com/65535/48538532156_b5157579c6_o.png (https://flic.kr/p/2gXbEy5)
Edit: Actually I think this may be something to do with Avast, I copied the encodingserver.exe to another directory and ran it, first windows firewall asked if I wanted to permit access, after permitting the encoding server opened, but then it had Avast CyberCapture above it, then promptly disappeared - I'll do some more testing. Odd thing is Avast is running on the other PC as well.
byteshare
14th August 2019, 21:33
I have to add: Often I donīt want to copy the streams, but encode them to something different (1. stream englisch AC3, 2. Stream japanese DTS -> both to AAC HE)... Either way, in batch mode, only the first stream is transcoded....
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.
duffbeer
15th August 2019, 10:34
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?
george84
15th August 2019, 10:55
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 Please Wait ... Gathering Information...
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.
Viper714
15th August 2019, 11:36
Hi, I have a bit of a weird problem. I've had this happen in the past and I've simply restarted Windows and its been fine, now it does it all the time, my PC did update to v1903 of Windows 10 (64bit) tonight, so not sure if that's any relevance, I've also turned off my antivirus just in case it was that, but made no difference.
I have two encoding servers set to start with Ripbot, neither are visible in the system tray, neither can Ripbot connect to them although it does connect to the instance on my other PC, but if I open task manager they are both there in the process list, if I open another instance of EncodingServer.exe then that also appears in the process list but still not in the tray or on the desktop.
Any thoughts please?
https://live.staticflickr.com/65535/48538532156_b5157579c6_o.png (https://flic.kr/p/2gXbEy5)
Edit: Actually I think this may be something to do with Avast, I copied the encodingserver.exe to another directory and ran it, first windows firewall asked if I wanted to permit access, after permitting the encoding server opened, but then it had Avast CyberCapture above it, then promptly disappeared - I'll do some more testing. Odd thing is Avast is running on the other PC as well.
I noticed you are running Logitech Software. See my post here (https://forum.doom9.org/showpost.php?p=1879997&postcount=17029). Hope this helps..
There is a post after mine from byteshare (Here (https://forum.doom9.org/showpost.php?p=1880045&postcount=17034)) to update to a different version of the Logitech Software as well. I haven't done that yet but plan on doing it soon. Just need to make sure that I do not loss my profiles as I have a few of them for my keyboard...
Ronski
15th August 2019, 19:38
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. :thanks:
howzz
17th August 2019, 06: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?
Atak_Snajpera
17th August 2019, 13:30
What is the size of .lwi file in job folder?
howzz
17th August 2019, 20:12
What is the size of .lwi file in job folder?
about 1.25GB
is that good or bad
howzz
17th August 2019, 21:37
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.
stax76
18th August 2019, 00:06
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.
howzz
18th August 2019, 00:23
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.
stax76
18th August 2019, 00:44
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.
howzz
18th August 2019, 00:50
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
18th August 2019, 00:58
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. :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.