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 11th July 2021, 18:11   #19201  |  Link
StormMeows
Registered User
 
Join Date: May 2020
Posts: 74
Hey guys, is there anyone out there that uses Staxrip and Ripbot? I recently learned how to use Staxrip for backing up my large blu-ray collection and I am loving it, but it doesn't take full advantage of my AMD 5950x. When I am doing x264 8-bit encodes, it is only typically using ~70% of the CPU power. I have been following this Ripbot thread and have seen the evidence where you can 100% use the AMD multi threading processors, like my 5950x. With Staxrip, I could probably change some settings to make it reach 100% but that might suffer quality of the overall encode, right? Thanks for any guidance on this. I have a ton of movies I need to do and don't want to lose any quality (I aim for transparency to the original blu-ray). Thanks!
StormMeows is offline   Reply With Quote
Old 11th July 2021, 18:47   #19202  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,599
Just activate distributed encoding mode with 2 servers and you will have constant 100% cpu usage.
Atak_Snajpera is offline   Reply With Quote
Old 11th July 2021, 19:17   #19203  |  Link
StormMeows
Registered User
 
Join Date: May 2020
Posts: 74
Quote:
Originally Posted by Atak_Snajpera View Post
Just activate distributed encoding mode with 2 servers and you will have constant 100% cpu usage.
How is the quality of Ripbot x264 8 bit going to compare to Staxrip? I read that the more threads that I use on my AMD processor, the more it degrades the overall quality. Is that why Staxrip only typically uses 60-75% of my CPU? Thanks
StormMeows is offline   Reply With Quote
Old 11th July 2021, 20:34   #19204  |  Link
JKyle
App Digger
 
JKyle's Avatar
 
Join Date: Sep 2018
Posts: 411
Quote:
Originally Posted by StormMeows View Post
How is the quality of Ripbot x264 8 bit going to compare to Staxrip? I read that the more threads that I use on my AMD processor, the more it degrades the overall quality. Is that why Staxrip only typically uses 60-75% of my CPU? Thanks
StaxRip does x265 chunk encoding by cutting frames into N chunks (simple arithmetic division of the total number of frames = equal chunking) if Input/Output > Chunks is set to N in x265 Options. But unlike RipBot, each chunk employs separate processes in the SAME CPU in StaxRip.

I don't know how RipBot cuts the frames for DE in different servers, but if it cuts the frames evenly by simple arithmetic division (equal chunking), the only difference b/w StaxRip and RipBot lies in whether different CPUs can be employed (RipBot) or not (StaxRip).

And equal chunking is obviously inferior to scene-aware chunking which cuts frames based on frame similarities via ffmpeg, etc.

If you're interested in scene-aware chunking in x265, you may want to try Av1an. But since it's a CLI app, it has some learning curve, though.

For reference, there was a request to implement scene-aware chunking in StaxRip, but it's put off as of now due to some difficult obstacles at the code level.

Anyway, my apologies for cluttering up this thread with StaxRip topics.

Last edited by JKyle; 11th July 2021 at 20:37.
JKyle is offline   Reply With Quote
Old 11th July 2021, 21:54   #19205  |  Link
StormMeows
Registered User
 
Join Date: May 2020
Posts: 74
Quote:
Originally Posted by JKyle View Post
StaxRip does x265 chunk encoding by cutting frames into N chunks (simple arithmetic division of the total number of frames = equal chunking) if Input/Output > Chunks is set to N in x265 Options. But unlike RipBot, each chunk employs separate processes in the SAME CPU in StaxRip.

I don't know how RipBot cuts the frames for DE in different servers, but if it cuts the frames evenly by simple arithmetic division (equal chunking), the only difference b/w StaxRip and RipBot lies in whether different CPUs can be employed (RipBot) or not (StaxRip).

And equal chunking is obviously inferior to scene-aware chunking which cuts frames based on frame similarities via ffmpeg, etc.

If you're interested in scene-aware chunking in x265, you may want to try Av1an. But since it's a CLI app, it has some learning curve, though.

For reference, there was a request to implement scene-aware chunking in StaxRip, but it's put off as of now due to some difficult obstacles at the code level.

Anyway, my apologies for cluttering up this thread with StaxRip topics.
Thanks for the comparison between the two programs! I really appreciate it. It sounds like for x264 8-bit 1080p blu-ray encodes, I am fine using either of these fine programs.
StormMeows is offline   Reply With Quote
Old 15th July 2021, 14:42   #19206  |  Link
Deputy Cartman
Registered User
 
Join Date: Jan 2009
Posts: 2
Looooong time RipBot264 user but I'm unable to resolve an issue with Temp files and I'm hoping someone here can point me in the right direction.

I just upgraded my ancient i7-3770K desktop, using Windows 10 Enterprise, to a Ryzen 5950X so I'm interested in doing encodes on said desktop. I have had RipBot264 running on a Windows 2019 VM on my ESXi server for quite some time now, Windows Server 2016 before that, that is able to write to and use a Temp\Ripbot264temp directory hosted on a CentOS 8 VM, also on said ESXi server, no problem. I have a lot of VMs running and this 16 core Ryzen 5950X is a beast, hence my desire to shift encodes to my newly-upgraded desktop.

Unfortunately, though I've mapped the Samba share with the same CentOS 8 account credentials as on the Windows Server 2019 VM, when I try to add an encode, it always spits out:

Cannot create file
"W:\Temp\Ripbot264temp\job1\Blu-Ray_structure_getinfo.cmd". The system cannot find the file specified.

I am able to create directories and files on on the mapped network drive in Temp\RipBot264temp without incident.

I do not want to write temp files to my 2 TB NVMe SSD in order to maintain its longevity.

RipBot264.ini reads as follows when it produces the mentioned error.

StoreTempFilesin=W
*truncated*
DefaultOutputPath=W:\

Change StoreTempFilesin to C or AUTO and POOF, no more error.

I am using RipBot264 1.26.1 on both Windows Server 2019 and on Windows 10 Enterprise (21H1). I am pretty confident it has nothing to do with the CentOS 8 Samba shares because SMB3 is the minimum protocol version allowed and even the "WTF were you thinking!?" chmod 777 of the directory does not fix the issue on Windows 10 (21H1).
Deputy Cartman is offline   Reply With Quote
Old 17th July 2021, 01:49   #19207  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 617
Quote:
Originally Posted by StormMeows View Post
Thanks for the comparison between the two programs! I really appreciate it. It sounds like for x264 8-bit 1080p blu-ray encodes, I am fine using either of these fine programs.
What you need to do is stop swapping from forum to forum, asking the same basic questions !!!

If you're after SPEED, then the ONLY option IS RipBot, and using the Distributed Encoding option, with your 5950X, it would just plough thru like nothing, as you don't use much filtering.

And if you have other PC's, they can join it, to speed it up even more !!

Until Staxrip implements a simliar DE option, (which doesn't seem to be in their plans any time soon) it WILL be slower !!!
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is offline   Reply With Quote
Old 20th July 2021, 01:18   #19208  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 617
Off Topic (major flooding in Germany & Poland)

Hi Atak,

I can't help but hear about unprecedented rain & flooding in your part of the World....unbelievable damage.

Is this affecting you at all ??

Keep safe.

Cheers
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is offline   Reply With Quote
Old 20th July 2021, 12:20   #19209  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,459
In Germany, mainly the western part (Erftstadt, Wuppertal, etc.). About 160 people dead. The government was warned precisely and conveniently ahead of time; but it didn't pass through to the people. The disaster alarm system broke in the last decades. A siren test day last year failed, and this year it got postponed to next year because they did not get fixed in time.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 22nd July 2021, 01:45   #19210  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 617
Quote:
Originally Posted by LigH View Post
In Germany, mainly the western part (Erftstadt, Wuppertal, etc.). About 160 people dead. The government was warned precisely and conveniently ahead of time; but it didn't pass through to the people. The disaster alarm system broke in the last decades. A siren test day last year failed, and this year it got postponed to next year because they did not get fixed in time.
I wasn't sure what you were talking about, until I had a bit more of a look on YT, and now I know that there was some flood early warning system in place....not sure how that would be affective, a bit like forecasting earthquakes, volcanic eruptions, tsunami's, etc

It's generally too late to do much
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is offline   Reply With Quote
Old 22nd July 2021, 06:37   #19211  |  Link
Ronski
Registered User
 
Join Date: Oct 2010
Posts: 61
Quote:
Originally Posted by Deputy Cartman View Post
I do not want to write temp files to my 2 TB NVMe SSD in order to maintain its longevity.
I can't help with your network issue, but what NVME drive are you using? How many encodes do you do?

Most 2TB NVME drives have a pretty high TBW rating, so will last an extremely long time. I've recently written a huge amount of data (Chia plots) to various NVME drives, and they've all got a lot of life left. each plot creates around 1.4TB of writes. I've always used an SSD for the temp file and for storing my working files, and made use of the move setting to limit wear, but I don't do a huge amount of encodes.
Ronski is offline   Reply With Quote
Old 28th July 2021, 06:34   #19212  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 617
AVX & AVX2 optimizations

So now that I have got a 5950X, to work along side the 3950X, I have been testing these "so called" AVX & AVX2 optimized x265's...

And sadly I cannot notice a significant difference between any of them, unless I am missing something....

If anyone has an opinion on this, I would be glad to hear it.

I also ran a few tests with a 4 minute test file I have (which unfortunately only uses 3 DE servers)...

So with all the x265 builds I tried, there was only a few seconds difference in the encoding time (start to finish), which was approx 3:00 minutes (on the 5950X),
I tested on the 3950X with ALL the same settings, and it was 15 seconds quicker, due to the fact that the 3950X was to run at 100% on the 3 DE servers,
whereas the 5950X was substantially less, at around 75% +/-, due to the extra "power" the 5950X has, I guess.

And just as a reference, I also ran the 4 minute test file without DE, on the 5950X. and it took 4:11, so that's how much difference DE can make, just on the same PC.

And just as a test, I also ran it on a single E5 2690 v1, and it took 13:11, running at 100% on the 3 DE's.

So just to sum up, I was rather disappointed that the "optimized" x265's were a bit of a let down
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is offline   Reply With Quote
Old 28th July 2021, 12:41   #19213  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,599
Avx optimizations are always automatically used in x265 by default. To see a difference you must explicity disable them via command line.

https://x265.readthedocs.io/en/3.4/c...rmance-options

Last edited by Atak_Snajpera; 28th July 2021 at 12:43.
Atak_Snajpera is offline   Reply With Quote
Old 28th July 2021, 12:54   #19214  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,168
The optimization during compiling does not help if the code is already optimized manually (i.e. written in assembly). It will help in cases where there's only pure C code or something like that.

Having said that, the GCC builds of x265 produced by the Media Autobuild Suite were a couple of % faster than any of those other available builds on my 3900X when the Zen2 optimizations were enabled. I've been using MABS to build them ever since.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 28th July 2021, 14:51   #19215  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 617
Quote:
Originally Posted by Atak_Snajpera View Post
Avx optimizations are always automatically used in x265 by default. To see a difference you must explicity disable them via command line.

https://x265.readthedocs.io/en/3.4/c...rmance-options
Interesting...

So to lock it in, you'd use --asm avx, or --asm avx2, and to "kill" them all, it'd be --no-asm
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is offline   Reply With Quote
Old 28th July 2021, 14:58   #19216  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 617
Quote:
Originally Posted by Boulder View Post
The optimization during compiling does not help if the code is already optimized manually (i.e. written in assembly). It will help in cases where there's only pure C code or something like that.

Having said that, the GCC builds of x265 produced by the Media Autobuild Suite were a couple of % faster than any of those other available builds on my 3900X when the Zen2 optimizations were enabled. I've been using MABS to build them ever since.
I tried a couple of DJATOM's Zen optimized builds, didn't notice any difference.

Any suggestions ??, what have you been using, and where can I get my hands on some ???

I've found that 3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is offline   Reply With Quote
Old 28th July 2021, 15:10   #19217  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,168
Quote:
Originally Posted by Pauly Dunne View Post
I tried a couple of DJATOM's Zen optimized builds, didn't notice any difference.

Any suggestions ??, what have you been using, and where can I get my hands on some ???

I've found that 3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/
This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 28th July 2021, 15:22   #19218  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 617
Quote:
Originally Posted by Boulder View Post
This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.
I just tried to download this, and got this msg

"The file you requested has been deleted"
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is offline   Reply With Quote
Old 28th July 2021, 16:09   #19219  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,168
Quote:
Originally Posted by Pauly Dunne View Post
I just tried to download this, and got this msg

"The file you requested has been deleted"
That service seems to allow just one download for non registered uploads.

I've put the zip file here, if it works better:
https://www.4shared.com/s/fNyWQ4RLpiq
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...

Last edited by Boulder; 28th July 2021 at 16:13.
Boulder is offline   Reply With Quote
Old 28th July 2021, 17:36   #19220  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,930
Quote:
Originally Posted by Boulder View Post
This is what I use: https://file.io/0em0NP3ZGdou

It's basically just what MABS produces by default but with CFLAGS="-march=znver2 -O2 -pipe" added to the parameter file \local64\etc\custom_profile.
Yeah, you want to be optimizing for YOUR version of Zen, not just Zen generically.

Profile-Guided Optimization may also help if you're trying to squeeze every last bit of performance out of it, particularly if you profile using the settings you'll be using with the final build.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner 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 23:49.


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