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. |
25th November 2020, 11:18 | #7861 | Link | ||
Lost my old account :(
Join Date: Jul 2017
Posts: 322
|
Quote:
Quote:
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. |
||
25th November 2020, 16:40 | #7862 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
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. |
|
30th November 2020, 08:31 | #7863 | Link |
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/ |
2nd December 2020, 02:40 | #7865 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
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. |
|
2nd December 2020, 12:40 | #7867 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
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... |
2nd December 2020, 15:50 | #7869 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
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... |
3rd December 2020, 18:30 | #7870 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
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... |
3rd December 2020, 19:25 | #7871 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
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... |
3rd December 2020, 20:50 | #7872 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
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.
|
11th December 2020, 14:51 | #7873 | Link |
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. |
11th December 2020, 17:18 | #7874 | Link | |
Registered User
Join Date: Jul 2007
Posts: 60
|
Quote:
|
|
11th December 2020, 17:34 | #7875 | Link |
German doom9/Gleitz SuMo
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 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 |
12th December 2020, 00:57 | #7877 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
Seems like an oversight or an upcoming feature. No hard 2-pass requirement for this approach. |
|
12th December 2020, 18:52 | #7879 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
Thread Tools | Search this Thread |
Display Modes | |
|
|