DrDc is unrelated to the issue here. As another commenter guessed, it's just an optimization to Chromium's graphics pipeline. Chrome has a number of processes that need to execute GPU work. For example, there's the renderer process which actually draws the page content into tiles (we refer to this as "rasterization"). There's at least one renderer process per page because of Site Isolation, but there can be more like in the case of iframes. There's also the Viz process that (among other things) handles the composition of all of the tiles generated by the renderers into the final framebuffer (this is known as the Display Compositor). Each of these processes funnels their GL calls into a separate thread called the GPU main thread which as part of Chromium's security model, is the only thread privileged to interact with the actual system graphics drivers.
The insight behind DrDc is that display compositing is higher priority than rasterization, so having both share work on the GPU main thread is bad for performance. DrDc is a large effort, but at the risk of oversimplifying, it's main purpose is to create a new GPU thread that the display compositor can use exclusively. DrDc is still rolling out on most platforms which may explain why it's disabled on your device, but regardless, it should not help with the video playback issues you're seeing.
Theoretically, the OpenGL, WebGL, Vulkan, Metal, and Unity implementations can all have comparable quality with enough dev work. From a quick glance through the README, it doesn't seem like the OpenGL implementation is relying on any cutting-edge features of the specification, so everything can be ported to WebGL as well. If anything, the Vulkan and Metal versions have higher "potential" when compared to older APIs like OpenGL because if you optimize with the lower level primitives, you'll have more cycles for complex rendering techniques. Also, I'd argue that Vulkan can be used by individual developers because there are already a bunch of games that have Vulkan support: https://en.wikipedia.org/wiki/List_of_games_with_Vulkan_supp...
Actually, if continue under this world with unlimited developer resources, the Cycles version should look the most realistic. It's markedly different than any of the other renderers included in this list because it's an offline path tracer whereas Unity and friends are for real-time rendering. We rely on a lot of hacks (Phong shading, FXAA, normal mapping) to produce an interactive 3D scene at 30+ FPS, but once you remove the real-time constraint, we can apply a lot of very fancy algorithms to more realistically render your scene. Cycles might take minutes or even hours to render a single frame, but it spends this time on a whole host of involved computation (physically-based BSDFs, Monte Carlo integration, Metropolis light transport, etc) that more accurately model how light interacts with materials.
The example in my blog post isn't really minimal because it assumes that you're writing your server in C++ for performance reasons. You can cut away a lot of the setup and boilerplate if you're fine with your server running on node and delegating all WebRTC tasks to a background electron process (see electron-webrtc).
WebRTC Data Channels don't actually let browsers send arbitrary UDP packets over the wire; rather, they only let you send SCTP packets tunneled over UDP. This distinction sounds pedantic because you can configure SCTP to deliver unreliable and unordered messages just like UDP, but there are some important caveats. For example, one of the benefits of UDP in real-time gaming is that packets can be dropped with minimal impact because it doesn't have head of line blocking. However, SCTP mandates congestion control which will start buffering your outgoing packets if it detects a minute or so of sustained packet loss (at least in libwebrtc). While congestion control is generally a good thing, in this case, it causes the game to grind to a halt. In addition, there is some overhead to sending the SCTP metadata which is suboptimal in bandwidth-heavy use cases like synchronizing a large physics simulation or supporting slower connections.
That being said, I'm very excited about WebRTC and its inclusion in Safari. It's not a silver bullet that exposes a simple UDP interface, but it's a welcome alternative to WebSockets for use in real-time games.
Even as someone who prefers the Vive in terms of overall experience, I think this article glosses over quite a few points and misrepresents the facts to the point where it shouldn't even be on HN for discussion. There are far less biased articles surfacing in the wake of Oculus Connect that don't for example, highlight Luckey's political leanings in the subtitle.
For one, the crux of the article is that the Rift is expensive. And sure, for some people, it definitely is. However, it's unfair to say that Oculus is a "$1,500 to $2,500 gaming platform" and shortly compare it to the $800 price point of the Vive which does not include the also required "$500 and $1,500" computer. Similarly, it seems wrong to compare either the Rift or the Vive to Google's Pixel because well, they're targeting different segments of the market with vastly different experiences. In addition, the article neglects to mention that a big announcement today was Oculus lowering the minimum specs of a VR headset with their new software that (from what I understand) interpolates frames. In fact, Oculus will be selling $500 dollar prebuilt systems which brings the minimum buy-in to experience VR on the Oculus considerably lower.
The rest of the article proceeds in a similar fashion; Oculus has quite a few interesting titles announced not even including the free title by Epic Games (makers of Unreal and the Unreal engine and definitely a well known studio) given out with the Touch. In particular, I'm excited about Luna because it was made by quite a few people from thatgamecompany (Journey). Similarly, having non-game media by OK Go (known for their virally popular experimental music videos) and Disney (no other introduction necessary) is huge for both the platform and VR in general. Yes, it's lacking a few big players like Bethesda, but I think the future lineup is far from as barren as the article so blindly suggests.
The insight behind DrDc is that display compositing is higher priority than rasterization, so having both share work on the GPU main thread is bad for performance. DrDc is a large effort, but at the risk of oversimplifying, it's main purpose is to create a new GPU thread that the display compositor can use exclusively. DrDc is still rolling out on most platforms which may explain why it's disabled on your device, but regardless, it should not help with the video playback issues you're seeing.