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 28th October 2016, 20:21   #4361  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,926
Quote:
Originally Posted by x265_Project View Post
Yes. We're always working on 2 things...
1 - improve compression efficiency (achieve the highest possible visual quality at any given bit rate; or, stated differently, achieve the lowest possible bit rate for any target level of visual quality).
2 - improve performance (without compromising compression efficiency, make x265 go faster). We can improve performance algorithmically, through smarter decisions that avoid unnecessary computations, and we are always looking to optimize x265 for the platforms it runs on (avoiding any bottlenecks).

Of course, x265 will benefit from advances in CPU performance from Intel, AMD, IBM and ARM. For example, the next generation of Intel Xeon chips (the Skylake Xeons, code-named Purley) will include AVX3 instructions which operate on 512 bits of data per clock cycle. But there are other possible ways to accelerate x265, and we're working on them.
Hopefully they will be better then your decoder optimizations on release
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004
CruNcher is offline   Reply With Quote
Old 29th October 2016, 09:17   #4362  |  Link
gamebox
Registered User
 
Join Date: Nov 2011
Posts: 66
@Boulder:

Deblocking filter in HEVC, in my opinion, should always be set lower than what you've been using in H264. For example, I used values of -1 (sometimes -2) in H264, but now use -2 and also, often, -3 in HEVC. Reducing strength of this filter does increase visibility of coding artifacts like blocking and (even more pronounced) ringing, but they seem to be less disturbing and present in smaller areas than in H264, possibly because of different block sizes. I also prefer sharper, detail-rich image with some artifacts better than completely smooth one, especially as newer kind of video content (HD) is often recorded differently than older media and it helps reducing visibility of artifacts (objects in foreground in modern media content are very sharp/focused with a smooth/unfocused/simplified background (that means lower visual complexity and better optimization for low bitrate encoding)). I haven't tried encoding with deblock filter completely off, and some people advised to keep it on at all times anyway, but set to lowest value (-6) if desired.
gamebox is offline   Reply With Quote
Old 29th October 2016, 13:12   #4363  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by Dclose View Post
My current test sample barely has any motion in it, and the file is bigger with 2 Intra than with 1 Intra. Maybe the small amount of motion on the screen draws my attention to the blur more, but even when only a character's mouth is moving, the entire video makes me want to rub my eyes of a haze.
Just a shot in the dark here but are the sources interlaced? I've seen the same thing when the source is not properly deinterlaced.
brumsky is offline   Reply With Quote
Old 30th October 2016, 18:56   #4364  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v2.1+36-d216cb9b3b47 (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)
Barough is offline   Reply With Quote
Old 30th October 2016, 21:26   #4365  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Me too:

x265 2.1+36-d216cb9b3b47 (MSYS/MinGW, GCC 6.2.0, 32 + 64 bit, 8+10+12 bit single EXE + DLL and multi-lib EXE)

More advanced options:

Code:
   --[no-]opt-qp-pps             Discard optional HRD timing information from the bistream. Default enabled
   --[no-]opt-ref-list-length-pps  Discard optional HRD timing information from the bistream. Default enabled
   --[no-]multi-pass-opt-rps     Enable storing commonly RPS in SPS in multi pass mode. Default disabled
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 30th October 2016, 22:56   #4366  |  Link
Dclose
Registered User
 
Join Date: Aug 2014
Posts: 50
Quote:
Originally Posted by brumsky View Post
Just a shot in the dark here but are the sources interlaced? I've seen the same thing when the source is not properly deinterlaced.
Nope. And I went through part of it frame by frame.

Also, as for size, I've been doing testing with 1 minute from The Matrix lately. People mostly standing around talking, lots of fine textures and a decent amount of grain.

Using Hybrid, 1080p, CRF 20... Intra/Inter 2 is slightly bigger file than Intra/Inter 1. I did the test again to double check, CRF23, again Intra 2 is slightly bigger. I thought it's supposed to be the opposite.
Dclose is offline   Reply With Quote
Old 31st October 2016, 15:51   #4367  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by Dclose View Post
Nope. And I went through part of it frame by frame.

Also, as for size, I've been doing testing with 1 minute from The Matrix lately. People mostly standing around talking, lots of fine textures and a decent amount of grain.

Using Hybrid, 1080p, CRF 20... Intra/Inter 2 is slightly bigger file than Intra/Inter 1. I did the test again to double check, CRF23, again Intra 2 is slightly bigger. I thought it's supposed to be the opposite.
It's hard to say, it's most likely getting more fine detail. Can you share a small sample file of the motion blur you are talking about? Maybe of the source as well, I'd like to see if I get the same effects.

Also, what are you full settings?
brumsky is offline   Reply With Quote
Old 1st November 2016, 03:26   #4368  |  Link
nandaku2
Registered User
 
Join Date: Jan 2014
Posts: 45
Quote:
Originally Posted by Boulder View Post
A question regarding recursion skip: it is disabled in --tune grain. How big a difference would it theoretically make (i.e. how important it is in keeping grain) compared to enabling it? It makes a really big difference performance-wise at least in --preset slower.
Since it was first introduced, rskip has now been optimized significantly to prevent loss of detail. It is definitely worth testing to see if we could re-enable it in tune grain and improve speed.
nandaku2 is offline   Reply With Quote
Old 1st November 2016, 07:24   #4369  |  Link
Kavitha
Registered User
 
Join Date: Aug 2016
Posts: 4
Quote:
Originally Posted by brumsky View Post
@x265_project

Thank you guys so much! I've been wishing for a option like this for some time.

A few quick tests show a performance drop of ~.5% with a file size ~2% smaller. This is comparing inter 1 vs inter 4 + limit tu 1. Without limit tu, inter 4 is ~ 20% slower.

So far I see no visible quality difference.

Great job!!!

Could you explain the differences between limit tu 1 + 2 a bit more in depth, please?

TU node in quad tree is traversed by depth first search process to find the best TU partition.
Aim of limit-tu feature is to limit the depth search range. By limiting the depth search range, the encoder can early exit thus improving the performance with minimal compromise in quality.
In limit tu 1, the depth search is limited using breath first search traversing. Here all partitions of current depth are processed before deciding if next depth should be traversed
In limit tu 2, depth search is limited by allowing the first partition to recurse fully to maximum allowed depths
(--tu-inter/intra-depth value determines the maximum TU depth the encoder is allowed to traverse) and limits the depth search of other partitions by reusing the maximum best depth that the first partition chooses.
Since --tu-inter-depth 1 allows the encoder to traverse only upto current depth, limit-tu has no scope to optimize the depth range. Hence limit-tu is enabled only if tu-inter-depth > 1
From the test results:
performance : limit-tu 2 > limit-tu 1
quality : limit-tu 1 > limit-tu 2
Kavitha is offline   Reply With Quote
Old 1st November 2016, 12:24   #4370  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Is 'multi-pass-opt-rps' only needed during the 1st pass of a 2pass encoding?
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 1st November 2016, 15:12   #4371  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Dclose View Post
The difference between Intra 1 and 2 isn't as pronounced as between Coding Unit 32 and 64. I encoded many hours of (animated) video at 1fps using CU64 to then watch it and think my media player had a blur filter turned on.
Note that your --ctu size implicitly sets the max tu size, and thus the starting point for further recursion to smaller tu sizes set by tu-inter/intra.

So, the difference between ctu 64 tu-inter/intra 2 and ctu 32 tu inter-intra 1 is that the first gives the option of a 32x32 tu. Both can down to 16x16 and 8x8.

I strongly suspect that some of the benefit of a smaller ctu with faster presets is that they allow smaller tu sizes. The default CTU 64 an tu inter/intra of 1 only gives the option of 32x32 and 16x16 tu sizes. Comparing ctu size impact on its own merits should probably use tu-inter 4 and tu-intra 4 to make sure that the minimum tu size is always 4x4.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st November 2016, 15:16   #4372  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Dclose View Post
Using Hybrid, 1080p, CRF 20... Intra/Inter 2 is slightly bigger file than Intra/Inter 1. I did the test again to double check, CRF23, again Intra 2 is slightly bigger. I thought it's supposed to be the opposite.
Comparing quality and ABR changes together is quite challenging. To really understand the impact of quality changes from parameters, I strongly recommend use of a 2-pass VBR encode with the alternate encodes parameters all using the same --bitrate, --vbv-maxrate, and, --vbv-buffsize. That way we are only comparing the quality @ bitrate. Once we figure out optimal settings for that, we can then work back to the right CRF.

It is completely predictable that different parameters can have different optimal CRF values to hit the same perceptual quality or the same ABR.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st November 2016, 15:20   #4373  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by gamebox View Post
@Boulder:

Deblocking filter in HEVC, in my opinion, should always be set lower than what you've been using in H264. For example, I used values of -1 (sometimes -2) in H264, but now use -2 and also, often, -3 in HEVC. Reducing strength of this filter does increase visibility of coding artifacts like blocking and (even more pronounced) ringing, but they seem to be less disturbing and present in smaller areas than in H264, possibly because of different block sizes. I also prefer sharper, detail-rich image with some artifacts better than completely smooth one, especially as newer kind of video content (HD) is often recorded differently than older media and it helps reducing visibility of artifacts (objects in foreground in modern media content are very sharp/focused with a smooth/unfocused/simplified background (that means lower visual complexity and better optimization for low bitrate encoding)). I haven't tried encoding with deblock filter completely off, and some people advised to keep it on at all times anyway, but set to lowest value (-6) if desired.
Note that this is really an alpha/beta pair, and that using different numbers is supported and often effective. I've seen some promising results with --deblock -1:1 for example. That reduces the strength of the deblocking (-1) but increases how much it gets used (+1).
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st November 2016, 15:25   #4374  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Boulder View Post
One more thing in addition to this: what about deblocking, does disabling it reduce the smoothing effect or will it cause ill effects elsewhere? I've been unable to determine it by a frame-by-frame comparison.
It can be complex. Less deblocking means less compression efficiency, so at the same bitrate, it will push up QP, which might trigger more SAO. Turning off both may reduce smoothness but increases QP. Thus at low-moderate bitrates true details can be lost, perhaps psychovisually balanced by the increased false detail of DCT "sizzle" (mild ringing and maybe blocking).

Again, I recommend making these comparisons at fixed ABR, or even CBR, since using CRF is going to yield simultaneous changes in ABR and perceptual quality, and we're better off understanding first how changes impact quality at the same bitrate.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st November 2016, 15:51   #4375  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by Kavitha View Post
TU node in quad tree is traversed by depth first search process to find the best TU partition.
Aim of limit-tu feature is to limit the depth search range. By limiting the depth search range, the encoder can early exit thus improving the performance with minimal compromise in quality.
In limit tu 1, the depth search is limited using breath first search traversing. Here all partitions of current depth are processed before deciding if next depth should be traversed
In limit tu 2, depth search is limited by allowing the first partition to recurse fully to maximum allowed depths
(--tu-inter/intra-depth value determines the maximum TU depth the encoder is allowed to traverse) and limits the depth search of other partitions by reusing the maximum best depth that the first partition chooses.
Since --tu-inter-depth 1 allows the encoder to traverse only upto current depth, limit-tu has no scope to optimize the depth range. Hence limit-tu is enabled only if tu-inter-depth > 1
From the test results:
performance : limit-tu 2 > limit-tu 1
quality : limit-tu 1 > limit-tu 2
Thank you for the explanation, that was exactly what I was looking for!
brumsky is offline   Reply With Quote
Old 2nd November 2016, 20:32   #4376  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by nandaku2 View Post
Since it was first introduced, rskip has now been optimized significantly to prevent loss of detail. It is definitely worth testing to see if we could re-enable it in tune grain and improve speed.
I did some tests with the noisy, blocky Star Trek TOS stuff, resized to 720p. I cannot tell which one looks better what comes to comparing to the original, because it seems to depend on the frame. I might even say that with rskip it's generally better and considering the cost in heavily increased encoding time, I'll use rskip also with --tune grain.

However, I need to make some more tests with a better source such as The Hobbit.

While I'm writing, I'd like to thank for the much improved encoder and --tune grain. It now looks like I can switch to x265 for good. Hopefully I can get me an Intel NUC that supports HW decoding of 10-bit HEVC soon
__________________
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 2nd November 2016, 20:33   #4377  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by benwaggoner View Post
Note that this is really an alpha/beta pair, and that using different numbers is supported and often effective. I've seen some promising results with --deblock -1:1 for example. That reduces the strength of the deblocking (-1) but increases how much it gets used (+1).
Thanks, I ended up using -6:1 to make only light deblocking but more often than with -6:-6.
__________________
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 November 2016, 04:26   #4378  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Quote:
Originally Posted by Kavitha View Post
performance : limit-tu 2 > limit-tu 1
quality : limit-tu 1 > limit-tu 2
How different is the quality between 1 and 2, at least in regards to your reckoning? Is using 2 worth it over none, and over 1?
burfadel is offline   Reply With Quote
Old 3rd November 2016, 05:53   #4379  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Damn. --tune grain is amazing.

With a very grainy movie I was able to achieve a 2:1 reduction versus x264 with no quality loss visible during motion. Still frame a:b comparison reveals differences, but nothing earth shattering.
Blue_MiSfit is offline   Reply With Quote
Old 3rd November 2016, 19:27   #4380  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
Hi....what would be faster in encoding?? Core i7-4790K or 2xXeon E5-2670 (with ASUS Z9PE-D8 WS motherboard and 64GB DDR3 RAM)?
jlpsvk 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 17:16.


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