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 > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 16th April 2017, 03:44   #5201  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by LigH View Post
The reason not to implement assembler optimized routines in 32 bit x265 versions is that it would be a waste of development time. Bit depths >8 would require twice the amount of RAM compared to the 8 bit version (addressing 16 bit even if only 10 or 12 bits precision are relevant), and already the allocated memory for 8 bit depth may be too much to encode 1080p video with a 32 bit build, depending on the complexity (preset).
Contributions are always welcomed, but you're right... the effort to fully optimize the 32 bit version of x265 (8 bit encoding only) is tough to justify. x265 has hundreds of kernels that are SIMD optimized for various instruction sets, and it's a fairly substantial effort (many, many developer man-months).
  Reply With Quote
Old 17th April 2017, 21:45   #5202  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Any idea when we might see the 10bit lamda table? I'm dying to give it a try!!
brumsky is offline   Reply With Quote
Old 19th April 2017, 07:33   #5203  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
There is light at the end of the tunnel: A patch for 10 and 12 bit lambda tables was proposed in the mailing list. So stay alert, new builds might appear soon™...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 19th April 2017, 15:04   #5204  |  Link
Magik Mark
Registered User
 
Join Date: Dec 2014
Posts: 666



Sent from my iPhone using Tapatalk
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR
Magik Mark is offline   Reply With Quote
Old 19th April 2017, 15:46   #5205  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Awesome!!
brumsky is offline   Reply With Quote
Old 19th April 2017, 16:07   #5206  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by aymanalz View Post
Interesting, I wonder if this would address the complaints against SAO on this thread, namely that it causes too much blurring.
It's "just" a performance optimization.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th April 2017, 17:00   #5207  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by mariush View Post
The 32bit version of x265 may lack some assembly optimizations that are present in the 64bit version of x265.

The 32bit version would also be more memory constrained, since it would be limited to 2-3 GB of memory... 64 bit versions wouldn't have such limitations.
Beyond the lack of assembly optimization, x64 has double the number of registers as old x86 vanilla.

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago. Adobe dropped 32-bit support in their video apps back in 2010. And 64-bit is generally faster and quite a bit more secure. 64-bit software decoders are generally faster than 32-bit versions as well.

I recommend folks upgrade to 64-bit OSes rather than trying to make x265 run better on 32-bit!
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th April 2017, 18:05   #5208  |  Link
x265_Project
Guest
 
Posts: n/a
Haivision contributions to the x265 open-source initiative have pushed boundaries

Haivision was one of the four original commercial sponsors of x265, and four years later, we can finally go public with this! They have been a terrific partner over the years, continually investing in x265 and UHDkit, to push the envelope of what is possible in a software encoder. Both Haivision and MulticoreWare will be demonstrating the latest capabilities of x265 and UHDkit at the NAB show next week.

Haivision to Demonstrate Breakthrough Performance of Live 4K HEVC/H.265 Software Encoding at 2017 NAB Show
http://www.haivision.com/news-events...ch265-software
  Reply With Quote
Old 19th April 2017, 18:31   #5209  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by benwaggoner View Post
Beyond the lack of assembly optimization, x64 has double the number of registers as old x86 vanilla.

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago. Adobe dropped 32-bit support in their video apps back in 2010. And 64-bit is generally faster and quite a bit more secure. 64-bit software decoders are generally faster than 32-bit versions as well.

I recommend folks upgrade to 64-bit OSes rather than trying to make x265 run better on 32-bit!
I don't know how large the market for them really is, but there are plenty of small mini-PCs that still ship with 32-bit versions of Windows because the companies involved don't want to put larger (read: anything over 32GB) internal storage in them, even though they use x86-64 hardware platforms.

And because said machines are likely using 32-bit UEFI (the horror), it's practically impossible to upgrade to 64-bit Windows without replacing the computer entirely. You can still run 64-bit Linux distributions on them (with varying levels of difficulty getting it set up right), since EFI mixed mode has been supported in the Linux kernel since version 3.15.

Personal anecdote time: I'm typing this post out on one such mini-PC (the Quantum Byte, specifically). It's a perfectly capable little machine for casual encoding or media consumption, or mundane office tasks/web browsing, but it's obviously not going to be used for serious encoding tasks. If I really want to squeeze it for performance and 64-bit usage, I did manage to get 64-bit Ubuntu installed to a USB stick and can boot from that when I need to (but running the OS through a USB 2.0 port is not exactly ideal for speed; probably negates all of the benefits 64-bit would've gotten me). It runs on the Atom Z3735F Bay Trail-T/Silvermont platform, so extrapolate whatever speed estimates you can there. It's good enough to bide my time until Coffee Lake arrives and I build something to replace the ancient Coppermine tower I'd been using as my main setup before I got the Byte. Provided Coffee Lake has AVX-512, anyway; there's been conflicting reports about that.
qyot27 is offline   Reply With Quote
Old 19th April 2017, 18:38   #5210  |  Link
Dclose
Registered User
 
Join Date: Aug 2014
Posts: 50
Quote:
Originally Posted by benwaggoner View Post
I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago.
Windows 7 OS uses less than a gb. Encoding mostly relies on CPU. X265 was working great until I wanted to use 10-bit. Windows 7 32-bit works as well for video on my HTPC as it did when I first put it together years ago.

Though the main reason 32-bit 7 is on there is because the TV tuner cards in it don't have a driver that works with 64-bit except 64-bit Vista.

Anyway, can anyone explain when SSIM RD setting is used? Sometimes it kicks in when changing only that setting, and sometimes the file size remains the same. It says it's only used on certain presets. Does x265 have to have a preset selected for SSIM RD to be used at all?

Last edited by Dclose; 19th April 2017 at 18:41.
Dclose is offline   Reply With Quote
Old 19th April 2017, 18:47   #5211  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
https://x265.readthedocs.io/en/defau...option-ssim-rd
https://x265.readthedocs.io/en/default/presets.html
sneaker_ger is offline   Reply With Quote
Old 19th April 2017, 19:55   #5212  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Dclose View Post
Windows 7 OS uses less than a gb. Encoding mostly relies on CPU. X265 was working great until I wanted to use 10-bit. Windows 7 32-bit works as well for video on my HTPC as it did when I first put it together years ago.
CPUs run faster in x86-64 than x86-32, due to the doubled registers, even if they have the same asm features. The SIMD registers are doubled too, which can matter a lot.

Quote:
Though the main reason 32-bit 7 is on there is because the TV tuner cards in it don't have a driver that works with 64-bit except 64-bit Vista.
Driver compatibility is one of the reasons why someone would stick to an old OS. Although the power and time savings from faster encoding would probably pay for a new tuner card quickly.

Quote:
Anyway, can anyone explain when SSIM RD setting is used? Sometimes it kicks in when changing only that setting, and sometimes the file size remains the same. It says it's only used on certain presets. Does x265 have to have a preset selected for SSIM RD to be used at all?
--ssim-rd only works at --rd 3 or above. See here.

--rd 3 is enabled in --preset medium and higher. See here (referenced as rdlevel).

ssim-rd is slower, so it definitely wouldn't make sense to use below --preset medium. I'd guess it wouldn't be a decent speed/quality tradeoff until at least --preset slower.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th April 2017, 21:18   #5213  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
@BenWaggoner

Based on the name of the paramter --ssim-rd, could one infer this should only be used for SSIM and PSNR tests?

Do you feel --ssim-rd is worth using?

Last edited by brumsky; 19th April 2017 at 21:31. Reason: Typo
brumsky is offline   Reply With Quote
Old 19th April 2017, 21:22   #5214  |  Link
Dclose
Registered User
 
Join Date: Aug 2014
Posts: 50
Yes, those are there. But the preset chart doesn't show SSIM in it. And there's a tune for SSIM, but not SSIM RDO.
Quote:
Originally Posted by benwaggoner View Post
CPUs run faster in x86-64 than x86-32, due to the doubled registers, even if they have the same asm features. The SIMD registers are doubled too, which can matter a lot.

Driver compatibility is one of the reasons why someone would stick to an old OS. Although the power and time savings from faster encoding would probably pay for a new tuner card quickly.
On two desktops side by side, Win8.1-64 and Win7-32, both using i7 3770k at the same speed, 8-bit x265 speed has been similar on both of them. Maybe 10% or so slower on the one, but that one also has slower hard drives though I wouldn't think that matters when using high-quality/slow-speed settings in x265.

Using 10-bit x265 is when a huge difference is seen. Around 75% slower.

Quote:
Originally Posted by benwaggoner View Post
--ssim-rd only works at --rd 3 or above. See here.

--rd 3 is enabled in --preset medium and higher. See here (referenced as rdlevel).
That first sentence describes it more specifically. Here's why the question came up:

The paragraph for SSIM RDO says SSIM RDO is only used on presets which use RDO 3 and above.

Since presets can change, I've been leaving it on None and set everything manually. I wouldn't think a particular setting requires a preset to be used even when set manually, but when the description says "It only has effect on presets... --rd 3 and above," I raise an eyebrow and wonder.

And speaking of SSIM RDO, I don't know if it has better quality from months ago, but it seems like it.
Dclose is offline   Reply With Quote
Old 19th April 2017, 21:26   #5215  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by brumsky View Post
@BenWaggoner

Based on the name of the paramter --ssim-rdo, could one infer this should only be used for SSIM and PSNR tests?
It is --ssim-rd, not --ssim-rdo

It uses SSIM as a more advanced rate distortion metric than the default, taking longer but ideally improving perceptual quality.

Quote:
Do you feel --ssim-rdo is worth using?
I'm not clear if it is a universal win in its current implementation. So many parameters to test!
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th April 2017, 21:33   #5216  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by benwaggoner View Post
It is --ssim-rd, not --ssim-rdo

It uses SSIM as a more advanced rate distortion metric than the default, taking longer but ideally improving perceptual quality.


I'm not clear if it is a universal win in its current implementation. So many parameters to test!
That was a typo, I fixed it.

Thanks, I'll test it with my preferred settings and go from there.
brumsky is offline   Reply With Quote
Old 19th April 2017, 21:44   #5217  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by Dclose View Post
Yes, those are there. But the preset chart doesn't show SSIM in it. And there's a tune for SSIM, but not SSIM RDO.
Well, you tested - to cite you - when it "kicks in" so from that you should be able to deduct the answer.

Quote:
Originally Posted by Dclose View Post
The paragraph for SSIM RDO says SSIM RDO is only used on presets which use RDO 3 and above.

Since presets can change, I've been leaving it on None and set everything manually. I wouldn't think a particular setting requires a preset to be used even when set manually, but when the description says "It only has effect on presets... --rd 3 and above," I raise an eyebrow and wonder.
Yes, it's poorly documented.
1. Default is disabled. (== --no-ssid-rd)
2. It's not bound to having explicitly set any preset.
sneaker_ger is offline   Reply With Quote
Old 19th April 2017, 21:46   #5218  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by benwaggoner View Post
It is --ssim-rd, not --ssim-rdo
I'm not clear if it is a universal win in its current implementation. So many parameters to test!
I just ran a very quick test with my settings which are a mix of very slow and placebo... For some reason my psy-rd was set to 0. Which of course resulted in a much smaller file, 55% smaller, but took about 1 second longer. The encode looks terrible compared to my default settings.

Has anyone else run into this?
brumsky is offline   Reply With Quote
Old 19th April 2017, 22:06   #5219  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Yes, psy rd is set to 0.0 when ssim-rd is turned on.

If you want to compare quality encode to same bitrate using 2pass encoding. Not surprising if something that uses 55% less bitrate looks worse. No knowledge to be gained from that.
sneaker_ger is offline   Reply With Quote
Old 19th April 2017, 22:33   #5220  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by sneaker_ger View Post
Yes, psy rd is set to 0.0 when ssim-rd is turned on.

If you want to compare quality encode to same bitrate using 2pass encoding. Not surprising if something that uses 55% less bitrate looks worse. No knowledge to be gained from that.
Why would it disable psy rd?
brumsky is offline   Reply With Quote
Reply

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


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