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 9th November 2019, 22:15   #17701  |  Link
mparade
Registered User
 
Join Date: Nov 2013
Posts: 577
Thx! + ok.
mparade is offline   Reply With Quote
Old 11th November 2019, 19:27   #17702  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by Pauly Dunne View Post
BIG changes in Encoding Client for server "control"

Can't wait to check this out
Ah, I see what you mean now. You can suspend or shutdown a server.
Not sure if anything else changed.
byteshare is offline   Reply With Quote
Old 12th November 2019, 00:36   #17703  |  Link
Dhry
Registered User
 
Dhry's Avatar
 
Join Date: Jan 2018
Posts: 16
There seems to be something wrong with the latest 1.25 of Ripbot and the 1.16 EncodingServer. I had reported issues with trying to get a batch to start properly (adding a file via Add worked, though), however as of today, even adding a file via that method did not work with distributed encoding. What happens is that the file demuxes and this and that fine, then the dist encoding master window pops up for pass1 and nothing happens. None of the server farm responds. Their encodingserver instances literally do not receive the TCP command at all. Nothing appears in the logging console. I switched out for 1.15.1.0 of the encodingserver and THEN they started to receive commands but were unable to open the file for writing to my shared folder. It's only when I went back to Ripbox 1.24 and used IT'S encoding client, and encodingserver 1.15.1.0 on all of my boxes, that everything started working again. INCLUDING batch processing! Some weird networking change has evidently been done in the code which breaks connectivity. I disabled my firewall and tested pings between the machines, no problem at all. The problem now is that using RB 1.24 I get the old error stating that video.265 file could not be opened. Are there any known distributed encoding connectivity issues that others have experienced with RB 1.25 and EncodingServer 1.16? Using Windows 7 SP1.

--Dhry
Dhry is offline   Reply With Quote
Old 12th November 2019, 06:52   #17704  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
Atak,

I don't recall if I've ever asked this before, although I get the feeling I may have broached the subject in years previous. I'm curious about what method you are employing to split the files (I don't see anything "obvious" in the tools directory except an executable called vjoin, which I assume is for joining). I'm trying to do some research on the best way to accomplish splitting/joining accurately and efficiently without any glitches. I've seen references online to using ffmpeg to split on keyframes (and ffprobe to acquire an index of keyframes to help with this) but haven't really found any real turnkey solution, outside of something like DVE https://github.com/nergdron/dve



slightly related, do you have any plans to ever expose ffmpeg for use by the user (as opposed to x264/x265)? I'm mainly interested in targeting and accelerating VP9 (libvpx for now) across multiple cores/machines, but down the road when Intel's SVT libraries become more mature this could be useful to a lot of people as well, especially with AV1
osgZach is offline   Reply With Quote
Old 12th November 2019, 13:25   #17705  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by Dhry View Post
There seems to be something wrong with the latest 1.25 of Ripbot and the 1.16 EncodingServer. I had reported issues with trying to get a batch to start properly (adding a file via Add worked, though), however as of today, even adding a file via that method did not work with distributed encoding. What happens is that the file demuxes and this and that fine, then the dist encoding master window pops up for pass1 and nothing happens. None of the server farm responds. Their encodingserver instances literally do not receive the TCP command at all. Nothing appears in the logging console. I switched out for 1.15.1.0 of the encodingserver and THEN they started to receive commands but were unable to open the file for writing to my shared folder. It's only when I went back to Ripbox 1.24 and used IT'S encoding client, and encodingserver 1.15.1.0 on all of my boxes, that everything started working again. INCLUDING batch processing! Some weird networking change has evidently been done in the code which breaks connectivity. I disabled my firewall and tested pings between the machines, no problem at all. The problem now is that using RB 1.24 I get the old error stating that video.265 file could not be opened. Are there any known distributed encoding connectivity issues that others have experienced with RB 1.25 and EncodingServer 1.16? Using Windows 7 SP1.

--Dhry
What happens If you run ripbot264 on other machine? Do you still see the same issue? Record you desktop with some software (fraps or other) and upload somewhere. I would like to see that weird behaviour with my own eyes.

Ps. I also have win7 on all my machines and everything just works.
Atak_Snajpera is offline   Reply With Quote
Old 13th November 2019, 04:44   #17706  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by Dhry View Post
There seems to be something wrong with the latest 1.25 of Ripbot and the 1.16 EncodingServer. I had reported issues with trying to get a batch to start properly (adding a file via Add worked, though), however as of today, even adding a file via that method did not work with distributed encoding. What happens is that the file demuxes and this and that fine, then the dist encoding master window pops up for pass1 and nothing happens. None of the server farm responds. Their encodingserver instances literally do not receive the TCP command at all. Nothing appears in the logging console. I switched out for 1.15.1.0 of the encodingserver and THEN they started to receive commands but were unable to open the file for writing to my shared folder. It's only when I went back to Ripbox 1.24 and used IT'S encoding client, and encodingserver 1.15.1.0 on all of my boxes, that everything started working again. INCLUDING batch processing! Some weird networking change has evidently been done in the code which breaks connectivity. I disabled my firewall and tested pings between the machines, no problem at all. The problem now is that using RB 1.24 I get the old error stating that video.265 file could not be opened. Are there any known distributed encoding connectivity issues that others have experienced with RB 1.25 and EncodingServer 1.16? Using Windows 7 SP1.

--Dhry
Quote:
Originally Posted by Atak_Snajpera View Post
What happens If you run ripbot264 on other machine? Do you still see the same issue? Record you desktop with some software (fraps or other) and upload somewhere. I would like to see that weird behaviour with my own eyes.

Ps. I also have win7 on all my machines and everything just works.
I concur...

I only just got around to "testing" the latest update (08-11-19), and it's completely ruined DE !!!

Not using DE works fine !!

So I have recorded my desktop (using OBS, Fraps doesn't like W10, apparently).

https://www.mediafire.com/file/aoz3z...49-35.rar/file

I have shown most of RB screens in the capture...there's just nothing connecting.

Also, there needs to be a "flyout" of what the new buttons do, in the left column of Encoding Client do (you'll see what I mean in the capture)

Also, running W10 1903, and just because it works on W7, doesn't mean it will work on other versions...

You might also notice that when the Job is aborted, it kills RB, but leaves the Clients in the Task Bar.

I have had to return to the previous build.

And another thing I'd like to mention (which has been a problem for me for a long time), after you add a new Job, and then start that Job, it won't start processing....RB has to be re-started beforehand !!
__________________
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; 13th November 2019 at 06:27.
Pauly Dunne is offline   Reply With Quote
Old 13th November 2019, 09:57   #17707  |  Link
MCFish
Registered User
 
MCFish's Avatar
 
Join Date: Oct 2002
Location: Norway
Posts: 46
Same here. None of the encoding servers get any connection with latest update.
__________________
MCFish
MCFish is offline   Reply With Quote
Old 13th November 2019, 11:04   #17708  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 454
I noticed one new thing:
After changing my Numa Settings in my proliant D380G7 (2 x Xeon X5650) to not use NUMA but instead treat the two CPUs as one - I get almost 96% CPU Usage when using one encodingserver with x265 slow settings - it is blazing fast now. Bevore, I had to use 4 servers to max out CPU (only de-interlacing used, nothing else).

Did anything change in recent x265 you use?
ReinerSchweinlin is offline   Reply With Quote
Old 13th November 2019, 14:46   #17709  |  Link
Ryushin
Registered User
 
Ryushin's Avatar
 
Join Date: Mar 2011
Posts: 431
I'm getting a error on the DE Server:
x265 [Error]: main10 profile not compatible with i444 input chroma subsampling

Brought a fresh job in of a 4K HDR mkv file, that Ripbot made from the original 4K source a few days ago. Changed the size down to 720p. Set 5.1 AAC, 21 CRF. X265 with the default options plus sar 1:1 (not sure why sar 1:1 is not the default as I've been bitten by stretching in 4x3 shows). Server Chunk fails with that error immediately as it tries to start it.

Also, older 4K jobs that I brought in from disc source from a couple of weeks ago just show "Starting...." and then nothing ever starts. Encoding client shows processor usage about 15%, but nothing ever starts.

Edit: Well, one of the older jobs eventually started running after about 30 minutes. However, the job before it had Starting... for six hours and never did anything.

Last edited by Ryushin; 13th November 2019 at 15:11. Reason: Update
Ryushin is offline   Reply With Quote
Old 13th November 2019, 15:44   #17710  |  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
I concur...

I only just got around to "testing" the latest update (08-11-19), and it's completely ruined DE !!!

Not using DE works fine !!

So I have recorded my desktop (using OBS, Fraps doesn't like W10, apparently).

https://www.mediafire.com/file/aoz3z...49-35.rar/file

I have shown most of RB screens in the capture...there's just nothing connecting.

Also, there needs to be a "flyout" of what the new buttons do, in the left column of Encoding Client do (you'll see what I mean in the capture)

Also, running W10 1903, and just because it works on W7, doesn't mean it will work on other versions...

You might also notice that when the Job is aborted, it kills RB, but leaves the Clients in the Task Bar.

I have had to return to the previous build.

And another thing I'd like to mention (which has been a problem for me for a long time), after you add a new Job, and then start that Job, it won't start processing....RB has to be re-started beforehand !!
Win10 1909
Atak_Snajpera is offline   Reply With Quote
Old 13th November 2019, 16:59   #17711  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by ReinerSchweinlin View Post
I noticed one new thing:
After changing my Numa Settings in my proliant D380G7 (2 x Xeon X5650) to not use NUMA but instead treat the two CPUs as one - I get almost 96% CPU Usage when using one encodingserver with x265 slow settings - it is blazing fast now. Bevore, I had to use 4 servers to max out CPU (only de-interlacing used, nothing else).

Did anything change in recent x265 you use?
Not the most recent update but maybe 2 versions ago (no version numbers for the changes so I can't recall)? There were some changes to RB and I saw the same effect of not needing as many servers to max out CPU. Had something to do with the multiple processing threads but I'm not sure exactly what was changed or what was the issue before hand.
For my encoding machines on Core version: 2019.10.15
I have a test machine for the latest builds and once they work how I like I change to a newer version.
byteshare is offline   Reply With Quote
Old 14th November 2019, 00:46   #17712  |  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
Win10 1909
So, we're just posting screen shots now, are we ???

My crystal ball musn't be working today....

So this is either you showing that it works, or you've fixed it, or you're just rubbing our nose's in it !!!

I got a new update this morning, only "script's", updated the pc that I did that screen recording on yesterday, loaded a new job, and exactly the same scenario....NOTHING, no TCP connection !!!

Ran build 22-10-19, loaded the same job, started that job, and away she goes, not problem, on the same pc.

What's changed ???

PS:- Just tried it on another W10 (1909) pc, and the same result, further comments in my reply to Dhry.

POORLY DONE !!!!!
__________________
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; 14th November 2019 at 01:32.
Pauly Dunne is offline   Reply With Quote
Old 14th November 2019, 00:56   #17713  |  Link
Dhry
Registered User
 
Dhry's Avatar
 
Join Date: Jan 2018
Posts: 16
The screenshot seems to show that RB works with Win10 only. I'm pretty sure something's broken with the tcp connectivity on Win7 at least. It's literally not making a outbound connection at all.
I'll go back to the newest versions and try again.
Edit: it isn't updating. Could the first post in this thread be changed to link to 1.25 of RB please? Still linked to 1.24.

Last edited by Dhry; 14th November 2019 at 00:59.
Dhry is offline   Reply With Quote
Old 14th November 2019, 01:31   #17714  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by Dhry View Post
The screenshot seems to show that RB works with Win10 only. I'm pretty sure something's broken with the tcp connectivity on Win7 at least. It's literally not making a outbound connection at all.
I'll go back to the newest versions and try again.
Edit: it isn't updating. Could the first post in this thread be changed to link to 1.25 of RB please? Still linked to 1.24.
Thanks Dhry, I'm glad I'm not the only one pissed off about this.

I have just tested it on 2 different W10 (1909) pc's, with the same result...NOTHING, it's f*****.

I'm not sure what the idea of that screenshot is, with NO explanation.

The only way I can get RB to do anything after that last 2 updates is to NOT use DE, OR go back to the previous build (22-10-19).
__________________
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 14th November 2019, 08:57   #17715  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 454
Quote:
Originally Posted by byteshare View Post
Not the most recent update but maybe 2 versions ago (no version numbers for the changes so I can't recall)? There were some changes to RB and I saw the same effect of not needing as many servers to max out CPU. Had something to do with the multiple processing threads but I'm not sure exactly what was changed or what was the issue before hand.
For my encoding machines on Core version: 2019.10.15
I have a test machine for the latest builds and once they work how I like I change to a newer version.
I noticed the CTU size smaller then usual when using RB with x265, which seems to help with many cores, maybe something changed here, too..
ReinerSchweinlin is offline   Reply With Quote
Old 14th November 2019, 10:11   #17716  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 692
Quote:
Originally Posted by ReinerSchweinlin View Post
I noticed one new thing:
After changing my Numa Settings in my proliant D380G7 (2 x Xeon X5650) to not use NUMA but instead treat the two CPUs as one - I get almost 96% CPU Usage when using one encodingserver with x265 slow settings - it is blazing fast now. Before, I had to use 4 servers to max out CPU (only de-interlacing used, nothing else).

Did anything change in recent x265 you use?
So you're saying that NUMA isn't an advantage, anymore ??
__________________
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 14th November 2019, 11:03   #17717  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by Dhry View Post
The screenshot seems to show that RB works with Win10 only. I'm pretty sure something's broken with the tcp connectivity on Win7 at least. It's literally not making a outbound connection at all.
I'll go back to the newest versions and try again.
Edit: it isn't updating. Could the first post in this thread be changed to link to 1.25 of RB please? Still linked to 1.24.
Like I said before. Everything just works
Atak_Snajpera is offline   Reply With Quote
Old 14th November 2019, 11:49   #17718  |  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
Like I said before. Everything just works
Godammit, so please explain to me why the previous build works, and then it gets updated with this mess, and it's useless !?!?!?

Something in the fairly major change to Encoding Client, has impacted the TCP connection !!

So you've clearly shown that it works for you on both W7 & W10, but you have to advantage over us, YOU know what you've changed, and we don't.

Did you view that desktop capture I posted ??? what else do you need ??
__________________
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 14th November 2019, 12:56   #17719  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
My theory is that your firewall Has detected that checksum for encodingclient.exe/encodingserver.exe changed and by default blocks again all outgoing connections.
Atak_Snajpera is offline   Reply With Quote
Old 14th November 2019, 13:10   #17720  |  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
My theory is that your firewall Has detected that checksum for encodingclient.exe/encodingserver.exe changed and by default blocks again all outgoing connections.
Well, I doubt that's the problem, as I have ALL the Firewall's disabled.

But why would that change between RB builds ??
__________________
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
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 10:11.


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