welljay cheyne zymran

[Edilma Howard]

Windows version of Netflix in particular is extremely dark in HDR mode. I would like to increase brightness, along with some additional calibration adjustments. However, the video adjustments available in Intel Command Centre do not have any effect, even when the "Automatically Process Video to Enhance it" option is selected in Windows Display Settings. However, if I download a netflix video rather than stream it, the Intel Command Centre does allow me to adjust video. Is this a known issue, and is a fix available to resolve this?

Taking into consideration that the tool is working locally, it indicates that the Graphics controller, drivers, and Windows are working properly together. We would appreciate the details requested below to try to narrow down the issue experienced when streaming.

I save the video locally using the App version of netflix. This is the only recognised way to download netflix to windows devices. Any video downloaded, whether it's HDR Ultra HD or standard definition, allows adjustment to be done through Graphics Command Centre. As soon as streaming however, graphics adjustment only works for SDR content.

With the details gathered at this point, we consider that the behavior experienced might be related to the Netflix app or the Netflix streaming requirements since the issue is only experienced when streaming.

It should be noted that as well as 'Play HDR Games and Apps' option being selected, the 'Automatically Process Video to Enhance it' option is also selected in the Windows Display Video Playback Settings. This is as instructed by the Intel Graphics Command Centre.

1 - The settings I use are shown in the attached screenshot. I find it easiest to test whether the settings are applying themselves to the streaming video by simply adjusting the brightness slider setting up and down. The video should go from light to dark very noticeably when this is being adjusted.

2 - Yes, I use the Netflix app to download a video. If you are replicating the test, it just needs to be a HDR format video. I used an episode from Stranger things season 3, or Altered Carbon Season 1

3 - When streaming a Netflix video, I do just open Netflix app and play a HDR video (such as one of the 2 examples I mentioned above). However, before I do this, I make sure to go into the windows display settings and ensure "Play HDR Games & Apps" is checked, along with "Automatically process video to enhance it" in the Video Playback Settings. I will attach 2 additional screenshots after this message showing these settings.

The option in Windows needs to be enabled as you pointed out, but we noted that it is necessary to create a new profile to modify the settings. Please confirm if you are using a custom video profile in the IGCC.

I'm having the same issue described here. One thing to note is that the sample video in the Windows HDR settings of the guy walking on the cruise ship shows the changes made in the Intel Graphics Control Center. But none of the videos played by browsers such as Edge and Chrome, including Amazon Video, Netflix, YouTube show any differences. This is very annoying and can't be a unique issue to a few people. Please help Intel.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

While 2018 was the year AV1 became known, 2020 will be the year that AV1 became interesting, primarily because of three developments. First, in early 2020, AV1-enabled smart TVs hit the market, right on the 2-year schedule announced back in 2018 by the Alliance for Open Media (AOMedia). Second, over the past two years, encoding times for the AOMedia AV1 codec have dropped from about 2500x real time to about 2x slower than HEVC. Finally, the emergence of third-party AV1 codecs have increased both the quality and encoding speed of the AV1 codec.

My focus for the review was developer-level products for integration into an existing encoding workflow as opposed to commercial cloud encoding or standalone encoders. I tested four separate AV1 encoders:

When I last tested AV1 codecs, I used four 5-second test clips because encoding times were so lengthy. This time, I started with 10-second clips and learned that AV1 encoding times had dropped significantly. So I expanded the test list to 16 clips in five categories, as shown in Table 1.

To produce the data necessary for the rate-distortion curves and BD-Rate statistics shown later, I needed four encodes for each clip. To choose the data rates, I targeted a VMAF range of between 85 and 95, which is the target for the highest-quality streams produced in most encoding ladders. The only exception were the gaming clips, which were all 60 fps and so dynamic as to require 10Mbps-plus to achieve the same quality levels. So I encoded at 5,750Kbps at the top rung and scaled down from there.

Virtually all codecs include presets because streaming producers have different goals and business models. Some may want to minimize encoding time and costs by accepting slightly lower quality. Some may want the utmost quality regardless of encoding time or cost. Presets allow each streaming producer to optimize for its particular requirements.

AV1 has nine presets selected via the cpu-used switch. My goal was to choose the most commercially reasonable preset that most producers would use, not the highest-quality AV1 preset. To identify this preset, I encoded 10 of the test files with FFmpeg/libaom from five genres to all presets and recorded encoding time, average quality, and low frame quality, the last of which is often useful to spot transient quality issues. I plotted these values as a percent in Figure 1, with red signifying encoding time; blue, average quality; and yellow, low frame quality.

As an example, at cpu-used 3, the encoder averaged 99.53% of average quality, 99.39% of low frame quality, and 6.4% the encoding time of the highest-quality preset, cpu-used 0. Encoding with cpu-used 2 would triple encoding time with minimal additional quality, while cpu-used 4 would increase encoding speed by about 33% with minimal quality loss.

Interestingly, SVT-AV1 showed a different quality/encoding time tradeoff, with an unexpected quality bump at cpu-used 7, then a drop in quality through cpu-used 2 (see Figure 2). Although the jump from cpu-used 3 to cpu-used 2 tripled encoding time, it also boosted quality from 95.07% to 99.72%, an increase most producers would likely find reasonable. So I encoded all SVT-AV1 clips using preset 2, although I also tested preset 7 in the performance tests discussed later.

x264 and x265 use presets with names like ultrafast, superfast, medium, slow, and placebo. Typically, I recommend the slow preset for x265, which offers a significant boost in low frame quality over the default medium preset and roughly doubles encoding time. However, in the x265 files produced for these comparisons, I encoded using the veryslow preset to optimize quality, although that boosted encoding time significantly. To provide a sense of this, I tested both the slow and veryslow presets in the performance tests discussed later.

Since x264 is orders of magnitude faster to encode than either x265 or any of the AV1 codecs, I used the veryslow preset, which typically offers slightly more quality than placebo in a fraction of the encoding time.

Tuning refers to the practice of applying tuning parameters to the command string to remove encoding techniques like adaptive quantization that are known to reduce metric scores. Tuning for metrics is generally well-established for x264 and x265, although not universally used. For example, when benchmarking AV1 against other codecs in recent analyses, neither Facebook nor Netflix tuned, preferring to use their actual production parameters. Nonetheless, because features like adaptive quantization are enabled by default for x264 and x264, I tuned when producing files to be rated via objective metrics.

The AV1 codec also has tuning mechanisms, with tuning for peak signal-to-noise ratio (PSNR) and SSIM available for a few versions, and tuning for VMAF relatively new. However, none of the AV1 codecs I tested enabled adaptive quantization by default, so what these tuning mechanisms were actually doing was unclear. Regarding tuning for VMAF, a Google engineer described this as "adaptive prefiltering (sharpening) of frames prior to standard encode. That boosts VMAF scores up to 30% in BD-rate terms, but of course, PSNR will not be very good."

Unlike tuning for PSNR and SSIM with x264 and x265, which disables features that improve subjective quality but degrade metric scores, tuning for VMAF enables features that improve metric scores but may degrade subjective quality, which feels like cheating. So I didn't tune for VMAF in any of the encodes. I will discuss tuning for PSNR/SSIM with the AV1 codecs following the x264/x265 discussion.

x264 offers two tuning mechanisms: PSNR and SSIM. To minimize administrative complexity, I wanted to use one mechanism for all files produced for metric testing. Although this analysis involves only VMAF and SSIMPLUS, I may incorporate PSNR, SSIM, and MS-SSIM in future testing. To choose the optimal tuning strategy for each codec, I encoded four files from four different genres with tuning for SSIM and PSNR enabled along with a file with no tuning. Then I averaged the result, which is shown for x264 in Table 2. The green scores were the highest average score.

As you can see in the table, tuning for PSNR delivered substantially higher VMAF and SSIMPLUS scores, was about even for PSNR, and produced very slight drops in SSIM and MS-SSIM. Accordingly, for x264, I tuned for PSNR. In a similar analysis for x265, tuning for SSIM produced the highest-quality score for all metrics, even PSNR. Accordingly, for x265, I tuned for SSIM.

90f70e40cf