WEBVTT 00:00:00.000 --> 00:00:06.400 HDMI made the entire internet mad recently by introducing a confusing new branding scheme 00:00:06.400 --> 00:00:11.200 when the old one was serving everyone just fine. But hold on, there's more because it's about to 00:00:11.200 --> 00:00:18.080 get more confusing with the introduction of HDMI 2.1a. There's an A. So let's talk about what's new 00:00:18.080 --> 00:00:24.720 in the HDMI 2.1a spec. And as you may have gathered from the fact that it's called 2.1a instead of 00:00:24.720 --> 00:00:31.920 2.2, the list of changes is rather short. In fact, there's only one new feature and it's called 00:00:31.920 --> 00:00:36.640 source-based tone mapping. That might sound like some kind of gimmick you'd pay extra for at a 00:00:36.640 --> 00:00:42.160 tanning salon, but it actually has to do with the way devices handle HDR. Tone mapping is the 00:00:42.160 --> 00:00:48.160 process of taking an HDR signal and adjusting it to match the capabilities of whichever display you 00:00:48.480 --> 00:00:55.760 be watching that content on. You see, many HDR-capable TVs actually are not able to show an 00:00:55.760 --> 00:01:01.600 HDR image as it's originally mastered. Oftentimes, the original video is mastered at 1,000 nits of 00:01:01.600 --> 00:01:06.720 brightness or even higher, but most consumer displays, even many that are marketed as HDR, 00:01:07.280 --> 00:01:13.840 cannot get that right. Additionally, HDR content is often mastered for a wider color gamut than 00:01:13.840 --> 00:01:20.320 many TVs can show, meaning they can't display as many colors as are contained in the source material. 00:01:20.320 --> 00:01:25.920 Without tone mapping, the TV would clip the image. That is, it would simply discard the information 00:01:25.920 --> 00:01:31.760 it can't display from the video signal, and the image would instead have very incorrect colors, 00:01:31.760 --> 00:01:36.880 or just parts with no information, and portions that would be blown out to absolute crap so you 00:01:36.880 --> 00:01:41.520 can't even see them at all. So tone mapping effectively takes color and brightness information 00:01:41.520 --> 00:01:47.760 and maps it to a value that the TV can actually show. This allows the TV to approximate the original 00:01:47.760 --> 00:01:53.280 image accurately enough so that it looks okay on your screen instead of a distorted mess. 00:01:53.280 --> 00:01:58.000 So for example, a signal with 1,000 nits peak brightness can be reduced so that the brightest 00:01:58.000 --> 00:02:03.600 parts of the image are now, say, 400 nits. Everything goes in line with that. 00:02:04.240 --> 00:02:10.080 Now back to HMAT 2.18. Traditionally, tone mapping is handled by the display itself, 00:02:10.080 --> 00:02:16.400 but the source-based tone mapping in HDMI 2.1a offloads some of this responsibility from the 00:02:16.400 --> 00:02:22.160 display and moves it to the source, whether the source is a GPU, a streaming box like an NVIDIA 00:02:22.160 --> 00:02:30.000 Shield, or a Blu-ray player. But why exactly would we want this? Dolby Vision HDR actually already has 00:02:30.000 --> 00:02:35.920 a proprietary option where you can select either TV-led or player-led tone mapping, 00:02:35.920 --> 00:02:41.040 and tests have shown that tone mapping looks better when it's handled by the display itself, 00:02:41.040 --> 00:02:47.440 as the TV is adapting to its own characteristics, as well as data from its ambient light sensor if 00:02:47.440 --> 00:02:52.000 it has one of those built in. Having the source handle tone mapping means that it's doing the 00:02:52.000 --> 00:02:57.040 mapping based simply on what the TV reports its capabilities to be, meaning the adjustments the 00:02:57.040 --> 00:03:04.240 source makes may not be as accurate. So why do we want this? Well, it's because there is a big plus 00:03:04.240 --> 00:03:11.440 to source-based tone mapping, lower latency. Even if something might look a bit better if the TV 00:03:11.440 --> 00:03:17.280 is handling the tone mapping, this additional processing that the TV has to do adds latency, 00:03:17.280 --> 00:03:22.720 which can be a significant drawback for gamers who want as small of a delay between pressing a 00:03:22.720 --> 00:03:28.480 button on the controller and seeing an action happen on the screen as possible. So source-based 00:03:28.560 --> 00:03:35.280 tone mapping, or SBTM, is a sensible addition to HDMI's increasingly gamer-focused feature set. 00:03:35.280 --> 00:03:40.320 Additionally, source-based tone mapping does allow more of a plug-and-play experience for the user, 00:03:40.320 --> 00:03:44.480 as since it allows the source to read and understand the display's capability, 00:03:44.480 --> 00:03:50.400 the user won't have to spend as much time adjusting picture settings to get their HDR content to look 00:03:50.400 --> 00:03:56.640 right. For now, it sounds like SBTM support can be added to existing devices via firmware updates, 00:03:56.640 --> 00:04:01.680 but that'll be up to device manufacturers. So if you want the feature without spending 00:04:01.680 --> 00:04:07.920 extra on new equipment, your mileage may vary as AV manufacturers have a track record, let's say, 00:04:07.920 --> 00:04:14.560 of being very slow with updates. Additionally, HDMI 2.1a is going to suffer from the same stupid 00:04:14.560 --> 00:04:21.440 naming issues we saw with the original HDMI 2.1. All current HDMI devices will transition over to 00:04:21.440 --> 00:04:28.880 the HDMI 2.1a name, but they don't all have to support every new feature of HDMI 2.1 or 2.1a, 00:04:28.880 --> 00:04:33.920 so make sure you read the spec sheet to see if the features you care about are actually present. 00:04:34.480 --> 00:04:37.920 I mean, you never spend money without reading the fine print first, right? 00:04:39.040 --> 00:04:43.360 Right? So thanks for watching guys, if you liked this video, hit like, hit subscribe, 00:04:43.360 --> 00:04:48.080 and hit us up in the comment section with your ideas for topics that we should cover in the future.