Where QoE is really decided: the TV in the living room
Dear [First name],
Last month I said we would go through the Video Developer Report chapter by chapter. This month it is QoE, Playback and Observability.
One number from the chapter stuck with me: 53% of teams need 12 hours or longer to find the root cause of a streaming issue. Only 9% get there within the hour. During a live match, 12 hours means the game is over, the viewer has moved on and the ad impressions are gone with them. Uptime tells you the backend was fine. It says nothing about what the viewer saw.
I understand why it takes so long. When a stream fails, the evidence is spread across half a dozen systems. Someone has to log into the DRM logs, the CDN logs, the ad stitcher, the live encoder and the player analytics, pull the same session out of each one and line up the timestamps by hand. On top of that, the report tracks 13 playback platforms. 80% of teams ship to browsers, 47% to Apple TV, 41% to Android TV and 38% to Samsung and LG TVs, and each of them fails in its own way. Twelve hours is what that process costs.
Here is what I want to cover this month:
01
How Bitmovin sees it
02
Startup on Samsung and LG: up to 45% faster
03
Encoder Version 3: the same picture with fewer bits
04
Measuring it: RTBF at World Cup scale
01
How Bitmovin sees it
The data belongs in one place. DRM, CDN, stitcher and encoder observability data should sit inside the video observability platform, next to the playback session, so a team sees the whole delivery chain at once instead of one leg of it.
Second, AI agents that run continuously on that data, spot issues as they appear and suggest how to fix them, rather than waiting for someone to open a dashboard the next morning. Together they move resolution from hours to minutes, and in some cases seconds. The report suggests the industry is heading the same way: direct API and database access to observability data went from 21% in 2020 to 45% this year, and MCP connectors and AI assistants show up as an access method for the first time.
Third, if you want to know how your services really performs, then start with the TV numbers. It is the device I get asked about most, and the data shows why. A broadcaster we work with in the Middle East sees a median startup time of 1 second in browsers, 2.5 seconds on Samsung and 3.2 seconds on LG, with the same content and the same player. Many of the TVs in people's homes are several years old, have less processing power than a mid-range phone, and stay in the living room for a long time.
So what happened our side:
02
Start up on Samsung and LG: up to 45% faster
Our Player team put a lot of our roadmap time into startup performance over 2025 and 2026, most of it on Tizen and webOS. Cold starts are now up to 45% faster on the TVs we tested, nine of the 13 platform versions improved by 24% or more, and the gains reach back to Tizen 3 and webOS 3. The Player bundle is 19% smaller, six memory leaks are fixed so long sessions stay stable, and ads are preloaded so there are fewer black screens going into a break. There was no single trick behind this, just many careful releases. If you are on an older Player version, upgrading is the fastest way to get all of it. The team wrote up the details here.
03
Encoder Version 3: the same picture with fewer bits
QoE starts before anyone presses play. We launched Encoder Version 3 at IBC, and the benchmark is now public. The new HEVC codec matches your current quality at 15.5% lower bitrate with Per-Title Encoding. AV1 needs 30.6% fewer bits than the current HEVC encoder at the same encoding speed. At the same bitrate, the new HEVC scores 3 to 4 VMAF points higher on average and up to 7 points on the lowest rungs of the ladder. Those rungs are what a viewer on a weak connection actually gets, so that is where the difference is seen. We also ran the same test against AWS Elemental MediaConvert, both on default settings with no tuning on either side. Its automated ladder needed 58.5% more bitrate to match the new HEVC with Per-Title Encoding. Fewer bits means a lower CDN bill on every hour watched, and a better picture for the viewers who need it most. VOD reaches general availability this fall, and existing customers can request beta access now. Full numbers and method here.
04
Measuring it: RTBF at World Cup scale
The last piece is measurement, because without it you do not know whether any of this worked. RTBF ran one of the first server-guided ad insertion deployments at this scale during the FIFA World Cup, on our Player and Observability: more than 50 million plays, more than 80 million ad impressions, median startup time under one second throughout, and successful ad plays and viewability between 90% and 98%. Observability gave their team and their partners a live picture during the tournament, not a report afterwards. One detail I found interesting: Android TV sessions generated close to 4 ad impressions per play and iOS around 3, against just over 1 on web. The big screen is where the engagement and the money are, which brings us back to the TV. Read the story here.
My advice for the quarter: if you upgrade your Player or move to a new codec, measure startup time and buffering before and after, broken down by device. That is the number that tells you whether the work paid off, and the one your board will ask about.
Next month I will move on to the next chapter, Low Latency, MoQ and the Future of Video Delivery. We are also planning a webinar, and I will share the details once they are confirmed.
Which devices give your team the most trouble right now? Hit reply and let me know, I would like to compare notes.
