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 26th December 2017, 13:38   #5801  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 307
x265 v2.6+22-ff02513b92c0 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 26th December 2017, 13:40   #5802  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,800
What to use for master-display when MediaInfo reports 'Display P3' ?
Code:
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : PQ
Matrix coefficients                      : BT.2020 non-constant
Mastering display color primaries        : Display P3
Mastering display luminance              : min: 0.0001 cd/m2, max: 1000 cd/m2
__________________
Hybrid here in the forum, homepage

Last edited by Selur; 26th December 2017 at 13:49. Reason: added mediainfo output
Selur is offline   Reply With Quote
Old 26th December 2017, 17:45   #5803  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 695
Quote:
Originally Posted by Selur View Post
What to use for master-display when MediaInfo reports 'Display P3' ?
Code:
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : PQ
Matrix coefficients                      : BT.2020 non-constant
Mastering display color primaries        : Display P3
Mastering display luminance              : min: 0.0001 cd/m2, max: 1000 cd/m2
from x265.readthedocs.io
Quote:
Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 26th December 2017, 17:47   #5804  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,800
Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 27th December 2017, 01:37   #5805  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 695
Quote:
Originally Posted by Selur View Post
Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which.


maybe (0.314,0.351)
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 27th December 2017, 21:22   #5806  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,513
In the docs, it says that --hdr-opt should be used with AQ-mode on. --tune grain disables AQ-mode, so is it OK to use --hdr-opt anyway or better to leave it out? Also, it is said that the input video should be 10-bit 4:2:0. Is it safe to input 16-bit video (because of processing things in Vapoursynth in 16-bit land) if the original source is 10-bit 4:2:0 and signal --input-depth 16?
__________________
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 January 2018, 05:43   #5807  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,794
Quote:
Originally Posted by Selur View Post
Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which.
DCI P3 is different in a bunch of other ways. If content is meant for display on an HDR TV, it won't use the DCI white point.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd January 2018, 05:49   #5808  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,794
Quote:
Originally Posted by Boulder View Post
In the docs, it says that --hdr-opt should be used with AQ-mode on. --tune grain disables AQ-mode, so is it OK to use --hdr-opt anyway or better to leave it out? Also, it is said that the input video should be 10-bit 4:2:0. Is it safe to input 16-bit video (because of processing things in Vapoursynth in 16-bit land) if the original source is 10-bit 4:2:0 and signal --input-depth 16?
--tune grain may not be appropriate to many HDR sources anyway. It's not a panacea. For content that doesn't need --tune-grain you waste a lot of bits to get the same output quality.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd January 2018, 15:23   #5809  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,791
x265 2.6+24-69cfe46e8a3b – merge with stable

Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:

Code:
   --radl <integer>              Number of RADL pictures allowed in front of IDR. Default 0

(  --analysis-reuse-mode <string|int>  removed )
   --analysis-save <filename>    Dump analysis info into the specified file. Default Disabled
   --analysis-load <filename>    Load analysis buffers from the file specified. Default Disabled
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd January 2018, 18:24   #5810  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,794
Quote:
Originally Posted by LigH View Post
x265 2.6+24-69cfe46e8a3b Ė merge with stable

Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:
I hadnít dealt with RADL before. Based on some documentation, it sounds like it relates to the frames before an IDR in an open GOP. That it requires a fixed IDR cadence suggests a pretty specific use case, like broadcast stream switching.

Anyone have some context to offer?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd January 2018, 19:55   #5811  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by benwaggoner View Post
I hadnít dealt with RADL before. Based on some documentation, it sounds like it relates to the frames before an IDR in an open GOP. That it requires a fixed IDR cadence suggests a pretty specific use case, like broadcast stream switching.

Anyone have some context to offer?
While an Instantaneous Decoder Refresh (IDR) picture cannot depend on any pictures before it in decoding order (nor can any pictures that follow the IDR picture), there is a concept of leading pictures that is allowed. Random Access Decodable Leading (RADL) B pictures precede the IDR in presentation order and immediately follow it in decoding order. This allows the encoder to exploit the benefits of prediction from a following frame (in presentation order). So, if there is a scene change just prior to the end of a Group of Pictures (GOP), x265 can use RADL B pictures referencing the next IDR picture (in the subsequent GOP) to get the benefits of prediction.
x265_Project is offline   Reply With Quote
Old 2nd January 2018, 20:01   #5812  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,800
What would happen if one sets radl to max key int?
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 2nd January 2018, 20:14   #5813  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by Selur View Post
What would happen if one sets radl to max key int?
I realize you're joking, but for clarity...

**Range of values: Between 0 and `--bframes`
x265_Project is offline   Reply With Quote
Old 2nd January 2018, 21:40   #5814  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,794
Quote:
Originally Posted by x265_Project View Post
While an Instantaneous Decoder Refresh (IDR) picture cannot depend on any pictures before it in decoding order (nor can any pictures that follow the IDR picture), there is a concept of leading pictures that is allowed. Random Access Decodable Leading (RADL) B pictures precede the IDR in presentation order and immediately follow it in decoding order. This allows the encoder to exploit the benefits of prediction from a following frame (in presentation order). So, if there is a scene change just prior to the end of a Group of Pictures (GOP), x265 can use RADL B pictures referencing the next IDR picture (in the subsequent GOP) to get the benefits of prediction.
So, it's sort of an enhanced Open GOP that can apply to the last frames in the prior GOP, not just the first frames in the new GOP?

I can see how that could reduce keyframe strobing and improve efficiency with fixed cadence encodes. Are there any downsides to it? Any compatibility issues?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd January 2018, 03:53   #5815  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,367
It actually sounds like a feature for closed GOP, because the importance of closed v.s. open GOP is during decoding, frames that are decoded after an IDR frame can be presented before it while only requiring data (in the decoded picture buffer) from the current GOP. Any RADL B frames would simply be dropped when seeking to the IDR frame.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 4th January 2018, 03:48   #5816  |  Link
fisherwei
Registered User
 
Join Date: Sep 2017
Posts: 3
from 2.6(+22 and +24), it seems some problem in my computer.

Code:
y4m  [info]: 1920x800 fps 24000/1001 i420p10 unknown frame count
raw  [info]: output file: D:\x265-workspace\output\harrypotter2001\00001.1080.hevc
x265 [info]: HEVC encoder version 2.6+24-69cfe46e8a3b
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: Turning on repeat-headers for HDR compatibility
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 2 / wpp(25 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge         : star / 25 / 5 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 1 / 360 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset                     : -2 / -2
x265 [info]: Intra 32x32 TU penalty type         : 1
x265 [info]: Lookahead / bframes / badapt        : 60 / 9 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 5 / on / off
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-19.0 / 0.70
x265 [info]: VBV/HRD buffer / max-rate / init    : 100000 / 100000 / 0.900
x265 [info]: tools: limit-modes rd=4 ssim-rd rdoq=2 psy-rdoq=8.00 limit-tu=3
x265 [info]: tools: signhide tmvp b-intra lslices=4 deblock(tC=-1:B=-1)
Error: fwrite() call failed when writing frame: 77, plane: 0, errno: 32
Output 82 frames in 139.43 seconds (0.59 fps)
DONE

2.5 is OK, and sometimes 2.6 is OK too.

Anybody know what's wrong?

Windows 10 64bit

Update:
2.6+17 was OK.
2.6+22/+24 was wrong.
source stream from vspipe.exe

Last edited by fisherwei; 4th January 2018 at 08:05. Reason: update
fisherwei is offline   Reply With Quote
Old 4th January 2018, 12:07   #5817  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
Quote:
Originally Posted by fisherwei View Post
from 2.6(+22 and +24), it seems some problem in my computer.
Your options are far from default -- could you post your command line to easier reproduce the problem.
Ma is offline   Reply With Quote
Old 4th January 2018, 16:12   #5818  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by Asmodian View Post
It actually sounds like a feature for closed GOP, because the importance of closed v.s. open GOP is during decoding, frames that are decoded after an IDR frame can be presented before it while only requiring data (in the decoded picture buffer) from the current GOP. Any RADL B frames would simply be dropped when seeking to the IDR frame.
Yes, if someone was seeking to (starting playback from) the IDR frame, any RADL B frames (which come after the IDR frame in decoding order) would be dropped, as they represent frames that come before the IDR frame in presentation order.

The term "current GOP" can be a bit confusing when we're talking about leading pictures. RADL B pictures require the IDR picture (the first frame of the next GOP) as a reference. But the decoder knows this already, as the NAL unit type of the IDR picture will indicate that leading pictures (from the previous GOP) follow the IDR picture in decode order (it will be an IDR_W_RADL as opposed to an IDR_N_LP - IDR with no leading pictures).
x265_Project is offline   Reply With Quote
Old 4th January 2018, 16:45   #5819  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 307
x265 v2.6+26-b4edf9b44d23 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
[EDIT]
DL Link to v2.6+26-b4edf9b44d23 have been fixed.

Last edited by Barough; 6th January 2018 at 18:02.
Barough is offline   Reply With Quote
Old 4th January 2018, 23:12   #5820  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
Am I right in presuming that the latest "Meltdown" security issue, and the implemented KPTI fix, will not impact x265 much or at all?
From what I understand, its only multiple/regular kernel calls/ints that will cause a slowdown (TLB flush), and presumably x265 doesnt do many? (only file read and writes + text output)
Although for me at least, I have Haswell (soon to be 8700k), so it has PCID, which will mitigate TLB flushes.

Cheers
Divxmaster
divxmaster 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 00:11.


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