Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd January 2020, 13:00   #18161  |  Link
GZZ
Registered User
 
Join Date: Jan 2002
Posts: 581
Quote:
Originally Posted by Pauly Dunne View Post
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

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.
GZZ is offline   Reply With Quote
Old 2nd January 2020, 16:42   #18162  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
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?

Quote:
Originally Posted by Pauly Dunne View Post
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.p...63#post1892063


Quote:
Originally Posted by ReinerSchweinlin View Post
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.
byteshare is offline   Reply With Quote
Old 3rd January 2020, 00:24   #18163  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by byteshare View Post
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.p...63#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...ostcount=18160).

No thanks, I got the filters figured out (with some help).
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)

Last edited by Pauly Dunne; 3rd January 2020 at 03:25.
Pauly Dunne is offline   Reply With Quote
Old 4th January 2020, 05:14   #18164  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Some weird problems with DE (latest build)

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/7ihak..._Error.7z/file
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)
Pauly Dunne is offline   Reply With Quote
Old 4th January 2020, 11:48   #18165  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
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.

Quote:
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.

Last edited by Atak_Snajpera; 4th January 2020 at 12:25.
Atak_Snajpera is offline   Reply With Quote
Old 4th January 2020, 12:27   #18166  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by Atak_Snajpera View Post
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.
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)

Last edited by Pauly Dunne; 5th January 2020 at 10:26.
Pauly Dunne is offline   Reply With Quote
Old 4th January 2020, 12:30   #18167  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by Atak_Snajpera View Post
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
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)
Pauly Dunne is offline   Reply With Quote
Old 4th January 2020, 12:43   #18168  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by Pauly Dunne View Post
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.
Atak_Snajpera is offline   Reply With Quote
Old 4th January 2020, 17:48   #18169  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 72
bug reports

Quote:
Originally Posted by Atak_Snajpera
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:
Code:
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 is offline   Reply With Quote
Old 4th January 2020, 17:50   #18170  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 72
Quote:
Originally Posted by Ripmann View Post
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:
Code:
#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.
Ripmann is offline   Reply With Quote
Old 4th January 2020, 22:41   #18171  |  Link
FuzzyNutz
Registered User
 
Join Date: Jun 2016
Location: Canada
Posts: 131
cpu vs gpu video decoding

what are the pros and cons?
FuzzyNutz is offline   Reply With Quote
Old 4th January 2020, 23:01   #18172  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Atak_Snajpera is offline   Reply With Quote
Old 4th January 2020, 23:09   #18173  |  Link
FuzzyNutz
Registered User
 
Join Date: Jun 2016
Location: Canada
Posts: 131
Quote:
Originally Posted by Atak_Snajpera View Post
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?
FuzzyNutz is offline   Reply With Quote
Old 4th January 2020, 23:11   #18174  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Encoding speed in fps
Atak_Snajpera is offline   Reply With Quote
Old 5th January 2020, 00:35   #18175  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by Atak_Snajpera View Post
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
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)
Pauly Dunne is offline   Reply With Quote
Old 5th January 2020, 00:44   #18176  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
MDegrain options.....

So enough of that doom & gloom.

Could you please give an explanation for this :-

https://forum.doom9.org/showpost.php...ostcount=18160

Mainly the MDegrain situation....
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)
Pauly Dunne is offline   Reply With Quote
Old 5th January 2020, 00:48   #18177  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
There is nothing to explain.
Atak_Snajpera is offline   Reply With Quote
Old 5th January 2020, 00:55   #18178  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by Atak_Snajpera View Post
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.
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)
Pauly Dunne is offline   Reply With Quote
Old 5th January 2020, 10:47   #18179  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by Atak_Snajpera View Post
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.
__________________
Not poorly done, just doin' it my way !!!
Live every day like it's your last, because one day, it will be !! (M$B)
Pauly Dunne is offline   Reply With Quote
Old 5th January 2020, 14:02   #18180  |  Link
slalom
Registered User
 
slalom's Avatar
 
Join Date: Jan 2010
Posts: 456
Check if they are in the same "home" network
__________________
E5 2697 v2 @ 3.0GHz on P9X79 Deluxe 24GB
Xeon E5-2680 v2 @ 3.1GHz 16GB
Sony Vaio VPC-F13Z1E/B
slalom is offline   Reply With Quote
Reply

Tags
264, 265, appletv, avchd, bluray, gui, iphone, ipod, ps3, psp, ripbot264, x264 2-pass, x264 gui, x264_64, x265, xbox360

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:54.


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