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 21st March 2017, 09:49   #5041  |  Link
need4speed
Registered User
 
Join Date: May 2002
Location: Milan, Italy
Posts: 79
Quote:
Originally Posted by LigH View Post
No, since v2.3+22 it's default.
Ok great cause St least for my personal setup this has been a good step forward.

Inviato dal mio GT-N7100 utilizzando Tapatalk
need4speed is offline   Reply With Quote
Old 21st March 2017, 17:20   #5042  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
The latest commit seems to put --limit-tu 4 in the presets slower and veryslow. Previously it was mentioned that --limit-tu 3 would provide good subjective quality while increasing performance, so has there been some more testing regarding the option?
__________________
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 21st March 2017, 18:10   #5043  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by Boulder View Post
The latest commit seems to put --limit-tu 4 in the presets slower and veryslow. Previously it was mentioned that --limit-tu 3 would provide good subjective quality while increasing performance, so has there been some more testing regarding the option?
Yes. Tests showed a ~20% performance increase with almost no detectable impact to quality.
  Reply With Quote
Old 21st March 2017, 18:34   #5044  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Shevach View Post
Thanks for a prompt reply. Frankly speaking i meant both min/max_display_mastering_luminance (signaled in MasteringDisplayColorVolume SEI) and MaxCLL/MaxFall (signaled in Content Light Level SEI).
What's about MaxCll? After encoding this value might be different from that obtained from source yuv or tiff.

In my opinion, lossy encoding may cause non-negligible changes in min/max_display_mastering_luminance and MaxFall/MaxCll.
Why? If a quantization rounding offset is less 0.5 in an encoder then reconstructed pixels tend to be smaller (leakage of energy). If the quantization rounding offset is above 0.5 then an opposite effect takes place. The quantization rounding offset is like a pump which either inhale or exhale "energy".
Consequently, after encoding MaxFall/MaxCll may differ from those in the original file.
You are entirely correct that encoding can reduce the MaxFALL and particularly MaxCLL from the source. However, industry standard behavior is to retain the values from the source as indicative of creative intent. Also, with adaptive bitrate switching, different streams could have different encoded metadata values. But Displays don't like mid-stream metadata value changes, so the same values should be used for all bitrates.

THAT said, devices don't make heavy use of MaxFALL and MaxCLL in practice, because knowing what the brightest frame and brightest pixel across an entire movie isn't that useful. Dynamic metadata ala Dolby Vision and SMPTE 2094-40 are much more useful for tone mapping.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd March 2017, 00:07   #5045  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,926
MaxFALL and MaxCLL play no role in Hardware protection or could they be used to save energy more efficient per frame improving overheating statistics and overall Hardware output efficiency ?


Though not sure for what that would help you need those data in realtime and some heat buffer that corrects the latency before you need to emergency shutdown, HDR is pretty interesting in those regards how smart (adaptive) the Display Hardware must react to not get damaged or MTBF rising heavily whiich in the end also defines the end result of what you gonna percept overall

HDR + VFR overall seem also to have the potential to be very efficiently combined especially 1 compensating the others higher power output needs

Especially Nvidia and AMD currently seem to be very interested in pushing this forward in their Labs currently

HDR generates some interesting drawbacks in terms of energy output savings that have been done over the years in power consumption it lowers the output efficiency again or compensates some of the advantages done in the Mobile Power Saving space pretty rapidly.

Power Supplier are surely pretty happy about this development
__________________
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

Last edited by CruNcher; 22nd March 2017 at 00:39.
CruNcher is offline   Reply With Quote
Old 22nd March 2017, 13:51   #5046  |  Link
jairovital
Registered User
 
Join Date: Sep 2010
Posts: 2
I'm having problem with non English filename using StxRip on Windows 7 64, Codepage 1252/850.
Running avs2pipemod64.exe (version 1.1.1 - Aug 2016) it gives:

Code:
avs2pipemod[error]: Import: couldn't open "B:\Programas\StaxRipTemp\S? corro_temp\S? corro.x265 - MKV - Super Low 26 - AAC - 22050 Hz.avs"
Talking with its author, Stax76, he said that since it works with x264, probably x265 could be the cause of problem, once we need to implement an avifile/avisynth/vapoursynth reader. "All of Rigaya's hardware encoders have direct support for avs and vpy, x264, so it supports at least avs".

I suspected avs2pipemod was the cause of problem, but it seems not.

Greetings from me and Stax76.
jairovital is offline   Reply With Quote
Old 22nd March 2017, 15:28   #5047  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v2.3+24-a0eee4b41185 (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+24-a0eee4b41185
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 23rd March 2017, 20:40   #5048  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
msvc comiled binaries

Could someone please post the latest build while using VS 2017?

Thanks!

Last edited by brumsky; 23rd March 2017 at 20:47.
brumsky is offline   Reply With Quote
Old 23rd March 2017, 20:49   #5049  |  Link
Leo 69
Registered User
 
Join Date: Nov 2004
Posts: 227
Quote:
Originally Posted by brumsky View Post
Could someone please post the latest build while using MSVC 2017?

Thanks!
http://www.mediafire.com/file/1g95yo..._vs2017-AVX.7z

http://www.mediafire.com/file/4nsvdb...vs2017-AVX2.7z
Leo 69 is offline   Reply With Quote
Old 23rd March 2017, 20:50   #5050  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
Quote:
Originally Posted by brumsky View Post
Could someone please post the latest build while using VS 2017?

Thanks!
If you don't see latest build on page www.msystem.waw.pl/x265 please refresh the page (F5 should help).
Ma is offline   Reply With Quote
Old 23rd March 2017, 21:01   #5051  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by Leo 69 View Post
Awesome thank you both!!
brumsky is offline   Reply With Quote
Old 23rd March 2017, 22:28   #5052  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by brumsky View Post
Awesome thank you both!!
I can only agree and applaud with both hands.

At the moment it is... "un-wise" to use a GCC built x265 binary.

VS2017 is (at least for now) the way to go.
pingfr is offline   Reply With Quote
Old 23rd March 2017, 22:49   #5053  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
Why is that pingfr?

GCC compiles mite be slow for 10bit encodes but thats not the case for 8bit.

Personally so am i not interested in 10bit due 2 that its not especially compatible with hardware.

Sent from my Samsung Galaxy S7 edge via Tapatalk
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else.
Barough is offline   Reply With Quote
Old 23rd March 2017, 23:09   #5054  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by pingfr View Post
The differences are subtle as the preset "increases"...
Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.



With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 23rd March 2017 at 23:12.
LigH is offline   Reply With Quote
Old 23rd March 2017, 23:58   #5055  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by LigH View Post
Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.
I full agree about using percentage ratios.

Has anyone tried doing profile-driven optimizations for x265? I don't know if it would help much given all the assembler, but 5% on veryslow with a different compiler suggests there may be some juice to squeeze out there still.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th March 2017, 00:03   #5056  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
An analytic with a lot of spare time would probably check: Which features are only enabled in slower presets, and are they still in C code? Most probably, as I would assume they are not primitive operations, thus rather hard to implement in lower level languages.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 24th March 2017, 00:42   #5057  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by LigH View Post
Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.



With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.
Thanks for making that table re-cycling the data I pasted a few days ago, glad it served a purpose.

Although it is missing the placebo preset.

I just can't be bothered waiting 45 minutes to run each placebo encodes.

Also note it is important to remind you these tests were ran using 2.3+23, it is worth mentioning the latest commit applies limit-tu to slower, veryslow presets for an up to 20% increase in FPS according to the commit, this most likely has skewed the presented data here, it has to be seen whether the delta remains and even there we're talking about 0.15 of 1 fps.
pingfr is offline   Reply With Quote
Old 24th March 2017, 01:26   #5058  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Don't be sad; I do not even have any AVX2 capable processor available.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 24th March 2017, 10:15   #5059  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by LigH View Post
Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.



With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.

What exactly is that ratio percent in the last row? In the first comparison, one encode is faster than the other by 0.83%, which you have called as a 100.83% ratio.

So in all the comparisons, to know by how much one is faster than the other, you have to ignore the "100", and whatever remains is the percentage difference in speed.

Isn't that the relevant metric? By what percent one is faster than the other?
aymanalz is offline   Reply With Quote
Old 24th March 2017, 10:17   #5060  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by pingfr View Post
Thanks for making that table re-cycling the data I pasted a few days ago, glad it served a purpose.

Although it is missing the placebo preset.

I just can't be bothered waiting 45 minutes to run each placebo encodes.
You could run the placebo encodes on a very short clip, maybe trimmed from your original clip.
aymanalz 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 18:01.


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