in 1997 I saw Linus Torvalds speak at UC Berkeley following his move to California to work at Transmeta. I was a computer science undergrad at UC Davis, and took Amtrak to Berkeley along with some friends to see Linus in person. Linux was building momentum, and Linus was a real celebrity to those in the space.
Supporting Linus and the Linux community is a great legacy for Transmeta, even if their products didn't find commercial success.
Another important feature: HEVC playback on Mac OS X. An increasing amount of video content, especially content recorded on mobile phones, uses HEVC. Inconsistent playback support represents a real barrier to HEVC adoption (among other things), and Firefox support goes a long ways toward making HEVC more widespread.
I'm amazed that their architecture doesn't include a CDN. These days I expect nearly all high traffic websites to make use of a CDN for all kinds of content, even content that's not cached.
They cited Cloudflare not being used due to privacy concerns. It'd be interesting to hear more about that, as well as why other CDNs weren't worth evaluating too.
This literally cost me sleep last night, paging me for new Kubernetes nodes that failed to transition to 'Ready' because they were unable to pull Calico images during bootstrapping. After some duct-taping to get those initial nodes up and running, we just moved the Quay-hosted images to a GCR repository and moved on with life.
But that doesn't diminish the fact that this outage is a complete disaster for Quay.
At Mux we use Cedexis Openmix to dynamically select between Fastly and Highwinds (now Stackpath) CDNs to stream a lot of video. The end-user experience with a CDN is going to vary dramatically depending on where your users are located around the world, which ISP they use, and many other factors that change by the minute. I wrote a blog[1] post about how & why we use multiple CDNs with our video service.
You might also want to evaluate a video QoE service to see what your users are experiencing in terms of video start-up times, rendition switching, buffering, etc.
> As of 2012, videos that didn’t load in two seconds had little hope of going viral.
This finding aligns with the results of a survey of users of the Mux video analytics service. We asked them "Which of the following streaming video problems is the most frustrating for you when it occurs?" Video rebuffering or stalled playback was considered the most annoying problem for 47% of respondents; video picture quality was chosen by only 14.3%. Slow startup times and rebuffering have a huge impact on the perceived QoE compared to video picture quality.
Very short segment durations are effective only when latency is more important than quality.
Each TS segment must start with a key-frame, and the GOP size can't exceed the duration of a segment (e.g. one second). Lowering the segment duration increases the frequency of key-frames, which has the effect of lowering the quality you can achieve at a given bitrate.
Periscope developed a Low-Latency HTTP Live Streaming (LHLS) technique that relies on HTTP chunked transfer-encoding to stream video bytes as they are encoded at the origin. This is still subject to TCP packet retransmission overhead, but the time-to-first-byte is reduced significantly and leads to less buffering on the client.
Most systems that serve HLS media use fixed content-length segments, which requires knowledge of the length of a segment before the first byte can be sent over the wire. So, for a 5 second segment you would need to encode the entire 5 seconds before the first byte can be sent; this does not apply when streaming the segments with chunked transfer encoding.
Incidentally, at Mux we also use chunked transfer-encoding to stream video that is encoded on-the-fly with great performance.
It's a great example of how trying to design a product that works well for every stakeholder in every scenario leads to a Frankenstein of a product that doesn't work well for anybody. This happens all too often in government (typically military) contracts.
Crawlers & scrapers that rely on headless browsers like Chrome often initiate playback of video on the pages they access.
The company I work for (Mux) has a product that collects user-experience metrics for video playback in browsers & native apps. It's been a non-trivial effort developing a system to identify video views from headless browsers so that we might limit their impact on metrics. Being able to make this differentiation has a real benefit to human users of our customer's websites.
My preference would be for headless browsers to not interact with web video or be easily identifiable via request headers, though I doubt either of these things will happen any time soon.
Great question! There was a fairly even distribution of slow-performing requests across the many user-agent strings coming from the Facebook ASN.
My hunch is that the Facebook crawlers send user-agent strings that Facebook has seen in requests to their own services. This allows them to crawl content in linked posts masquerading as a device that their users would actually use.
Post author here: this post was written in June 2017, and the subject has become increasingly relevant since the MySpace video advertising bot fraud reported by BuzzFeed on October 27, 2017:
https://www.buzzfeed.com/craigsilverman/remember-tom
Two years ago I integrated CoderPad into a technical-screening-as-a-service product I was involved with; Vincent's responsiveness and focus were very impressive. I'm thrilled to see him making such progress!
In the event that someone else is looking to integrate CoderPad into their product, here's the Java client library I wrote for CoderPad in 2015: https://github.com/skidder/coderpad-java-api
Crawlers & bots trigger video playback on the websites they visit, though it's probably unintentional in most cases. At Mux we have taken steps to identify such video views to limit their impact on aggregate video view performance metrics:
https://mux.com/blog/do-androids-watch-videos-of-electric-sh...
Mux (https://mux.com/) collects performance metrics for video delivery & playback on the websites & apps of our customers. These metrics feed into our real-time alerting system. If the error-rate for a customer property (site) or video-title is exceptionally high then an alert will be triggered. Mux customers can configure alert notifications to be sent to Slack & email, and view a history of alerts in the Mux web dashboard. We also offer the ability to view breakdowns of playback failures, video start-up times, and more through our dashboard. This can be helpful for diagnosing playback issues related to specific browsers, geographies, ISPs, and more.
We ruled out HTM due to AGPL licensing concerns. It's an interesting product, but wasn't a good fit for us at this point in time. EGADS and other basic statistical methods can actually get you pretty far.
Supporting Linus and the Linux community is a great legacy for Transmeta, even if their products didn't find commercial success.