Legacy Device Offboarding
Legacy Device
What defines a legacy device?
- Official support, limitation of hardware or security threat with no action to be closed
- Meeting mvp requirements for a modern player is defined by a platform. Each platforms streaming formats, codecs or security levels (DRM, TLS) a newer company is unlikely to support Smooth.
Standard API
- Device Media Device detection, common error codes
- Code repurposing Brightscript example discussed
Offloading devices
- The challenge in consensus across commercial, enterprise, product and tech
- Don't maintain hardware to test, bug reports are ignored
- Costs how to track all the elements dev, testing, revenue
- HBBTV and legacy attempts were discussed.
Rob from Peacock, rolling out multiview showed misalignment in implementations on features like MSE, browser based applications lend themself to the inconsistencies but also the bloat of the browser to a stripped back platform runtime TV focused browser like WPF. Restricts, simplifies some porting examples to projects GStreamer?
- A general consensus that CTVs? don't update Chromium versions and we are supporting back to 38 still supported on fairly recent devices
- Gary pointed to YouTube? Cobalt project they use that works on very old devices and is an open source framework
- React Native framework was discussed but where a device might already be underpowered it's not great
Compliance test suite across tvs
- Where is a TV test lab? THere? is a CTA WAVE test lab, free event coming soon that drives
- A benefit is the shared infra for replicating bugs and having a shared space for issues
- CanIuse? for video people, CanIPlay?.com doesn't stop at browsers go deeper into OS version CTV and list devices that reject being tested. links off to test suite where anyone can replicate
- Youtube test suite for manufacturers, hbbtv had a similar issue
- How does a manufacturer get certified? Dolby partnerships and hardware is tested. No similar legal agreement or sticker on the box for manufacturers
Biggest pain points
- Not being able to monetize Multi-Period DASH
- Dropping Flash, single development codework, EOL was already planned
- Gen1 Chromecast Costing more to support than value created, migration to new tech stack MVP decisions on PS3? based on UX of app
- STB trying for feature parity on older devices. A device only supported MPEG2? video and needed
- Supporting browser Chrome 39 on HLS.JS older webkit workarounds to gain compatibility
- Stop support for security reasons, dropping devices that couldn't support TLS 1.1 and 1.0
Misc:
- Business agreement to not support but not actively drop devices, reject
- We never dropped anything even flash we just migrated to something else or example on mobile directed to the app. Incidental things like ES versions won't work on older device but no one is calling out its broken so userbase is
- Dropped actively for dev sanity IE11?, held out some time still had users on it but no one complained
- Good point raised on third world devices. And support for say 10 year old smooth streaming
- Example of users don't always drop their service, new TVs? move from the living room to the basement, other devices
- Player built on web components drew a line from the start on device/browser support
- Example from user with several rounds across streaming services. Minmising the content formats at the video stack. Driven by content environments like removing TS support disqualified some devices. CMAF, CNC, DRM
- When pulling the plug commercial agreements from the start had a sunset timeline, insisting on formats, content protections required from the start
- Monetisation and cost to reencode preventing this