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 March 2017, 18:27   #5001  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by CruNcher View Post
x265_Project

did you ever made tests how high the 10->8bit conversion overhead is for an almost perceptual banding free result, especially on high f-stop captured skyboxes internally and where the point of f-stop slope is it makes virtually no difference anymore in overall perception ?

and at which QP this merges currently depending on the overall Preset Setup in x265 or does it explicitly need AQ enabled, and how this shifts between Generations ?

Or do you know some papers this was discussed about in General @ HEVC at conferences primarily maybe by Ateme, Dolby, Technicolor, Sony, Samsung ?
Uhhh... No.
x265_Project is offline   Reply With Quote
Old 16th March 2017, 21:54   #5002  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,462
Quote:
Originally Posted by need4speed View Post
Same feeling. TV series, dark scenes and fast motion.
Noticeable improvements generally speaking but there seems to be more noise, especially in dark scenes.
Are you using --aq-mode 3? I recommend that for SDR content, as it reduces QP in dark areas.

I wonder if aq-mode also needs to be retuned for the new lambda table.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 16th March 2017, 22:02   #5003  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,462
Quote:
Originally Posted by CruNcher View Post
did you ever made tests how high the 10->8bit conversion overhead is for an almost perceptual banding free result, especially on high f-stop captured skyboxes internally and where the point of f-stop slope is it makes virtually no difference anymore in overall perception
I think all you're going to get from x265 for this scenario is the --dither option for better quality dithering when x265 is doing the color space conversion.

Can you share a sample of this content? I'm having a hard time visualizing.

It's possible that you could adapt your own lambda table if it has very different psychovisual properties.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 16th March 2017, 23:17   #5004  |  Link
need4speed
Registered User
 
Join Date: May 2002
Location: Milan, Italy
Posts: 79
Quote:
Originally Posted by benwaggoner View Post
Are you using --aq-mode 3? I recommend that for SDR content, as it reduces QP in dark areas.

I wonder if aq-mode also needs to be retuned for the new lambda table.
AQ3? Not really, it's 1080p to 1080p, avc to x265 to decrease size.
Tried aq3 in the past, somehow wasn't good as expected. Some improvement in dark areas, but the impression was more blurring.
The aq-motion currently in use is giving good results, besides it seems to disable standard aq modes (correct me if Im'm wrong).
need4speed is offline   Reply With Quote
Old 17th March 2017, 08:44   #5005  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Quote:
Originally Posted by benwaggoner View Post
I think all you're going to get from x265 for this scenario is the --dither option for better quality dithering when x265 is doing the color space conversion.

Can you share a sample of this content? I'm having a hard time visualizing.

It's possible that you could adapt your own lambda table if it has very different psychovisual properties.
you practically see that in every 10 bit UHD Demo today especially Natural light HDR Demos all are focusing on it and it's the part where especially no studio natural lighting film content benefits the most perceptually (overall stability) and all agree upon if they don't fight on the contrast side with each other .

It's crazy how even LG and Samsung buildup a whole Broadcasting Network and experimenting their.
__________________
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; 17th March 2017 at 09:27.
CruNcher is offline   Reply With Quote
Old 17th March 2017, 10:59   #5006  |  Link
Andrew Placid
Registered User
 
Join Date: Mar 2009
Posts: 10
Hi.
Is any tool for cutting/combining x265 raw stream?
Andrew Placid is offline   Reply With Quote
Old 17th March 2017, 12:10   #5007  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 4,996
mkvmerge followed by mkvextract. (If you need something graphical try SolveigMM Video Splitter or AviDemux)
sneaker_ger is offline   Reply With Quote
Old 17th March 2017, 12:53   #5008  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 286
x265 v2.3+23-97435a0870be (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+23-97435a0870be
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 17th March 2017, 12:53   #5009  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,425
Are there any "sensible low anchor" GCC optimizations you would suggest for x265?

I just compared build scripts on two different PCs, because I noticed a size difference, and found that I used
Code:
export CXXFLAGS="-march=pentium4 -mtune=generic"
for Win32 target only in one of my build environments (not for Win64 because I guess there is already an assumed similar minimum for the x86-64 platform as such). Any suggestions regarding this choice? My goal is not maximum speed for top CPU generations, rather a good compromise with high compatibility for all the hardware expected as minimum recommendable to run x265 on.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 17th March 2017, 16:13   #5010  |  Link
Andrew Placid
Registered User
 
Join Date: Mar 2009
Posts: 10
Quote:
Originally Posted by sneaker_ger View Post
mkvmerge followed by mkvextract. (If you need something graphical try SolveigMM Video Splitter or AviDemux)
I need clean raw on export. I'm not sure that extracted raw stream from mkv after cutting will 100% correct.
Andrew Placid is offline   Reply With Quote
Old 17th March 2017, 20:32   #5011  |  Link
adsun701
Registered User
 
Join Date: Dec 2016
Posts: 6
Hi there. For Video Usability Information, is it possible to add support for the new color primaries in the latest (4th) version of the HEVC standard on the ITU website, such as DCI P3? Also, can the new SMPTE ST 2085 color matrix and the ICtCp color matrix be supported?

Thanks!
adsun701 is offline   Reply With Quote
Old 17th March 2017, 20:57   #5012  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by adsun701 View Post
Hi there. For Video Usability Information, is it possible to add support for the new color primaries in the latest (4th) version of the HEVC standard on the ITU website, such as DCI P3? Also, can the new SMPTE ST 2085 color matrix and the ICtCp color matrix be supported?

Thanks!
I'll ask our development team to look at this.

Tom Vaughan
VP and GM, Video

By the way, I'm the only person who logs into Doom9 as x265_Project
x265_Project is offline   Reply With Quote
Old 17th March 2017, 21:28   #5013  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 291
Quote:
Originally Posted by LigH View Post
Are there any "sensible low anchor" GCC optimizations you would suggest for x265?

I just compared build scripts on two different PCs, because I noticed a size difference, and found that I used
Code:
export CXXFLAGS="-march=pentium4 -mtune=generic"
for Win32 target only in one of my build environments (not for Win64 because I guess there is already an assumed similar minimum for the x86-64 platform as such). Any suggestions regarding this choice? My goal is not maximum speed for top CPU generations, rather a good compromise with high compatibility for all the hardware expected as minimum recommendable to run x265 on.
At the beginning of GCC 6 release if you compile x265 without -march=pentium4 the resulting exe was not working. Now it is special workaround in cmake that adds -mpreferred-stack-boundary=2 if it detect GCC 6 and 32-bit mode. Now it is not necessary to specify -march=pentium4.

You can consider difference in speed. I've made test of encoding with command line:
x265_32 -D10 -f130 ../ducks_take_off_1080p50.y4m w.hevc

The result was:

LigH 2.3+17 version with -march=pentium4 -mtune generic
encoded 130 frames in 100.31s (1.30 fps), 8566.20 kb/s, Avg QP:38.35

Barough 2.3+23 version
encoded 130 frames in 133.73s (0.97 fps), 8562.60 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSE4.1
encoded 130 frames in 84.20s (1.54 fps), 8566.20 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSSE3
encoded 130 frames in 92.38s (1.41 fps), 8566.20 kb/s, Avg QP:38.35

If you do not specify -march=pentium4 -mtune=generic for 32-bit x265, the encoding time in 10-bit mode will be longer about 33%. Computers with Pentium 3 are very slow and with tiny memory so anyway there are not for x265 encoding.
Ma is offline   Reply With Quote
Old 17th March 2017, 21:55   #5014  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,462
Quote:
Originally Posted by adsun701 View Post
Hi there. For Video Usability Information, is it possible to add support for the new color primaries in the latest (4th) version of the HEVC standard on the ITU website, such as DCI P3? Also, can the new SMPTE ST 2085 color matrix and the ICtCp color matrix be supported?

Thanks!
I'm not seeing a lot of interest in DCI P3 as a native color space for HEVC delivery at least, but it could be useful for mezzanines.

ICtCp is used for Dolby Vision encoding, and so definitely has a significant current use case. It seems likely that the lambda table will need to be retuned for it (and probably for HDR PQ in general), and that --hdr-opt may need to be refactored for ICtCp.

I imagine Dolby would be motivated to help get MCW the necessary details.

What is SMPTE 2085 for? I see it's YDzDx Color-Difference Encoding for XYZ signals. Some sort of more efficient digital cinema color space or something?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 17th March 2017, 22:34   #5015  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by Ma View Post
At the beginning of GCC 6 release if you compile x265 without -march=pentium4 the resulting exe was not working. Now it is special workaround in cmake that adds -mpreferred-stack-boundary=2 if it detect GCC 6 and 32-bit mode. Now it is not necessary to specify -march=pentium4.

You can consider difference in speed. I've made test of encoding with command line:
x265_32 -D10 -f130 ../ducks_take_off_1080p50.y4m w.hevc

The result was:

LigH 2.3+17 version with -march=pentium4 -mtune generic
encoded 130 frames in 100.31s (1.30 fps), 8566.20 kb/s, Avg QP:38.35

Barough 2.3+23 version
encoded 130 frames in 133.73s (0.97 fps), 8562.60 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSE4.1
encoded 130 frames in 84.20s (1.54 fps), 8566.20 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSSE3
encoded 130 frames in 92.38s (1.41 fps), 8566.20 kb/s, Avg QP:38.35

If you do not specify -march=pentium4 -mtune=generic for 32-bit x265, the encoding time in 10-bit mode will be longer about 33%. Computers with Pentium 3 are very slow and with tiny memory so anyway there are not for x265 encoding.
So which build toolchain would you recommend to use on modern architectures? (and by modern I mean anything newer than Ivy Bridge, Sandy Bridge, Haswell, Skylake, Kaby Lake even) running a modern OS consumer oriented such as Windows 7, 8 or Windows 10.
pingfr is offline   Reply With Quote
Old 17th March 2017, 23:32   #5016  |  Link
adsun701
Registered User
 
Join Date: Dec 2016
Posts: 6
Quote:
Originally Posted by benwaggoner View Post
I'm not seeing a lot of interest in DCI P3 as a native color space for HEVC delivery at least, but it could be useful for mezzanines.

ICtCp is used for Dolby Vision encoding, and so definitely has a significant current use case. It seems likely that the lambda table will need to be retuned for it (and probably for HDR PQ in general), and that --hdr-opt may need to be refactored for ICtCp.

I imagine Dolby would be motivated to help get MCW the necessary details.

What is SMPTE 2085 for? I see it's YDzDx Color-Difference Encoding for XYZ signals. Some sort of more efficient digital cinema color space or something?
Yes. SMPTE ST 2085 is used for efficient processing of high dynamic range content using CIE XYZ primaries.

That also means CIE XYZ (SMPTE ST 428-1) primaries would have to be supported in Video Usability Information.
adsun701 is offline   Reply With Quote
Old 17th March 2017, 23:45   #5017  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 291
Quote:
Originally Posted by pingfr View Post
So which build toolchain would you recommend to use on modern architectures? (and by modern I mean anything newer than Ivy Bridge, Sandy Bridge, Haswell, Skylake, Kaby Lake even) running a modern OS consumer oriented such as Windows 7, 8 or Windows 10.
VS 2017 with options /GS- /GL (at least). I assume that you write about 64-bit version of x265.

My speed test was for 32-bit version of x265 and 10-bit mode. It is similar to 64-bit x265 with option --no-asm.
Ma is offline   Reply With Quote
Old 17th March 2017, 23:52   #5018  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by Ma View Post
VS 2017 with options /GS- /GL (at least). I assume that you write about 64-bit version of x265.

My speed test was for 32-bit version of x265 and 10-bit mode. It is similar to 64-bit x265 with option --no-asm.
x64 yes indeed.
pingfr is offline   Reply With Quote
Old 18th March 2017, 11:20   #5019  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,418
Quote:
Originally Posted by Ma View Post
VS 2017 with options /GS- /GL (at least). I assume that you write about 64-bit version of x265.

My speed test was for 32-bit version of x265 and 10-bit mode. It is similar to 64-bit x265 with option --no-asm.
I make little comparison with ICC, GCC 7.0 and VS 2017: VS 2017 seem produce better speed for x265.
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 18th March 2017, 12:09   #5020  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,425
I still wonder if there is a recommendation whether I should use no additional compiler flags (because CMake scripts already take enough care of that?), or may enable some basic optimizations just based on a minimum architecture suitable for x265 due to architecture details (e.g. cache dimensions). Ma's remark about P3 vs. P4 class sounds worth a thought. Regarding AMD, I would assume Athlon 64 X2 (K9 core) as low anchor. In general, I'm looking at architectures implementing at least SSE2, because I see the Phenom-II CPUs I can use as a minimum I need to support with my own builds (still trying to get rich...).
__________________

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


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