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 25th November 2020, 11:18   #7861  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by FranceBB View Post
Wait, so you're saying that it's using Rec709 primaries with an HLG color curve applied? That would be a pretty poor choice...
Also, if it's not and they're just displaying BT2020 on non BT2020 compatible displays that's a poor choice as well...
Quote:
Originally Posted by benwaggoner View Post
HLG is mainly being boosted for live broadcast scenarios, where there aren't colorists anyway. Premium content (movies and scripted TV) creatives and technologists aren't fans.
I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/...tion_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.

Last edited by excellentswordfight; 25th November 2020 at 11:57.
excellentswordfight is offline   Reply With Quote
Old 25th November 2020, 16:40   #7862  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by excellentswordfight View Post
I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/...tion_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.
I know exactly what you mean as I use HLG all the times at work to air in BT2020nc + color curve. The compromise is simple: the closer you get to HDR, the worse it looks on SDR BT2020 compatible monitors, the closer you get to SDR BT2020, the less dynamic range you have on those with an HDR compatible TV.
Since HLG is not a purely logarithmic curve its lower part resembles the one of an SDR curve like the Linear BT2020nc SDR 100 nits, but as it gets to the higher values (whites) it resembles more and more a logarithmic curve and therefore introduces dynamic range, hence it doesn't offer many details in the blacks, but it does offer them in the mid-white and therefore it avoids the sky to be clipped out etc. As I said, the problem is that the TVs that don't understand any color curve, but do understand BT2020 are not gonna interpret those things, hence displaying the lower values correctly but not the highlights. Of course, this is intended and it's what the BBC made it for, in fact we've been airing like this for years now.

Here's a comparison of an HDR HLG BT2020nc 600 nits shot.

On a TV which interprets both the color matrix (BT2020nc) and the color curve (HLG) and displays it as intended:


On an SDR TV 100 nits which does interpret the color matrix (BT2020nc) but totally ignores the color curve (the "not so bad" fallback as intended by the BBC specs):


On an SDR TV 100 nits which has no clue about both the color matrix and the color curve and ignores them both (totally wrong display, not acceptable, never should happen):



The first image is what we see in our monitors and it's how the whole content is graded and how it should be visualized by people at home. It's HDR, it has a dynamic range of 600 nits.
The second image is what people at home who have an old 4K TV which doesn't support HDR are gonna see. Ignoring the color curve and just interpreting the matrix isn't so bad and it's what the BBC guys were thinking about. The fact that the color curve is ignored makes the image look ok in the lower values/blacks ('cause the HLG is essentially like the Linear BT2020 SDR on the lower part) and "dull"/greyish in the higher values/whites ('cause as it goes up it embraces its logarithmic part).
Lastly, we have something that should never happen and that it's not part of the specs as not only it ignores the color curve, but it wrongly translates the values of the BT2020 so it's totally wrong. This is what happens if you try to watch a BT2020nc HLG stream on a BT709 aware only monitor (so don't do it).


My remarks:
as I said countless times in other topics here on Doom9 before, overall, the result of HLG on BT2020nc only aware monitors is not so bad and HLG makes its fair share to keep things not so unwatchable compared to PQ. In fact, while HLG can be watched on SDR BT2020 monitors, PQ can't and if you attempt to recreate a similar experiment you would get this on an HDR PQ BT2100 aware display:



and this crap on an SDR BT2020nc only aware display:



This is because PQ is a truly logarithmic curve, so blacks start very high and the "trick" doesn't work...
Of course there are caveats in HLG as not only is limited to 1000 nits maximum, but there's no added benefit for the blacks compared to a BT2020 SDR stream, while the PQ not only can achieve up to 10'000 nits but it does offer a wide range in the blacks as well (although it breaks BT2020 SDR compatibility). On top of this, the example above is done with a 600 nit file, but as we go up, the SDR picture will look more and more grey as we will be essentially pushing mid-tones up and up, so it will look worse (this is what I said at the very beginning "the closer we get to HDR, the worse it will look on BT2020 SDR monitors").
I discussed these things several times both in "General" and in "Development" with Derek and the others and I can say that I'm not too disappointed with HLG as it just works and it allows broadcasters like us to save a lot of bandwidth, especially on our beloved overcrowded Hot Bird where it's pricey.
FranceBB is offline   Reply With Quote
Old 30th November 2020, 08:31   #7863  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Wonder why there's no activity since a little over a month ago. Anyone here know the reason why, or did I missed something. Thank you in advance.

https://bitbucket.org/multicoreware/x265_git/commits/
nakTT is offline   Reply With Quote
Old 30th November 2020, 08:38   #7864  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
That happens from time to time. The mailing list is a little more active with discussions about details before commits are agreed to.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd December 2020, 02:40   #7865  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by excellentswordfight View Post
I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/...tion_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.
Yeah, HLG seems to give you one of decent SDR OR decent HDR. If you want both, you get mediocre SDR and mediocre HDR.

HLG + dynamic metadata could help that a LOT. One of the key goals/limitations of HLG was that it not require any metadata, because preserving metadata in broadcast is a massive PITA.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd December 2020, 08:25   #7866  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Quote:
Originally Posted by LigH View Post
That happens from time to time. The mailing list is a little more active with discussions about details before commits are agreed to.
Seems like the last commit was way back in the late october. Wonder why there is a fairly large gap since last commit, unlike anything before.
nakTT is offline   Reply With Quote
Old 2nd December 2020, 12:40   #7867  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by nakTT View Post
Seems like the last commit was way back in the late october. Wonder why there is a fairly large gap since last commit, unlike anything before.
Based on the mailing list, there's nothing amazing in the pipeline. I think it's safe to say that the application is in a stable status with not much active development going on. The active developers and QA people from the early days have moved on a long time ago.
__________________
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 December 2020, 13:28   #7868  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Well, then maybe someone could have time to clean up "small but annoying things" like tons of NASM warnings...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd December 2020, 15:50   #7869  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by LigH View Post
Well, then maybe someone could have time to clean up "small but annoying things" like tons of NASM warnings...
I'm not sure they possess the proper knowledge, based on what I've seen and tested myself
__________________
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 December 2020, 18:30   #7870  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by benwaggoner View Post
HLG + dynamic metadata could help that a LOT.
Ahhh!! Dynamic Metadata!! *screams out in pain*




Just joking, but yes, it would be hard to broadcast dynamically changing metadata on live feeds, especially with commercial breaks and other stuff...
FranceBB is offline   Reply With Quote
Old 3rd December 2020, 19:25   #7871  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by FranceBB View Post
Just joking, but yes, it would be hard to broadcast dynamically changing metadata on live feeds, especially with commercial breaks and other stuff...
Oh come on, you can always do the same as with the audio. Come the commercial break, turn the knob to 11
__________________
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 December 2020, 20:50   #7872  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Boulder View Post
Oh come on, you can always do the same as with the audio. Come the commercial break, turn the knob to 11
Oh, all that loudness boost stuff gets applied to the ad's audio source. Then CALM act loudness limitation gets applied to the whole audio channel. It's a weird tech arms race. CALM helped a lot at first, but once the algorithm was codified, working around it became a valuable feature.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 11th December 2020, 14:51   #7873  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
Finally a patch to be able to have more control with --scenecut-aware-qp: https://mailman.videolan.org/piperma...er/013191.html
Now "Forward masking" would be like the first implementation.

Too bad it's still restricted to 2 pass for no reason.
There should be an option to have it forward-only with single pass/CRF, only backwards would require a stat file I think.

And it's merged! https://bitbucket.org/multicoreware/...ff4f5f6e617a30

Last edited by quietvoid; 11th December 2020 at 15:57.
quietvoid is offline   Reply With Quote
Old 11th December 2020, 17:18   #7874  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by quietvoid View Post
Finally a patch to be able to have more control with --scenecut-aware-qp: https://mailman.videolan.org/piperma...er/013191.html
Now "Forward masking" would be like the first implementation.

Too bad it's still restricted to 2 pass for no reason.
There should be an option to have it forward-only with single pass/CRF, only backwards would require a stat file I think.

And it's merged! https://bitbucket.org/multicoreware/...ff4f5f6e617a30
The reason for two-pass is that it messes up with VBV rate control in single pass.
vpupkind is offline   Reply With Quote
Old 11th December 2020, 17:34   #7875  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
New uploads: x265 32-g57e0b0382

CLI changes since x265 3.4+30-g6722fce1f:

Code:
   --scenecut-aware-qp <0..3>    Enable increasing QP for frames inside the scenecut window around scenecut. Default disabled
                                 0 - Disabled
                                 1 - Forward masking
                                 2 - Backward masking
                                 3 - Bidirectional masking
   --masking-strength <string>   Comma separated values which specifies the duration and offset for the QP increment for inter-frames
replaces
Code:
   --[no-]scenecut-aware-qp      Enable increasing QP for frames inside the scenecut window after scenecut. Default disabled
   --scenecut-window <0..1000>   QP incremental duration(in milliseconds) when scenecut-aware-qp is enabled. Default 500
   --qp-delta-ref <0..10>        QP offset to increment with base QP for inter-frames. Default 5.000000
   --qp-delta-nonref <0..10>     QP offset to increment with base QP for non-referenced inter-frames. Default 6.500000
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 11th December 2020, 17:55   #7876  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
Quote:
Originally Posted by vpupkind View Post
The reason for two-pass is that it messes up with VBV rate control in single pass.
Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then.
quietvoid is offline   Reply With Quote
Old 12th December 2020, 00:57   #7877  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by quietvoid View Post
Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then.
Isn't this exactly the sort of thing that --rc-lookahead is for? Plus --gop-lookahead, --lookahead-slices, and --lookahead-threads are all doing "so, what's happening with upcoming frames" stuff.

Seems like an oversight or an upcoming feature. No hard 2-pass requirement for this approach.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 12th December 2020, 16:13   #7878  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?
Stereodude is offline   Reply With Quote
Old 12th December 2020, 18:52   #7879  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Quote:
Originally Posted by Stereodude View Post
Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?
Would be great but vpy support should be enabled too, vpy is supported by lavf but it's disabled by default. As far as I know it cannot be enabled at runtime, I've asked before but there wasn't any C++ programmer with an answer.
stax76 is offline   Reply With Quote
Old 12th December 2020, 19:18   #7880  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Best chance: ffmpeg. Although it may not pass all x265 params.
__________________

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 14:49.


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