Hacker News Reader

Comment by baby_souffle | Hacker News Reader

> DisplayPort is packet-based and can be multiplexed with other USB-C traffic through a hub

This is part of why DP is $$$ compared to HDMI. I would love to see DP start eating HDMI's lunch after this and the absolute shit show that was the HDMI 2.0 roll out but cheaper to implement is almost certainly going to be the driving factor when it comes to consumer grade TV / Displays and no console or other set top box maker is going to bother putting display port on their device if nobody's got a TV that can use it.

View on HN

> This is part of why DP is $$$ compared to HDMI.

Why is that more expensive?

In terms of complexity, implementing DP vs HDMI 2.1 is not materially different. They both have fixed rate links, packets, Reed-Solomon forward error correction, DSC, etc.

But IIRC DP is royalty free, and HDMI is not.

It sounds like it might be more about "the market will pay more for the packet-based approach, and we shall charge what the market will bear"

Speaking about 'packet-based approach', the way it's presented in the popular press as if it's similar to Ethernet, is a pretty gross distortion, the impact of which is not nearly as much as people seem to think it is.

You can check that there in this presentation (https://www.vesa.org/wp-content/uploads/2011/01/ICCE-Present...), page 32 and 33.

The majority of DP traffic is still brute force video data, interspersed with heavily packetized secondary data.

Over the years, I've spent many hours wading through DisplayPort data debug traces, and I've always wondered what people were smoking when they called it 'packetized like Ethernet'. It's just not true. (And FWIW: even old HDMI can transport secondary data packets just the way you can with DP. It's how audio-over-HDMI is done...)

Perhaps there is just more scale for HDMI making it easier to recoup r&d for new components that implement it

And the HDMI is pretty much a direct digital translation of analogue CRT signalling, blanking and timing weirdness included. Which is also not how modern LCDs implement their internal screen driving, so needs a similar level of complexity to decode and convert.

I think the biggest difference in DP vs HDMI cost is simply scale - there's probably orders of magnitude more HDMI chips sold than DP.

It won't happen unless VESA gets serious about adding home theater specific features to DP that HDMI has had for 20 years.

For example...? My experience is that DP is excatly like HDMI from the end user's perspective but happy to learn more.

ARC and CEC come to mind. ARC probably isn't too important, but CEC is nice being able to control various boxes with the same remote. Or being able to control the TV's volume with another remote.

ARC is actually pretty important, especially now that eARC is a thing. It finally decouples your receiver's HDMI capability requirements from your TV.

I see no __technical__ reason why you couldn't do CEC over the AUX channel... all that's required is for the software on either end to be updated to squirt and interpret the bits, and it's a low-speed protocol, so it'll fit just fine in the AUX channel.

"ARC" seems to be "Audio over HDMI using CEC for discovery and control", which (if you've bothered to run CEC over the DisplayPort AUX channel) you get the rest automatically with DisplayPort.

However, because both CEC and ARC are HDMI standards, you bet your biscuits that the HDMI Consortium will bar anyone who wants to use HDMI ports on their devices from shipping official firm/software that does the braindead-simple thing of running CEC over DP AUX, and having ARC-compatible firm/software.

As is nearly always the case (and when it's not, it's not for long) DisplayPort is totally capable of everything HDMI is, but the HDMI Consortium stands in the way of having commercially-distributed DisplayPort "home theater" products that are compatible with the nice-to-have HDMI features.

When I say DisplayPort needs these features, I don't necessarily mean they need the HDMI Consortium's specific implementation of them. I see no reason VESA couldn't implement their own alternatives to CEC, ARC, Auto Lipsync, etc. These HDMI features solve a host of problems that are unique to home theater setups, so any HDMI alternative that wants to supplant it needs to also solve them as well.

Like you point out, there's no technical reason DisplayPort cannot provide similar features. The issue is the lack of any standards for them built into the DisplayPort specification. Some of these features, like CEC, are 20 years old and could easily be improved upon in an ecosystem that doesn't have to worry about backwards compatibility.

> When I say DisplayPort needs these features, I don't necessarily mean they need the HDMI Consortium's specific implementation of them.

Ah, okay.

Well, DisplayPort handles EDID, DDC/CI, E-DDC & friends... that's the CEC-equivalents handled. VESA does have standards for remote control of displays... it turns out that that's a thing that people want to be able to do.

> The issue is the lack of any standards for them built into the DisplayPort specification.

Nah. DisplayPort already supports everything (or just about everything) CEC can do.

The reason you don't see this stuff often making its way into TVs is because the HDMI Consortium gets in the way of folks who want to add DP ports to their TVs. The reason you don't see explicit support for HDMI Consortium protocols such as CEC in VESA standards is -again- because the HDMI Consortium gets in the way of folks who want to add DP ports to their TVs... so why bother? (Especially when actually supporting the protocol is trivial... squirt exactly what you'd send over the HDMI cable over the DP AUX channel, instead.)

If it was actually politically possible to have DP ports on TVs, then you'd see some of the more esoteric aspects of CEC (like manipulating a TV tuner) be quickly standardized into the VESA equivalents... assuming that VESA didn't just say "Oh yeah, y'all just go talk CEC to these new DP-equipped TVs. You already know how.".

eARC is important not only because cable management and CEC, but because it's the only high bitrate digital audio output on most TVs: the only other commonly available digital audio output, TOSLINK, is limited to two-channel PCM[1], AC3, and DTS.

[1] While the physical TOSLINK cable is able to support higher channel counts via ADAT[2], I'm not aware of any TVs with ADAT support.

Similarly, while 192 kHz / 24-bit TOSLINK support is common in pro audio and audiophile gear, the standard only requires 48 kHz / 20-bit. I imagine most TVs output 48 kHz / 20-bit, if only for the sake of configuration simplicity: TOSLINK is strictly unidirectional, so automatically negotiating format support beyond mandatory minima is impossible.

[2] https://en.wikipedia.org/wiki/ADAT_Lightpipe

> ...[eARC is] the only high bitrate digital audio output on most TVs...

Great news! DisplayPort supports:

> 1–8 channels, 16 or 24-bit linear PCM; 32–192 kHz sampling rate; maximum bitrate 36,864 kbit/s (4,608 kB/s)

But it doesn't support any of the common bitstreamed audio formats like Dolby Atmos or DTS.

eARC lets your TV pass those along to your compatible receiver even if the TV itself can't make heads or tails of the format.

> eARC lets your TV pass those along to your compatible receiver even if the TV itself can't make heads or tails of the format.

DisplayPort Multi Stream Transport (MST) serves that role. Given that you'd only be passing along the audio data, rather than the video data, you could save money by putting the slowest available hardware (only BRR-capable) into the receiver.

Or, the TV could "just" pass along the audio stream to any plugged-in receiver. You don't gotta have a standard for that... just a standardized way to ask the TV to do it (assuming that you want to control the behavior and not have the conditional be "Is there a receiver plugged in? Pass along the audio and don't send it to the TV speakers.").

> But it doesn't support ... Dolby Atmos or DTS.

No, I think you're wrong about that.

> DisplayPort v1.2 also adds new audio enhancements including the following: — Audio Copy Protection and category codes — High definition audio formats such as Dolby MAT, DTS HD, all Blu-Ray formats, and the DRA standard from China — Synchronization assist between audio and video, multiple audio channels, and multiple audio sink devices using Global Time Code (GTC)

MAT claims to require an Atmos-capable decoder, so that sure seems like Atmos to me. I dunno what DTS HD, but that sounds like a souped-up DTS. Also take note of the "High definition audio formats such as" statement... that list of formats is incomplete.

The quote comes from: <https://vesa.org/press/vesa%C2%AE-introduces-displayporttm-v...>

Reply on news.ycombinator.com