Bitmovin QoE report newsletter

Start Your Trial 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 wit