I recently noticed a recurring visual artifact in the "Most Replayed" heatmap on the YouTube player. The highest peaks were always surrounded by two dips. I got curious about why they were there, so I decided to reverse engineer the feature to find out.
This post documents the deep dive. It starts with a system design recreation, reverse engineering the rendering code, and ends with the mathematics.
This is also my first attempt at writing an interactive article. I would love to hear your thoughts on the investigation and the format.
I like this style of writing as well, but I think this article overdoes it, to the point that it became somewhat irritating to read.
The part where I particularly feel this way is when the author spends two whole paragraphs discussing why YouTube (or its developers) chose to sample by "100" segments, to the extent that the author even asks, "If you work at YouTube and know the answer, please let me know. I am genuinely curious." Which, for lack of better words, I found ridiculous.
If this was my post I'd certainly appreciate criticism.
> but I think this article overdoes it
Perhaps its overdone in places, to your credit the question about if 100 was an arbitrary number was a bit much. But, as a counterpoint, I found the related pondering of "might it make sense to have variable time duration windows" to be interesting. The interpolation YouTube ultimately selected is deceiving and variable density could be a way to mitigate that.
There's definitely a healthy balance and perhaps the author teeters on the verbose end, but I mostly just wanted to voice that I was surprised about the type of article it was, but not in an unpleasant way.
You are likely right that I over-rotated on the "storytelling" aspect there. My curiosity about the "100 segments" stemmed from wondering if there was a deeper statistical reason for that specific granularity (e.g., optimal binning relative to average video length) versus it just being a "nice round number."
That said, I can see how dedicating two paragraphs to it felt like over-dramatizing a constant. I will try to tighten the pacing on the next one. Thanks for reading despite the irritation!
It’s often surprising how "intuitive" or elegant solutions can seem once you peel back the layers, isn't it? That simplicity is part of the beauty of good engineering!
I actually wasn't familiar with Josh Comeau’s work before this, but I just looked him up and... wow. To be mentioned in the same breath (let alone "arguably better") is a massive compliment. I’ll definitely be diving into his archives now.
Rendering bezier curves on the client side seems reasonable. Calculating ~400 points and rendering 100 curves would not impact performance, but I wonder if these little interactions would impact performance if added up.
About YouTube's comment about Gangnam Style, it wasn't a tweet. You can't find the original post because it was google+, which is dead. Google said it was a joke shortly afterwards: https://www.cnet.com/tech/services-and-software/gangnam-styl...
Re: Blurry canvases: You are spotting the classic HTML5 Canvas high-DPI issue. It happens because the canvas backing store pixels don't map 1:1 to CSS pixels on high-density displays (like Retina screens). I likely need to scale the canvas drawing context by window.devicePixelRatio to fix that sharpness. Good catch. EDIT: Made the change.
Re: Performance: That is an interesting thought. Since the calculation only triggers when you visit (or resize) the video player, there is definitely a CPU spike. My guess is they chose this approach to have a "plug and play" rendering logic that adapts perfectly to the client's specific device width and pixel density, rather than generating thousands of static image variations on the server.
Re: Gangnam Style: Ah, Google+! That explains why I couldn't find the original source. Thanks for the correction. EDIT: Added the correction.
https://issues.chromium.org/issues/40853564 (while Microsoft has filed it as a bug in Chromium, I hazard it is actually just a bug in the way YouTube handles events on their text fields)
I like how detailed they were in their writing (even though I was suspecting the graph function to be the culprit all along) ! Big Kudos though to get to the ground of it and writing it all down for others to learn ! Also, indeed this would make a great template for LLM problem-decomposition / solving.
Is this an invented bit of humor ... or an existing usage applied to the prevalence of rounded corners we see (once again) in User Interfaces of today?
(The original term has nothing to do with web design or UI per se)
https://en.wikipedia.org/wiki/Bouba/kiki_effect
Edit: i see the article goes on to explain the term in context.
But I feel the sharp corners versus round corners is a design/fad cycle that will keep repeating.
We will see sharp corners once again in vogue within the next decade if not sooner.
It will start small with one or two players wanting to distinguish their offering from the crowd, and one of them seeing success, and others copying them slowly at first and then it catches on.
You are spot on about the cycle, though. I suspect that once everything is perfectly round and polished, the only way to stand out will be to go sharp again.
