View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
GZZ
31st December 2019, 13:23
@gzz
1) code which replaces text is case sensetive! You wrote e: but IT should be E: in load plugin
2) If for some reason ffmpeg.exe still sits in memory with 0 % CPU then there is special switch to restart encoding automatically
EncodingServer.exe /restart-if-no-progress
Encoding will be restarted If encodingserver detects no CPU usage for ffmpeg.exe/x26x.exe for 1 minute.
1) casesensitive on folder. :( but thanks for pointing it out.
2) thanks for the switch, is there a list of hidden switches?
Atak_Snajpera
31st December 2019, 14:34
2) settings -> distributed encoding tab -> wrench icon -> command line help
You can easily check if restarting works by suspending ffmpeg.exe/x264.exe/x265.exe in processhacker/processexplorer. After 1 minute you should get this message
https://i.postimg.cc/85FgYWBJ/Untitled-1.png
GZZ
31st December 2019, 15:33
2) settings -> distributed encoding tab -> wrench icon -> command line help
You can easily check if restarting works by suspending ffmpeg.exe/x264.exe/x265.exe in processhacker/processexplorer. After 1 minute you should get this message
https://i.postimg.cc/85FgYWBJ/Untitled-1.png
Thanks and Happy new year. :)
ImEverlasting
31st December 2019, 18:33
No, I posted it from a working build, just to help people in need.
I think the reason for it showing that I uploaded it today is, that I actually took it down, for a day or so.
Hey, you asked if anybody had a working version, and then you question it....:(
It's entirely up to you if you want to use it or not....I just know that at least 23 others have.
You're new, and I don't know you, either !!!
I know I asked, but it's me being cautious since it's not an "official" link from the original maker. I do greatly appreciate the help and will give your link a try tonight. :) :thanks:
guest
1st January 2020, 00:53
I know I asked, but it's me being cautious since it's not an "official" link from the original maker. I do greatly appreciate the help and will give your link a try tonight. :) :thanks:
My 1st post for 2020...
OK, fair enough, but seeing there isn't an "official" link to v1.25.0, this is the closest you'll get.
This IS the version I am currently using, and I'm not having any RB related issues, if you choose the 1st link on that post, the other link is an older build, but still v1.25.0.
guest
1st January 2020, 00:55
2) settings -> distributed encoding tab -> wrench icon -> command line help
You can easily check if restarting works by suspending ffmpeg.exe/x264.exe/x265.exe in processhacker/processexplorer. After 1 minute you should get this message
I'm going to test that theory....I rarely see any pop up messages on W10 & Server...only on older OS's, like W8.1 (which is the oldest I'm currently running).
edit:- have tested this on several different platforms, and indeed, it does work for me :)
guest
1st January 2020, 01:18
2) thanks for the switch, is there a list of hidden switches?
For future reference...
http://www.mediafire.com/file/yxd0wqrxix0jgzd/hidden_switches.jpg/file
guest
1st January 2020, 01:41
Atak,
Not sure if this has been suggested or asked about before...
Could this be done ?? (A bit like a Mining Rig)
If I wanted to load up a Server (don't want to do this on a Client, as I use different Clients, but use the same Servers) with multiple GPU's for certain filter encoding, what switches would be required to use them ALL ??
Would the switches only have to be on the DE Server, or some how on the Client ??
Have I answered my own question....
Using one or both "knlmeansCL-opencl-device-type GPU", and/or "knlmeansCL-opencl-device-ID 0 or 1 or 2", however they're numbered, and multiple lines, one for each device.
guest
1st January 2020, 05:57
Atak,
I have had a couple of strange drop out's today, and I'm really thinking that it a network connection problem (cable's & plug's)
Would you be so kind as to have a look at the 2 log files from 2 different servers, and see what you can see :-
http://www.mediafire.com/folder/fcqgg4c2b6qia/TCP_log_off_2_different_servers
Hint, the number in the .txt name is the line the problems seem to start.
I also had once more instance of a chunk showing "Starting" (on the Client), and on the Server, the TCP had stopped, but it was still processing.....so I let it go to completion...unfortunately it didn't actually complete that chunk, (as far as the Client was concerned) and it also didn't proceed to the next available chunk.
So I was in the process of posting this edit, and got another error..
But in the meantime, here's some more screens & tcp logs I would like you to have a look at:-
https://www.mediafire.com/file/fa55o1kjpnpm1bc/chunk_double_up_%26_tcp_log_to_suit.rar/file
And this is the error I just mentioned:-
https://www.mediafire.com/view/msggh3k101v62q2/and_a_final_error_of_the_same_job.jpg/file
another update on this last error...I re started RB for a 2nd time to finish chunk 116, and it did, and video.265 appeared...so it wasn't a waste of a 2 day encode :)
guest
2nd January 2020, 10:06
Well, we've had a little New Years surprise....from Atak.
An auto update, core (01-01-20), ES (1.17.1). Not sure there is anything else, yet.
edit:- OK, I have found a few new filters, and MT settings.
There is now reference to MDegrain1, 2 & 3 available (in the Ripbot264.ini file, & MT filters), however, I cannot for the life of me find where they are to enable them....they are not in "Custom" or "Denoise" (only MDegrain2)
I hope I'm not missing something obvious ???
And best surprise of all, there is now a v1.25.0 on page one :) (and it's the very latest build)
I must say that it would have been extra nice if it was say v1.26.0 for the new year....but hey, it's only a number :)
:thanks::thanks::thanks:
GZZ
2nd January 2020, 13:00
Well, we've had a little New Years surprise....from Atak.
An auto update, core (01-01-20), ES (1.17.1). Not sure there is anything else, yet.
edit:- OK, I have found a few new filters, and MT settings.
There is now reference to MDegrain1, 2 & 3 available (in the Ripbot264.ini file, & MT filters), however, I cannot for the life of me find where they are to enable them....they are not in "Custom" or "Denoise" (only MDegrain2)
I hope I'm not missing something obvious ???
And best surprise of all, there is now a v1.25.0 on page one :) (and it's the very latest build)
I must say that it would have been extra nice if it was say v1.26.0 for the new year....but hey, it's only a number :)
:thanks::thanks::thanks:
I agree it could be nice if the About tab under settings was updated with the newest change and a Build number or better version tracking.
The issue with the Client shutdown hangs ripbot has been fixed in this or the previous version, but it could be nice to know when it happend!
I will have a look at MDegrain when I get home.
Atak: Thanks for fixing and hope you had a good new year. :)
byteshare
2nd January 2020, 16:42
Catching up on things...
I see RipBot264 v1.25.0 Core 2020.01.01 as the most uptodate, did the stalling/timeouts get resolved by this version?
So how would you set these up a a Custom filter ??
Still need help with this? I posted something about this when trying to help Ryushin: https://forum.doom9.org/showthread.php?p=1892063#post1892063
While reading up on the discussion about turing hevc encoding vs x264/x265, I encountered the advantage of x264 veryslow mentioned by Atak over here:
https://forum.doom9.org/showthread.php?t=176889
So I started encoding tests with x264 very slow in ripbot.
I noticed, that encoding speed in ripbot differs a lot compared to hybrid:
ripbot (with 20 cores in total, using two xeons, kaby lake i5 and some others)
x264 very slow: 2 hours
x265 default: 1,3 hours
hybrid (only using the i6 Kaby lake with 4 cores)
x264 very slow: 1,1 hours
I am not sure if I am doing something wrong here´... Is it normal that x264 very slow is slower than x265 default?
I just did some more testing...
Hybrid and Handbrake encode almost as fast on the one i5 Kabylake as the whole network with Ripbot. Using the same settings (x264veryslow, no filter, no tune, no audio, simply passing through video..). I assume that there are different versions of x264 under the hood of each program, but this difference is huge. If I look at the encoding server on the i5, I have around 4 fps with ripbot, while hybrid and handbrake get up to 12fps...
What yould be causing this? I remember encoding some 1080p videos a while ago in Ripbot with x264veryslow and I had much faster fps... Running the latest Corev4 you posted above.
Have you done anymore tests? I don't see a speed difference when using x265 and filters with either DE or non-DE mode, if anything usually DE is slightly faster using a more constant 95+% CPU.
guest
3rd January 2020, 00:24
Catching up on things...
I see RipBot264 v1.25.0 Core 2020.01.01 as the most uptodate, did the stalling/timeouts get resolved by this version?
Still need help with this? I posted something about this when trying to help Ryushin: https://forum.doom9.org/showthread.php?p=1892063#post1892063
Welcome back byteshare, you have a LOT of catching up to do...
Haven't heard from you since last year, lol, your last post was #17979.
This version seems to be pretty good, there's only one question I have about it, and that hasn't been addressed yet.
(see https://forum.doom9.org/showpost.php?p=1894495&postcount=18160).
No thanks, I got the filters figured out (with some help).
guest
4th January 2020, 05:14
Hey guys,
So my first use of this build (in anger), and I could NOT get any Servers to connect to the Client...as soon as you choose what Server you want from the Client screen, it creates and error log in TCP Com's, and it looks like it's looking for the wrong port.
I have several screen shots that I hope will show what's going on..I don't know whether it's just me, or the HOT weather today, it's a baking 46° Celsius !!!!!
Anyway, here's the link:-
https://www.mediafire.com/file/7ihak9vdl67h83j/Cannot_find_chunk_.cmd_Error.7z/file
Atak_Snajpera
4th January 2020, 11:48
1) stop saying that EmcodingClient is listening at wrong ports. Everything is fine. Tcpservers on client use ports from 1001 to 1016. On other hand servers use 1000 to 16000 to avoid conflicts.
2) server can not Access that cmd file using network Path. Enter that Path in Explorer to see If shared folder is acessible.
a baking 46° Celsius !!!!!
Weather here in Poland is also weird! IT is 6C now and they predict 10C in few days. That's not normal here in January. We should have temperatures below zero and snow.
guest
4th January 2020, 12:27
1) stop saying that EmcodingClient is listening at wrong ports. Everything is fine. Tcpservers on client use ports from 1001 to 1016. On other hand servers use 1000 to 16000 to avoid conflicts.
2) server can not Access that cmd file using network Path. Enter that Path in Explorer to see If shared folder is acessible.
Fair enough, but when you get a very unexpected error, and you notice that the numbers don't seem to match, that's the first thing that comes to mind.
I wasn't aware it uses differing ports, in normal operation...one doesn't notice that, when everything is working OK.
I don't understand why I got this error today, when the last time I used RB (2 days ago) everything was running well.
The only difference being the latest update.
So I will double check the sharing, next time I using.
guest
4th January 2020, 12:30
Weather here in Poland is also weird! IT is 6C now and they predict 10C in few days. That's not normal here in January. We should have temperatures below zero and snow.
Well, I guess they don't call it Global Warming for nothing..I mean the weather has been so unpredictable for a couple of years, now.
Australia is suffering the worst drought & bush fire's, in our short history
Atak_Snajpera
4th January 2020, 12:43
Well, I guess they don't call it Global Warming for nothing..I mean the weather has been so unpredictable for a couple of years, now.
Australia is suffering the worst drought & bush fire's, in our short history
Personally I have been noticing global warming since 90s. We used to have always so called white christmas almost every year. Now IT is just a history. Every year winter is milder and shorter. Instead of winter we just have cold autum at the moment. Spring is also very short. Last year we had Rapid change from 10C to 20C+ in first week of april. In other words IT was sudden jump to summer season.
Ripmann
4th January 2020, 17:48
Changelog v1.25.0
Added: Audio profiles in Profile\Audio.txt
...
First of all, thank you very much for implementing my suggestion for the audio profiles. It's a fantastic addition. Now here are some issues I'd like to report (1.25):
1) Adding new audio profiles currently has no effect on the 2-Pass KBPS calculations with Lock Size on. To reproduce, add two new AC3 profiles to Audio.txt:
5.1 FFMPEG AC3 512 kbps [cbr]
5.1 FFMPEG AC3 576 kbps [cbr]
Enable Lock Size and scroll through the audio profiles. Original profiles (448kbps, 640kbps) will change the 2-Pass KBPS value accurately. The new profiles will default to the same incorrect one (higher bitrate than for 448kbps), and the size-locked output will be encoded at higher size than expected.
Note: this may only affect some 5.1 AC3 profiles because I don't recall noticing this with "2.0 FFMPEG AC3 384 kbps [cbr]". I've only done a handful of jobs with the new profiles, so it obviously needs more testing. I'll let you know if I discover new details.
2) The program still has a problem with Unicode characters. This is a longstanding issue, but I just retested it on 1.25.
To reproduce, rename a test file to "Tést.mkv". Add as a new job. The audio track list will be empty ([NO AUDIO]).
Related note: as I recall from long ago, having Unicode characters in the output's file name would cause another error during the muxing process. I'm can't test it now, unfortunately, but the steps to reproduce would be: have a regular input "Test.mkv", set the output name as "Tést.mkv", start the job, wait for an error on the final stage.
3) The program also has two slight problems with intentional periods in output names:
Everything after the last period gets trimmed. To test, try renaming output to "BAD.NAME" (without .MKV). It will save as BAD.MKV. To avoid the problem, the .MKV extension part should be added to the file's name: entering "BAD.NAME.MKV" won't trim the name but will show as "BAD NAME.MKV" in the job's window.
This is also a problem for titles that should contain periods ("Dr. Dolittle", "Mr. Robot", etc.). I love that the program auto-removes periods from input names on demuxing ("test.file.S01E01.pilot.episode" becomes "test file S01E01 pilot episode"), but ideally, once you edit it manually, it should allow and keep the changes you make.
I found these naming issues a long time ago, so now I just routinely remove Unicode and periods from names and rename afterward, but I thought I'd mention them nevertheless. Hope it helps.
Ripmann
4th January 2020, 17:50
Come to think of it, here's yet another set of non-essential but useful suggestions I'd like to mention.
1) Adding black bars to adjust resolution without resizing. Some players and filters (for example, FFDshow) only support resolutions that are multiples of 16, so if you have an input of something like 1916x1080, adding black bars to "round it up" to 1920 would be a better solution, instead distorting the video with resize.
...
I don't know if this is new or I just noticed it (sadly, it was probably the latter), but this feature request is completely obsolete. For those struggling with the same issue, here are the extremely newbie-friendly steps for adding black vertical borders to the sides of the video:
1) Go to ...\RipBot264\Tools\AviSynth plugins\Scripts\Custom\
2) Create a custom script, name it something like like AddSideBorders_2x2.avs. Edit it in a text editor to include this:
#AddSideBorders
video=AddBorders(video,2,0,2,0)(This code will add 2 pixel-wide bars to the left and right sides of the video and 0 to the top and bottom.)
3) In the AviSynth tab of the job, go to the second screen and select your script from the CUSTOM SCRIPT dropdown menu. Preview.
That's it. If you just want to add black bars based on the aspect ratio, the custom scripts folder already has AddBorders16by9.avs for 16:9. Copy it and adjust its values for whatever aspect ratio you desire.
FuzzyNutz
4th January 2020, 22:41
what are the pros and cons?
Atak_Snajpera
4th January 2020, 23:01
https://i.imgsafe.org/28/286ce8b657.png
FuzzyNutz
4th January 2020, 23:09
https://i.imgsafe.org/28/286ce8b657.png
what do the numbers (0-70) on the left of your graph represent?
is hardware decoding gpu and software decoding cpu?
is there a diff in quality of end result?
Atak_Snajpera
4th January 2020, 23:11
Encoding speed in fps
guest
5th January 2020, 00:35
Personally I have been noticing global warming since 90s. We used to have always so called white christmas almost every year. Now IT is just a history. Every year winter is milder and shorter. Instead of winter we just have cold autum at the moment. Spring is also very short. Last year we had Rapid change from 10C to 20C+ in first week of april. In other words IT was sudden jump to summer season.
I guess it would depend on the where you are on Earth, to the different way it's impacting the climate, you being in a colder climate would notice different changes to here in Australia, where it's a very different climate.
It's certainly not going to get better, any time soon (if at all), and I really pity the current & future generations growing up, and coming into this world :(
guest
5th January 2020, 00:44
So enough of that doom & gloom.
Could you please give an explanation for this :-
https://forum.doom9.org/showpost.php?p=1894495&postcount=18160
Mainly the MDegrain situation....
Atak_Snajpera
5th January 2020, 00:48
There is nothing to explain.
guest
5th January 2020, 00:55
There is nothing to explain.
OK, but there's a reference to MDegrain 1 2 & 3 in the .ini file.
There's exceptions for them in the MT section.
But where are they, to use / enable....they're not in the Denoise drop down, or in the Custom drop down.
guest
5th January 2020, 10:47
1) stop saying that EmcodingClient is listening at wrong ports. Everything is fine. Tcpservers on client use ports from 1001 to 1016. On other hand servers use 1000 to 16000 to avoid conflicts.
2) server can not Access that cmd file using network Path. Enter that Path in Explorer to see If shared folder is acessible.
Well, after a much cooler 25°C day, I have come to some interesting conclusions.
Windows Networks & Sharing sux !!!
One thing that really bugs me is when you can connect to another pc, from a pc, but if you try to connect the other way, from the 2nd pc, it won't "talk" to the 1st pc, even with ALL the settings identical.
Not sure if that makes much sense, but then neither does this behaviour.
I now know why RB & DE can have so many problems, with situations like this, and also poor cables & plugs, doesn't help.
I've just updated all the connections on my small encoding "farmlet", I'm now using "Teaming" on all connections, which should greatly decrease the possibility of disconnections & dropouts (hopefully).
2 out of the 6 servers I have in this "farmlet", have this bizarre network connection problem that I mentioned above, they just won't "talk" to the client.
But at least I got nearly half way thru my next long encode, so it wasn't all bad.
slalom
5th January 2020, 14:02
Check if they are in the same "home" network
LigH
6th January 2020, 10:21
Windows Networks & Sharing sux !!!
I can only agree, being a semi-admin of a small company. I know this "half-blind network" very well. Especially workgroups are unreliable, domains may be better.
byteshare
6th January 2020, 17:07
is hardware decoding gpu and software decoding cpu?
is there a diff in quality of end result?
Yes, hardware is GPU and software is CPU.
There should not be a difference in quality.
Ripmann
7th January 2020, 14:21
I'm also fairly clueless about the process. Launching or exiting full screen 3D applications or games often causes temporary blinking even on secondary monitors. Can such simultaneous uses of the video card affect the encoding results? Or is the process entirely self-contained and checks should only be run on more serious cases like driver crashes?
Other than that concern, the difference in speed is pretty amazing with my setup. With the GPU boost, HEVC encoding finally takes reasonable amounts of time. Great new feature.
Atak_Snajpera
7th January 2020, 14:40
Hardware video decoding is performed on dedicated ASIC not on some shader units in GPU.
Ripmann
7th January 2020, 15:04
Hardware video decoding is performed on dedicated ASIC not on some shader units in GPU.
I knew it ran through a dedicated circuit, but I didn't realize that the two were entirely separate. For some reason, I was never interested in delving into the hardware component of computing, so I guess I still see a piece of hardware as a single unit, where if one thing fails, it all goes down the drain. Don't get me wrong, I can follow the specs and build and troubleshoot a PC, no problem, but once under-the-hood micro stuff like transistors, resistors, or integrated circuits get mentioned, my mind sort of automatically becomes oblivious to the stuff. Thanks for clarifying.
delacroixp
7th January 2020, 15:59
I have a 60fps gaming sequence ... how can I Change/Decimate/Blend/ConvertFPS() downto 24fps.
The Decimate option in RipBot264 is greyed out.
I've never toyed with avisynth but I'm keen to experiment.
Also, how do I encode in CRF (constant rate factor), rather than CQ (constant quality).
It's my first time with RipBot ... previously with HDConvertToX and then Xvid4psp (which recently became donation-ware).
I love the app, esp the option to encode with GPU support (currently running on a dual core with Nvidia 710).
Thanks much
:):devil::eek:
Atak_Snajpera
7th January 2020, 16:39
I knew it ran through a dedicated circuit, but I didn't realize that the two were entirely separate. For some reason, I was never interested in delving into the hardware component of computing, so I guess I still see a piece of hardware as a single unit, where if one thing fails, it all goes down the drain. Don't get me wrong, I can follow the specs and build and troubleshoot a PC, no problem, but once under-the-hood micro stuff like transistors, resistors, or integrated circuits get mentioned, my mind sort of automatically becomes oblivious to the stuff. Thanks for clarifying.
Obviously if gpu driver dies then encoding will die too ;)
Atak_Snajpera
7th January 2020, 16:51
Also, how do I encode in CRF (constant rate factor), rather than CQ (constant quality).
Select CQ mode and select your prefered CRF value in gui.
https://i.postimg.cc/4dDGZm39/Untitled-1.png
I have a 60fps gaming sequence ... how can I Change/Decimate/Blend/ConvertFPS() downto 24fps.
Just add this
https://i.postimg.cc/jjCQYjmK/Untitled-2.png
The Decimate option in RipBot264 is greyed out.
This option is only for inverse telecine.
delacroixp
7th January 2020, 19:52
Select CQ mode and select your prefered CRF value in gui.
Just add this
This option is only for inverse telecine.
Perfect ... works very nicely indeed.
Is there an option for AAC-He v2 VBR ...
The VBR is useful in avoiding wasted bits during quiet moments and v2 uses 1 channel to replicate the stereo differences.
All in all, even at maximum quality the bitrate hovers around 48 kb/s (suitable for most PC or built-in TV type speaker systems).
Is it true that h264 encodes are more efficient with "width MOD 32 = 0" and "height MOD 32 = 0" ... ie width and height perfectly divisible by 32 ?
Thanks much
:):devil::eek:
Atak_Snajpera
7th January 2020, 20:06
Do not worry about MOD 32 thing. It is just a placebo.
Regarding audio bitrate. Fraunhoffer encoder does not support VBR. Just old good Average Bit-Rate mode. Besides You won't save huge amounts of space by going down to ~48kbps.
example
120 min movie
7200s * 8KiB (64kbps) = ~56 MiB
7200s * 6KiB (48kbps) = ~42 MiB
So with 2h movie you save just 14 MiB. That's nothing these days.
LigH
8th January 2020, 10:28
In other circumstances, CQ may not mean "constant quality", but instead "constant quantizer".
Wishbringer
9th January 2020, 15:46
And in RipBot264 it's (CQ) used to set -crf (constant rate factor)
byteshare
9th January 2020, 22:55
What is the best method to convert 444 video to something usable for KNLMCL A?
x265 [error]: main10 profile not compatible with i444 input chroma subsampling.
delacroixp
10th January 2020, 01:09
Regarding audio bitrate. Fraunhoffer encoder does not support VBR. Just old good Average Bit-Rate mode.
Besides You won't save huge amounts of space by going down to ~48kbps.
example
120 min movie
7200s * 8KiB (64kbps) = ~56 MiB
7200s * 6KiB (48kbps) = ~42 MiB
So with 2h movie you save just 14 MiB. That's nothing these days.
So true ... everyone is going nuts about DTS (1,500 kb/s) , FLAC vinyl (3,000 kb/s) and 4/8k @ 60fps ...
that fighting over a few kb/s is really "penny wise and pound foolish".
Even the DL or storage of complete bluray ISO images (30+ GB) is getting more popular and
10 TB HDD's (see Storinator (https://www.youtube.com/watch?v=z3X49SYvbo0&feature=youtu.be&t=171) link) are also becoming more affordable
In other circumstances, CQ may not mean "constant quality", but instead "constant quantizer".
When Dr DivX (https://sourceforge.net/projects/drdivx/) first came out, CQ (constant quantizer) was gaining traction (2-pass is still more popular) ...
but CQ bunched all the quality around one quantizer (as seen by AVInaptic, for eg).
At least CRF compensates for human eyesight by attributing bitrate according to perceived experience (a bit like what VBR does for audio).
I've been trying to encode a Pavarotti concert compilation, released on NTSC DVD (Duets - 2008) interlaced BFF.
How do I deinterlace ... and reverse telecine the 29fps downto 24.
Each time it's halved the video time ... from 1hr 10 min downto 35 min.
The Decimate window is active but Deinterlace is greyed out. I'll try the Decimate -> 23fps only.
Thanks much
:):devil::eek:
Pascal
LigH
10th January 2020, 08:37
You either decimate Telecine (originally progressive video with duplicated fields, removing the duplicates to restore the original progressive content), or you deinterlace regular interlacing (it was never progressive, the recording time advances from field to field). They are mutually exclusive. And Telecine only exists in the NTSC world.
Perverse norm conversion results are not mentioned here. Reconstructing those is a higher skill.
bassquake
10th January 2020, 17:48
Seems to get stuck at "Please wait... Gathering information."
v1.25.0 on Win 10 1903.
Happens with any file I try to Add. Tried moving to standard folders with no spaces as recommended elsewhere to no avail.
duffbeer
10th January 2020, 17:54
Seems to get stuck at "Please wait... Gathering information."
v1.25.0 on Win 10 1903.
Happens with any file I try to Add. Tried moving to standard folders with no spaces as recommended elsewhere to no avail.
How long have you waited?
It always looks like it's frozen but after 10-15 mins you should be able to continue. Has been this way since 1.24.1
GZZ
10th January 2020, 19:47
How long have you waited?
It always looks like it's frozen but after 10-15 mins you should be able to continue. Has been this way since 1.24.1
Takes less then a minute here, but can take several minutes if cpu is under heavy load.
delacroixp
10th January 2020, 23:57
You either decimate Telecine (originally progressive video with duplicated fields, removing the duplicates to restore the original progressive content), or you deinterlace regular interlacing
(it was never progressive, the recording time advances from field to field).
They are mutually exclusive. And Telecine only exists in the NTSC world.
Perverse norm conversion results are not mentioned here. Reconstructing those is a higher skill.
OK ... chose the Restore-> 23.976 FPS (From NTSC 29.970 (30000/1001) FPS)
Audio is fine but video runs for 35 min (23.976 fps) instead of 1hr 10min.
Job Log
C:\Encoding\Muxing>"C:\Program Files (Green)\RipBot264v1.25.0\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "C:\Temp\RipBot264temp\job26\job26.avs" -strict -1 -f yuv4mpegpipe - | "C:\Program Files (Green)\RipBot264v1.25.0\tools\x264\x264_x64.exe" --colorprim bt709 --transfer bt709 --colormatrix bt709 --opencl --opencl-device 0 --opencl-clbin "C:\Users\RolyPoly\AppData\Local\Temp\x264_lookahead.clbin" --crf 20 --fps 24000/1001 --force-cfr --min-keyint 24 --keyint 240 --frames 50609 --sar 1:1 --level 4.0 --aud --nal-hrd vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --b-pyramid none --stdin y4m --output "C:\Temp\RipBot264temp\job26\video.264" -
y4m [info]: 672x504p 1:1 @ 38002/1585 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GT 710
x264 [info]: profile High, level 4.0, 4:2:0, 8-bit
[0.0%] 1/50609 frames, 0.93 fps, 184.90 kbps, eta 15:05:02
...
[99.9%] 50562/50609 frames, 25.04 fps, 2216.48 kbps, eta 0:00:01
x264 [info]: frame I:725 Avg QP:18.23 size: 46254
x264 [info]: frame P:14657 Avg QP:20.98 size: 19627
x264 [info]: frame B:35227 Avg QP:23.60 size: 7468
x264 [info]: consecutive B-frames: 2.7% 6.0% 22.7% 68.6%
x264 [info]: mb I I16..4: 12.2% 67.0% 20.8%
x264 [info]: mb P I16..4: 2.2% 12.8% 2.9% P16..4: 37.4% 23.1% 12.6% 0.0% 0.0% skip: 9.0%
x264 [info]: mb B I16..4: 0.4% 1.7% 0.5% B16..8: 41.3% 10.9% 3.1% direct: 7.9% skip:34.3% L0:38.5% L1:47.3% BI:14.3%
x264 [info]: 8x8 transform intra:69.3% inter:69.7%
x264 [info]: coded y,uvDC,uvAC intra: 78.5% 83.3% 51.7% inter: 34.0% 39.4% 3.2%
x264 [info]: i16 v,h,dc,p: 30% 38% 8% 24%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 16% 16% 6% 8% 9% 8% 8% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 29% 11% 5% 7% 8% 7% 7% 7%
x264 [info]: i8c dc,h,v,p: 48% 22% 20% 10%
x264 [info]: Weighted P-Frames: Y:15.9% UV:10.1%
x264 [info]: ref P L0: 58.5% 17.4% 15.7% 7.7% 0.7%
x264 [info]: ref B L0: 86.6% 13.4%
x264 [info]: kb/s:2214.43
encoded 50609 frames, 25.06 fps, 2214.43 kb/s
C:\Encoding\Muxing>"C:\Program Files (Green)\RipBot264v1.25.0\tools\mkvtoolnix\mkvmerge.exe" -o "C:\Encoding\Muxing\Pavarotti The Duets (2008) 430p crf20.mkv" --compression 0:none --title "Pavarotti The Duets (2008) 430p crf20" --default-duration 0:24000/1001fps "C:\Temp\RipBot264temp\job26\video.264" --compression 0:none --language 0:eng --aac-is-sbr 0:1 "C:\Temp\RipBot264temp\job26\Encoded_Audio_1.aac"
mkvmerge v41.0.0 ('Smarra') 64-bit
'C:\Temp\RipBot264temp\job26\video.264': Using the demultiplexer for the format 'AVC/H.264'.
'C:\Temp\RipBot264temp\job26\Encoded_Audio_1.aac': Using the demultiplexer for the format 'AAC'.
'C:\Temp\RipBot264temp\job26\video.264' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
'C:\Temp\RipBot264temp\job26\Encoded_Audio_1.aac' track 0: Using the output module for the format 'AAC'.
The file 'C:\Encoding\Muxing\Pavarotti The Duets (2008) 430p crf20.mkv' has been opened for writing.
'C:\Temp\RipBot264temp\job26\video.264' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 672/504.
The cue entries (the index) are being written...
Multiplexing took 10 seconds.
-------------------------
Elapsed Time: 00h:33m:55s
MediaInfo (BEFORE Encode)
General
Unique ID : 100180061204223771025399716201256040817 (0x4B5DFA5C443D9F49AD89CFDE9E79B971)
Complete name : C:\_ TO DO\Pavarotti\Pavarotti The Duets (2008) 430p.mkv
Format : Matroska
Format version : Version 4
File size : 3.94 GiB
Duration : 1 h 10 min
Overall bit rate mode : Constant
Overall bit rate : 8 016 kb/s
Movie name : Pavarotti The Duets (2008) 430p
Encoded date : UTC 2019-12-28 21:52:04
Writing application : mkvmerge v41.0.0 ('Smarra') 64-bit
Writing library : libebml v1.3.9 + libmatroska v1.5.2
Video
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : Variable
Format settings, picture structure : Frame
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1 h 10 min
Bit rate mode : Constant
Bit rate : 6 500 kb/s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Variable
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Bottom Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.628
Time code of first frame : 10:00:00:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 3.19 GiB (81%)
Title : Pavarotti The Duets (2008) 430p
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 1 h 10 min
Bit rate mode : Constant
Bit rate : 1 510 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Delay relative to video : 33 ms
Stream size : 760 MiB (19%)
Title : DTS
Language : English
Default : Yes
Forced : No
MediaInfo (AFTER Encode)
General
Unique ID : 178994719990866081107555327139134561340 (0x86A9210D77EA45EFDF12B60B37ABDC3C)
Complete name : C:\Encoding\Muxing\Pavarotti The Duets (2008) 430p crf20.mkv
Format : Matroska
Format version : Version 4
File size : 654 MiB
Duration : 1 h 10 min
Overall bit rate mode : Variable
Overall bit rate : 1 300 kb/s
Movie name : Pavarotti The Duets (2008) 430p crf20
Encoded date : UTC 2020-01-10 22:01:29
Writing application : mkvmerge v41.0.0 ('Smarra') 64-bit
Writing library : libebml v1.3.9 + libmatroska v1.5.2
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 35 min 10 s
Bit rate mode : Variable
Bit rate : 2 214 kb/s
Maximum bit rate : 25.0 Mb/s
Width : 672 pixels
Height : 504 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.273
Stream size : 557 MiB (85%)
Writing library : x264 core 159 r2991 1771b55
Encoding settings : opencl=1 / cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / crf_max=0.0 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio
ID : 2
Format : AAC LC SBR
Format/Info : Advanced Audio Codec Low Complexity with Spectral Band Replication
Commercial name : HE-AAC
Format settings : Explicit
Codec ID : A_AAC-2
Duration : 1 h 10 min
Bit rate : 192 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 23.438 FPS (2048 SPF)
Compression mode : Lossy
Stream size : 96.6 MiB (15%)
Language : English
Default : Yes
Forced : No
Sorry about the long post.
Thanks much
:):devil::cool:
Pascal
Atak_Snajpera
11th January 2020, 00:10
You should upload sample of original source file...
Ps. I suspect that problem is related with variable FPS in original video.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.