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 29th July 2021, 01:27   #19221  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
Quote:
Originally Posted by Boulder View Post
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
Thanks for doing that, I use IDM to download stuff, and some sites don't work too well, so that's why I didn't get it on the first attempt.

Is this a "special" build ??

Cheers
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is online now   Reply With Quote
Old 29th July 2021, 03:39   #19222  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
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.
OK, Boulder, I have done a fair bit more testing and have some interesting results:-

Oh, and BTW, those parameters don't work under Windows, or at least in RipBot

So, using your x265.exe, (which seems to be 3.5+10-82786fc GCC 10.3) with my test file using --ctu 32, took 2:11, using --ctu 64, took 3:34.

The x265 I am currently using (3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/ ) using --ctu 32, took 2:07, using --ctu 64, took 3:31.

So just the tiniest bit faster....and these were ALL done at Level 5.2 10bit.

Dropping down to Level 4.0 --ctu16 (default), it took the same time, 2:07.

I read somewhere that the GCC 11.1 builds are a little better with Ryzen's.

So using --ctu 32 would yield a much faster encode, but would --ctu 64 look a little better ????
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is online now   Reply With Quote
Old 29th July 2021, 12:25   #19223  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,165
I tested the two builds and the difference was just one second for 1500 frames so with my scripts and setup it's negligible. Nevertheless, the GCC builds seem best for Zen2 and probably Zen3 as well.
I use CTU 64 for 1080p and above and CTU 32 for below that.
__________________
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 30th July 2021, 03:31   #19224  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
Quote:
Originally Posted by Boulder View Post
I tested the two builds and the difference was just one second for 1500 frames so with my scripts and setup it's negligible. Nevertheless, the GCC builds seem best for Zen2 and probably Zen3 as well.
I use CTU 64 for 1080p and above and CTU 32 for below that.
Thanks for the info, and I might do a test using 32 & 64 on a 4K encode.

Cheers
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is online now   Reply With Quote
Old 31st July 2021, 10:21   #19225  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 192
Quote:
Originally Posted by Pauly Dunne View Post
OK, Boulder, I have done a fair bit more testing and have some interesting results:-

Oh, and BTW, those parameters don't work under Windows, or at least in RipBot

So, using your x265.exe, (which seems to be 3.5+10-82786fc GCC 10.3) with my test file using --ctu 32, took 2:11, using --ctu 64, took 3:34.

The x265 I am currently using (3.5+10-82786fc GCC 11.1 (none) from here, seems to be as good as any :- http://msystem.waw.pl/x265/ ) using --ctu 32, took 2:07, using --ctu 64, took 3:31.

So just the tiniest bit faster....and these were ALL done at Level 5.2 10bit.

Dropping down to Level 4.0 --ctu16 (default), it took the same time, 2:07.

I read somewhere that the GCC 11.1 builds are a little better with Ryzen's.

So using --ctu 32 would yield a much faster encode, but would --ctu 64 look a little better ????
Look at your CPU utilization and you will probably find that decreasing the maximum CU size will increase the potential for higher multi threaded load. The resolution you are encoding at and the number of threads you have available will determine how much impact this will have. Also note that it might be worth changing the merange value to accommodate for this change. With a high thread CPU like 5950X you will have a hard time saturating 32 threads for 1080p and bellow for single instance encoding without lowering the CU size, hence the speed increase.

I have a vague recollection that the devs posted some tests showing that it does effect encoding output somewhat hence why they stick to 64 even for lower res (for UHD you probably always wanna stick to 64). But I'm pretty sure its rather negatable, for high core count systems its probably worth the trade off.

Last edited by excellentswordfight; 31st July 2021 at 10:29.
excellentswordfight is offline   Reply With Quote
Old 31st July 2021, 11:01   #19226  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
Quote:
Originally Posted by excellentswordfight View Post
Look at your CPU utilization and you will probably find that decreasing the maximum CU size will increase the potential for higher multi threaded load. The resolution you are encoding at and the number of threads you have available will determine how much impact this will have. Also note that it might be worth changing the merange value to accommodate for this change. With a high thread CPU like 5950X you will have a hard time saturating 32 threads for 1080p and bellow for single instance encoding without lowering the CU size, hence the speed increase.

I have a vague recollection that the devs posted some tests showing that it does effect encoding output somewhat hence why they stick to 64 even for lower res (for UHD you probably always wanna stick to 64). But I'm pretty sure its rather negatable, for high core count systems its probably worth the trade off.
Interesting....and it's early days for me and the 5950X, haven't really done too much with it yet, done a bit more with the 3950X, but I think the 5950X is SO much better

I haven't done too much in the way of "tuning" x265, and I also don't know what merange runs at, within RipBot...I thought I saw a reference, showing it @ 9, but apparently the "default" setting is 57.

https://x265.readthedocs.io/en/stable/presets.html

So some testing is on the cards, as I have a LOT to do, and a short time to do it.
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is online now   Reply With Quote
Old 31st July 2021, 11:47   #19227  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 192
Quote:
Originally Posted by Pauly Dunne View Post
Interesting....and it's early days for me and the 5950X, haven't really done too much with it yet, done a bit more with the 3950X, but I think the 5950X is SO much better

I haven't done too much in the way of "tuning" x265, and I also don't know what merange runs at, within RipBot...I thought I saw a reference, showing it @ 9, but apparently the "default" setting is 57.

https://x265.readthedocs.io/en/stable/presets.html

So some testing is on the cards, as I have a LOT to do, and a short time to do it.
"Motion search range. Default 57

The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames."

https://x265.readthedocs.io/en/stable/cli.html

So for 1080p and lower you might wanna try --ctu 32 --merange 26 if you use preset slow or lower, for UHD just stick with default.

Last edited by excellentswordfight; 31st July 2021 at 11:50.
excellentswordfight is offline   Reply With Quote
Old 31st July 2021, 12:29   #19228  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
Quote:
Originally Posted by excellentswordfight View Post
"Motion search range. Default 57

The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames."

https://x265.readthedocs.io/en/stable/cli.html

So for 1080p and lower you might wanna try --ctu 32 --merange 26 if you use preset slow or lower, for UHD just stick with default.
Nice, not too concerned about 1080p or lower all that much, but currently I'm doing a lot of DVD res stuff, old TV series, DVD rips etc.

But the main project is getting a LOT of 4K stuff done, it's just such a shame that it takes so long....if I could get a encode done in a day (6 - 8 hours, won't let it run overnight !!!!), that would be awesome.

So what would you recommend for nice 4K results & speed ??

Do you use RipBot ??
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is online now   Reply With Quote
Old 1st August 2021, 21:41   #19229  |  Link
Ripmann
Registered User
 
Join Date: Nov 2019
Posts: 56
A quick and easy feature request for consideration:

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).
Ripmann is offline   Reply With Quote
Old 2nd August 2021, 03:27   #19230  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
Quote:
Originally Posted by Ripmann View Post
A quick and easy feature request for consideration:

Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).
I'm pretty sure that this same question was asked not too long ago..

That copy option is only available for certain file types, eg:- .ts, ,m2ts, etc. .mp4 & .mkv don't.
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is online now   Reply With Quote
Old 2nd August 2021, 15:12   #19231  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 363
Quote:
Originally Posted by Ripmann View Post
Please consider adding a "Copy Stream" option for the video track Profile (similar to that for audio tracks). Not sure how useful it would be in a single job mode, but there's definitely use for it the batch window (mass convert audio tracks only).
Yes, I asked that some time ago, too.
ReinerSchweinlin is offline   Reply With Quote
Old 2nd August 2021, 16:05   #19232  |  Link
chainring
Registered User
 
chainring's Avatar
 
Join Date: Sep 2006
Posts: 163
Snip...

Quote:
Originally Posted by Pauly Dunne View Post
So what would you recommend for nice 4K results & speed ??
Back some time ago, I had the same dilemma. I don't recall which thread it was in, but I asked benwaggoner and Blue_Misfit about resizing 4K content down to 2560 x X since the majority of 4K releases had been rendered at DCI 2K. I figured 2560 was a happy medium between 4K (3840) and DCI 2K (2048). Consensus was it'd be a good idea as long as my playback device could handle the resolution.

All the content I have is played back through Nvidia Shields and I have zero problems. I also play those same movies on a Samsung Tab S6 (OLED screen) via Kodi and it has no problems, either.

Anything 4K with HDR, gets the following treatment:
Resized to 2560 x X
x265 10 bit
--hdr10 --hdr10-opt
Preset Medium

Flavor to taste with:
I start with CQ16 and adjust upwards if file size gets out of control.
Denoise with MDegrain and adjust to grain content. Most of the time, MDegrain2 is the highest I go.

I've been overall very satisfied with the speed of processing when using RipBot's DE mode and four older Dell PCs. If there's no MDegrain involved, I can rip through an encode in 2-3 hours. Add in MDegrain2 and we're talking more like 9 hours. File sizes are sometimes ridiculously small, even at CQ16 and it's a bit difficult to accept, but I go with it.
chainring is offline   Reply With Quote
Old 2nd August 2021, 20:44   #19233  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,165
--hdr10-opt is the one that causes the bitrate drop, the CRF values with and without it are not directly comparable. For HDR, I use CRF 14 or 15, downscaling to 1440p or 1080p largely depending on whether it's a native 4K source or just upscaled from 2K.
__________________
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 3rd August 2021, 07:38   #19234  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,595
You are wasting energy! 30Mbps for 1080p and 60Mbps for 2160p? That's Probably more than original bitrate. Just remux that movie and do not reencode!
Atak_Snajpera is offline   Reply With Quote
Old 3rd August 2021, 10:44   #19235  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
Quote:
Originally Posted by Atak_Snajpera View Post
You are wasting energy! 30Mbps for 1080p and 60Mbps for 2160p? That's Probably more than original bitrate. Just remux that movie and do not reencode!
I was actually expecting you to chime in...

I think you'll find that GOOD quality original 1080p's & 2160p's can be ≥ than the bitrates I encode @ !!!

As far as I have noticed, it doesn't affect the processing time of the encode, it's simply the muxing that might take a little longer, but if you've got powerful CPU's & fast NVMe's, it's NOT an issue.

And just so you know, there's NO wasted energy here, "sunshine", I ONLY encode when I'm getting "free" power from my solar panels !!!!

Admittedly, some could be simply remuxed, but some need filtering !!

And while I have your attention, I have noticed an issue with Windows 11 (not that you'll care too much), but in the Encoding Client window, that little row of "button's" for each server, seem to loose their functionality, mainly the Shutdown Server button, not only doesn't it change it's appearance, you can't tell whether it's enabled or disabled, but either way, as it doesn't seem to want to turn off the server(s)....however, the main Shutdown Servers & Client works, tho.
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(

Last edited by Pauly Dunne; 4th August 2021 at 00:53.
Pauly Dunne is online now   Reply With Quote
Old 3rd August 2021, 11:46   #19236  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,595
You do not have my attention sunshine.
Atak_Snajpera is offline   Reply With Quote
Old 3rd August 2021, 12:58   #19237  |  Link
Pauly Dunne
Grumpy Old Man.
 
Pauly Dunne's Avatar
 
Join Date: Jul 2019
Location: Out There....
Posts: 587
Quote:
Originally Posted by Atak_Snajpera View Post
You do not have my attention sunshine.
I beg to differ...you replied
__________________
Not poorly done, just doin' it my way !!!
So much to do, and so little time :(
Pauly Dunne is online now   Reply With Quote
Old 3rd August 2021, 15:43   #19238  |  Link
chainring
Registered User
 
chainring's Avatar
 
Join Date: Sep 2006
Posts: 163
Quote:
Originally Posted by Pauly Dunne View Post
Hey chainring, yeah, not interested in downsizing 4K footage, I mean, that's why I bought a 4K, HDR TV !!!
4K, meh. HDR is where it's at.

Quote:
I also use SMDegrain filters, found them better than MDegrain, I also don't use any CRF settings, I just go for bitrate, size is NOT an issue.
After years of messing with different scripts put together by the honest to god geniuses of Doom9, I no longer have the time nor inclination to constantly tweak scripts anymore. MDegrain works plenty good for me.

Bitrate is for when you need a predictable sized outcome. Why, if you're doing this for your own purposes, are you not letting CQ decide? Constant Quality. It ain't dumb. Go back and find posts from akupenguin and Dark_Shikari; get some history under your belt.

Quote:
So 15,000kbps for 720p, 30,000kbps for 1080p, and 60,000kbps for 4K, and SMDegrain to "flavour"
You're wasting time and energy encoding at those bit rates. Why don't you stick with a remux?

Last edited by chainring; 3rd August 2021 at 15:45.
chainring is offline   Reply With Quote
Old 3rd August 2021, 20:56   #19239  |  Link
Ryushin
Registered User
 
Join Date: Mar 2011
Posts: 318
Bind IP Bug

Hi Atak,

I think I uncovered a bug. For some reason I can never bind to my subnet, 192.168.9.* for the encoding server. I tried adding to the encoding server:
/IP 192.168.9.40
And it always grabs the secondary IP 192.168.1.40. I added 172.28.27.40 and 192.168.0.40 as secondary IPs and the encoding server will bind to those, but not to 192.168.9.40. Very odd.
Ryushin is offline   Reply With Quote
Old 4th August 2021, 09:14   #19240  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,459
Shh, calm down please. Let's focus on technical solutions, not personal opinions.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 07:59.


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