Tizen TV App Development & webOS: DRM, HLS, Certification

Updated October 2026: Tizen TV tooling has moved from Tizen Studio to the VS Code extension; LG's webOS 26 ships PlayReady 4.6 and Widevine 17; PlayReady 4.8 moves license servers to a new revocation list; new Tizen and webOS market figures; a partner-selection checklist.

Why this matters

For a streaming service, the television is the screen that earns the longest watch sessions and carries the premium, studio-licensed catalogue — and two platforms, Samsung Tizen and LG webOS, own most of that glass outside of Roku and Android TV. A media founder or product manager who treats "the TV app" as one more port is in for two expensive surprises: the content owner's contract will demand a digital rights management system the TVs support, and the TVs in people's homes span ten model years that do not all behave the same. This article explains both platforms in plain language — the web-app model, the native video path, the DRM and encryption-scheme reality, and the certification gate — so you can scope a TV build, judge a vendor's SDK, and avoid the encryption mistake that quietly breaks playback on the older half of the fleet. It is the living-room companion to the OTT client matrix, which maps every screen you must cover, and a sibling to iOS and Android playback. For a shorter, build-oriented overview of all four TV platforms, see our smart TV app development guide on the blog; this article is the deep reference for the two web-based TV operating systems.

Tizen TV app development and webOS: the short answer

Tizen TV app development means building a packaged web app (HTML, CSS and JavaScript) that runs in the Chromium-based engine of a Samsung TV, plays premium video through Samsung's native AVPlay API, and reaches viewers only after certification in Samsung TV Seller Office. LG webOS app development is the same web-app model with different parts: the Enact framework, the ares-* command-line tools, the HTML5 media path, and LG Seller Lounge review.

One codebase can serve both TV platforms, but three things never port for free: the video player binding, the DRM (PlayReady and Widevine, never FairPlay), and the encryption scheme, where older TVs still need cenc (CTR) rather than the mobile-standard cbcs. Budget most of the effort for testing across model years, not for writing the UI.

The living room is web apps — with native plumbing underneath

Start with the fact that makes TV development less scary than it looks: on both Samsung Tizen and LG webOS, your application is a web app. It is HTML for structure, CSS for layout, and JavaScript for behaviour, running inside a browser engine that the television ships with — a Chromium-derived engine on Tizen, a Blink-based web engine on webOS. If your team can build a web front-end, it can build the shell of a TV app. That is the good news, and it is why a single codebase can, with care, serve both platforms.

The catch is what sits beneath the web layer. A web page in a desktop browser plays video by handing a file to the <video> element and trusting the browser. A television is a constrained, purpose-built device, and premium streaming needs three things a plain web page does not give you: adaptive quality switching over a real network, hardware-accelerated 4K decoding, and studio-grade content protection. Each platform exposes those through its own native interfaces, reached from your JavaScript. So the shell is shared; the video and the protection are not. The rest of this article walks the two stacks, then the one thing that decides whether your content plays at all — the encryption scheme — and the tax that the device matrix imposes.

A "stack" here means the chain that turns a file on a server into moving pictures on the screen: the player (the code that fetches, decodes, and adapts the video), the streaming format (how the video is chopped into small pieces and described), and the digital rights management system, called DRM — the lock that stops a paying viewer's TV from copying premium content. On TVs, the player and DRM bindings differ between Samsung and LG even though the app language does not.

Figure 1. One web app, two TV operating systems. The shell is shared HTML/CSS/JS; the video path and the DRM binding are each platform's own.

Samsung Tizen: the web app, AVPlay, and Seller Office

Tizen is Samsung's own operating system, and it runs on every Samsung Smart TV released since 2015. Samsung was the world's No. 1 TV brand for the 20th year in a row in 2025, with 29.1% of the global TV market by Omdia's count (Samsung, March 2026), and Parks Associates' 2026 US household research puts Tizen at 23% of TV operating-system usage, second only to Roku OS at 28%. Since 2022 Samsung has also licensed Tizen to other TV brands (RCA, EKO, QBELL and Axdia among the partners named in August 2025), so a Tizen build now reaches some non-Samsung sets too. That reach is the reason Tizen is rarely optional for a serious OTT service.

Your Tizen app is a packaged web app. You write the interface in standard web technology; many teams use a TV-friendly UI framework on top. For tooling, Samsung points TV developers to the Tizen TV extension for Visual Studio Code, which creates projects from templates, builds and signs the package with your certificate profile, launches it on a real TV, the TV Emulator or the Simulator, debugs it in the Chrome Web Inspector, and live-reloads code on 2017 and later models. The older Eclipse-based Tizen Studio has been phased out: Samsung kept it in maintenance only until the end of 2025 and puts all new tooling work into VS Code, so start new projects there. For anything beyond casual clips, Samsung's guidance is explicit: to play adaptive streaming, additional subtitle formats, and 4K UHD video, you use the AVPlay API — Samsung's native media player — rather than the plain HTML5 <video> element. AVPlay gives your JavaScript direct control of the hardware media pipeline: you set the source, configure DRM, choose audio and subtitle tracks, and drive play, pause, and seek. The HTML5 element is fine for a trailer; AVPlay is what a real catalogue runs on.

A minimal sketch of the AVPlay wiring, illustrative rather than production code:

// Tizen native playback via the AVPlay API (simplified).
webapis.avplay.open("https://cdn.example.com/title/master.m3u8");
webapis.avplay.setDisplayRect(0, 0, 1920, 1080);

// Point AVPlay at your PlayReady or Widevine license server.
var drmParam = {
  DeleteLicenseAfterUse: true,
  LicenseServer: "https://license.example.com/playready"
};
webapis.avplay.setDrm("PLAYREADY", "SetProperties", JSON.stringify(drmParam));
webapis.avplay.prepareAsync(onReady, onError);   // then avplay.play()

Getting an app onto Samsung TVs means passing certification. You package the app into Tizen's widget format — the bundle carries a config.xml plus the signature files Tizen requires — and submit it through the Samsung TV Seller Office, Samsung's developer portal. There you select which model groups the version targets, and each version is certified separately against Samsung's launch checklist. That model-group step is your first direct encounter with fragmentation: you are not shipping to "Samsung TVs", you are shipping to specific generations, and you say which ones.

LG webOS: the web app, the media element, and Seller Lounge

webOS is LG's television operating system, and by LG's September 2025 count webOS runs on more than 240 million devices worldwide, including TVs from other brands that license it through LG's webOS Hub. The current release is webOS 26: it began rolling out to 2025 OLED models in August 2026, and under LG's webOS Re:New programme supported TVs receive a yearly OS upgrade for five years, with 2022–2024 sets scheduled for late 2026 or early 2027. It is the second web-based TV platform you will target, and it follows the same pattern as Tizen with different names on the parts.

A webOS app is again a web app — HTML, CSS, and JavaScript — and LG steers developers toward Enact, its own React-based UI framework tuned for the ten-foot, remote-driven living-room experience. You scaffold and deploy with the webOS TV SDK and its command-line tools (ares-generate to create a project, ares-setup-device to connect a real TV). For device features beyond the web sandbox — system services, inputs from the Magic Remote — webOS exposes the Luna Service API, reached through the webOSTV.js helper library. On the media side, webOS leans on the standard HTML5 media path enhanced for the TV, and its documentation is precise about formats, which matters more here than on any other platform.

Distribution mirrors Samsung's. You submit through LG Seller Lounge, the app passes LG's App Approval Process, and LG publishes an App Self Checklist you are expected to clear first. As on Tizen, you are certifying against specific webOS versions, not a single moving target.

The format reality: HLS, DASH, and a webOS quirk

Picking a streaming format is where the two platforms visibly diverge, and it has a direct bill attached. The two adaptive formats in play are HTTP Live Streaming (HLS), Apple's format standardised as IETF RFC 8216, and MPEG-DASH, the ISO format defined in ISO/IEC 23009-1. Adaptive means the stream is cut into short segments at several quality levels, and the player climbs up or down the ladder as the network changes — the mechanics live in our packaging article and, for the protocol internals, in Video Streaming's HLS vs DASH.

On Tizen, AVPlay handles both HLS and DASH, so a Samsung-only plan can use either. On webOS, LG's streaming specification lists HLS as supported (HLS version 7 on webOS TV 5.0 and later, version 5 on 4.x, version 3 on 3.5 and earlier) and does not list MPEG-DASH among the supported protocols. The practical rule: if you serve LG TVs, produce HLS. The cleanest way to satisfy both platforms without re-encoding twice is to package once into the Common Media Application Format (CMAF) — fragmented-MP4 segments defined in ISO/IEC 23000-19 — and expose them as both HLS and DASH from the same files.

webOS carries one quirk worth a line in your packaging spec: LG documents that the platform does not support different segment durations between the audio and video tracks of an HLS stream. If your packager emits, say, six-second video segments and four-second audio segments, playback can fail on LG TVs even though the same stream plays everywhere else. Align your segment durations and the problem disappears — but only if you knew to look.

DRM on the TV: PlayReady and Widevine, never FairPlay

Now the part a studio contract turns on. On phones the protection split is clean — FairPlay on iPhone, Widevine on Android. On televisions, Apple's FairPlay does not exist, because FairPlay is confined to Apple's own devices. The two DRM systems that matter in the living room are Microsoft PlayReady and Google Widevine, and webOS, and the HTML5 video path on Tizen, reach them the same way the browser does: through the web standard called Encrypted Media Extensions (EME), the W3C recommendation that lets a web app request decryption keys from a license server without ever touching the raw key. On Tizen's AVPlay path the app configures the same PlayReady or Widevine licence natively with setDrm, as in the sketch above; either way the key never reaches your JavaScript. EME is covered in depth in Encrypted Media Extensions and the browser DRM stack; the three systems themselves are in Widevine, PlayReady, FairPlay.

Which system runs depends on the platform and the model year. Samsung Tizen TVs support both PlayReady and Widevine Modular; PlayReady has the deeper history on Samsung hardware. LG webOS supports both PlayReady and Widevine Modular as well, with Widevine L1 (hardware-secure decoding) from webOS TV 3.5, and LG has deprecated the legacy Widevine Classic from webOS TV 23 — only the modern Widevine Modular, the EME-based one, remains. The safe default for the broadest TV coverage is a dual-DRM plan: PlayReady and Widevine, issued from the same encrypted files.

LG publishes the exact DRM versions per webOS release, which is the table your QA lead needs when deciding how far back the support matrix goes:

Source: LG webOS TV Developer, Streaming Protocol and DRM specification, checked October 2026.

There is also a quality gate, exactly as on mobile. Each DRM grades a device by how securely it can handle keys and decoded video. PlayReady expresses this as a security level (the higher hardware-rooted levels are required by studios for 4K), and Widevine as L1 versus L3. A TV that cannot prove hardware-level protection will be held to standard definition by the content owner's policy — not by a bug in your app. The full policy mechanics are in license policy: rentals, offline, and output control, and output protection over the HDMI cable (HDCP) is a separate layer again.

Figure 2. The TV DRM boundary. The app is a courier: EME requests a key from your license server, and the decryption happens inside the TV's protected media path.

The mistake that breaks the older half of the fleet: the encryption scheme

Here is the single most important — and most missed — fact in TV streaming, and it is grounded in the encryption standard itself. Common Encryption, the umbrella standard ISO/IEC 23001-7, defines two schemes for scrambling video: cenc, which uses AES in counter mode (AES-CTR), and cbcs, which uses AES in cipher-block-chaining mode with sub-sampling (AES-CBC). They are not interchangeable: a player that expects one cannot read the other.

On phones, the industry converged on cbcs, because Apple's FairPlay accepts only cbcs and the modern advice is "encrypt once with cbcs and serve every device". That advice is correct on mobile. It is wrong, by itself, for the television fleet. Independent device testing — Bitmovin's analysis of DRM ciphers on Samsung Tizen is the clearest public example — found that on Tizen TVs older than roughly 2019, cbcs (the CBC scheme) support is limited or absent, while Widevine with the cenc (CTR) scheme covers the large majority of Tizen TVs in the field. Newer model years (2022 and later) are moving in the cbcs-friendly direction, but the installed base in living rooms today still skews toward cenc.

The consequence is concrete. If you carry over a mobile packaging plan that encrypts the catalogue in cbcs only, your app can play perfectly on a 2024 TV in the test lab and show a black screen on the 2018 TV in a real customer's living room — because that older TV's DRM cannot decrypt the cbcs scheme. The fix is not a code change; it is a re-encrypt, which on a large library is days of compute and a delivery delay.

The way out is to decide your scheme strategy before you encrypt, with the TV fleet in mind. Two common patterns work: package a cenc (CTR) variant for the broad TV base alongside the cbcs variant your phones use, or — for the newest-only TV cohort — confirm cbcs coverage on your specific model groups first. Either way, the scheme decision is a TV-fleet decision, not a copy-paste from the phone plan. The scheme mechanics in full are in CENC, CTR, and CBCS: common encryption explained, and wiring one workflow to feed every device is multi-DRM: one workflow, every device.

Figure 3. Why "cbcs everywhere" breaks on TV. The older fleet leans on the cenc (CTR) scheme; cbcs coverage grows only with the newest model years.

The 2026 PlayReady change on Samsung — a server problem, not a TV problem

One dated item belongs in any current TV plan. In 2025, PlayReady SL2000 and SL3000 device certificates leaked publicly and Microsoft had them taken down from GitHub; the SL3000 tier is the hardware-rooted one studios require for 4K. Microsoft's answer is in PlayReady 4.8 (documented in 2026): Server SDK 4.8 downloads a new certificate revocation list from a new address (aka.ms/revinfo2), the old list is no longer updated, a 4.8 server pointed at the old list throws an error, and a 4.7-or-older server keeps running with greatly reduced device-revocation coverage. Microsoft also requires every PlayReady server to refresh its revocation list once a week. For a service streaming to Samsung Tizen TVs, almost all of the work lands on your license server, not on the televisions, because the PlayReady client is baked into each TV's firmware and is not upgraded the way an app is. A misconfigured 4.8 server looks like a black screen to viewers; an un-upgraded one quietly stops enforcing the latest device blocks. The same server-side change applies to PlayReady on LG webOS. We treat the Samsung migration step by step in the PlayReady-on-Samsung 2026 migration.

The device-fragmentation tax: where TV budgets actually go

Add the pieces up and the real economics of TV come into focus. Writing the web app once is the cheap part. The recurring cost — the device-fragmentation tax — is everything that multiplies across model years and platforms.

Walk the multipliers out loud. A live OTT service might support TVs back to 2016, which on Samsung alone is eleven model years (2016–2026), each with a different version of the Chromium-based web engine, a different memory budget on the cheaper tiers, and different DRM-scheme behaviour. Do the same for webOS and you have a second column of the same length. Your app's UI must stay responsive on the weakest, oldest device you promise to support, not the newest one you develop on — so the rule, from Samsung's and LG's own guidance, is to test on the oldest model year in your support matrix, not the latest. Certification is per platform and re-runs per version. The encryption scheme has to satisfy both the new cbcs cohort and the old cenc base. None of that work is visible in a demo; all of it is in the budget.

One thing changed the arithmetic in 2024–2026: model year no longer fixes the OS version. Samsung promised seven years of free Tizen OS upgrades for its 2024 AI TVs and some 2023 models, and LG's webOS Re:New programme gives supported TVs a yearly OS upgrade for five years. That is good for viewers and adds a dimension to your matrix: a 2023 Samsung or a 2022 LG set may run the original OS or a newer one, with a different web engine and DRM version. Test by OS version within model year, and re-run your smoke tests each time Samsung or LG ships an upgrade wave.

The lever that controls the tax is your support matrix — the explicit list of model years and OS versions you commit to. Narrow it and you cut testing, certification, and DRM-variant cost, but you also cut reach. Widen it and you reach the long tail of older TVs at a real and rising engineering cost. That trade — reach versus the fragmentation tax — is the central decision of a TV build, and it should be made deliberately, on paper, before the first sprint. The cross-platform strategy that keeps it from becoming eleven separate codebases is the player on every screen: a unified strategy.

Figure 4. The fragmentation tax. One codebase, but the recurring cost multiplies across model years, DRM schemes, and two certification pipelines.

Common mistake — the four that sink TV launches. First, encrypting in cbcs only and carrying it over from mobile, so the older TV fleet shows a black screen; plan a cenc (CTR) variant for the broad base. Second, producing DASH only, so LG webOS has nothing to play; always produce HLS. Third, developing and testing only on a current-year TV, then discovering the app is unusable on a 2018 set; test on the oldest model you support. Fourth, assuming the FairPlay setup from iOS carries over — it does not; TVs use PlayReady and Widevine.

How to choose a Tizen and webOS development partner

Short answer: pick the team that can show you a shipped Tizen or webOS app with studio DRM, explain its cenc/cbcs decision, and name the oldest model year it tested on. Generic app agencies usually stop at the web shell; TV specialists own the player binding, DRM, packaging and certification. Six questions separate them:

1. Shipped TV apps with protected content. Ask for live Tizen and webOS apps in Seller Office and Seller Lounge, not mock-ups, and who held the DRM integration.
2. Player and DRM depth. They should explain when to use AVPlay versus HTML5 video on Tizen, how PlayReady and Widevine are issued from one encrypted library, and what PlayReady 4.8 changes on the license server.
3. Encryption-scheme plan. A specialist asks about your oldest supported TV before you encrypt anything; a generalist copies the mobile cbcs plan.
4. Device lab. Real TVs across model years and OS versions, not only the emulator, and a written support matrix with the cost of each extra year.
5. Certification track record. How many Samsung and LG submissions they have taken through review, and what the last rejection was for.
6. One codebase strategy. How the same web build covers Tizen, webOS and the other TV platforms without forking per vendor.

Whoever you shortlist, run a paid two-week proof of concept: one protected title playing on the oldest and newest TV in your matrix. If you would rather add TV specialists to your own team than hand off the whole build, a dedicated streaming development team can own the Tizen and webOS clients while your engineers keep the backend.

FAQ

What is the difference between Tizen OS development and Tizen TV app development?

Tizen OS development means working on the operating system itself or on native platform services, which on TVs is Samsung's and its licensees' job. Tizen TV app development means building a web app that runs on top of Tizen OS and is distributed through Samsung TV Seller Office; that is what an OTT service builds.

What do I need to start Tizen TV app development in 2026?

A Samsung developer account, Visual Studio Code with the Tizen TV extension (Tizen Studio maintenance ended in 2025), a Samsung certificate profile to sign the package, the TV Emulator or a real Samsung TV in developer mode, and a license server for PlayReady or Widevine if your content is protected.

Which tools are used for LG webOS app development?

The webOS TV SDK with its ares-* command-line tools, LG's React-based Enact framework (optional but recommended), the webOSTV.js library for Luna Service API calls, and LG Seller Lounge for submission after the App Self Checklist.

Can one codebase target both Samsung Tizen and LG webOS?

Yes for the UI shell, because both run HTML, CSS and JavaScript apps. No for playback: Tizen premium video runs through AVPlay, webOS through its HTML5 media path, and each platform needs its own DRM configuration, packaging checks and certification.

Do Samsung and LG TVs support FairPlay DRM?

No. FairPlay is limited to Apple devices. Tizen and webOS TVs use Microsoft PlayReady and Google Widevine Modular, through Encrypted Media Extensions or, on Tizen's AVPlay, through Samsung's native DRM call.

Does LG webOS support MPEG-DASH?

LG's streaming specification lists HLS, not MPEG-DASH, as a supported protocol, so produce HLS for LG TVs. Packaging once in CMAF lets the same segments serve HLS for webOS and DASH for other devices.

How far back should a smart TV app support older models?

Set the cut-off from your audience data and your studio contracts, then price it: every extra model year adds test devices, DRM-scheme coverage (pre-2019 Tizen sets need cenc) and certification work. Pull the model-year split of your own viewers from analytics and stop where the next year back costs more than the audience it adds.

Where Fora Soft fits in

Television is where an OTT service meets its longest sessions and its most demanding content licences, and the scale problem is not one device — it is a decade of Samsung Tizen and LG webOS model years that each behave a little differently while a studio contract holds you to the same protection standard on all of them. Fora Soft has built video streaming, OTT/Internet TV, e-learning, and telemedicine applications since 2005 — 250+ projects across 20+ years — so the smart-TV realities here (the web-app model, AVPlay on Tizen, the HLS-and-EME path on webOS, dual-DRM with the right cenc/cbcs scheme, and per-store certification) are the day-to-day of our streaming work. We are vendor-neutral: we translate each platform's rules into a build, rather than reselling a single SDK. If you are putting a channel on Tizen and webOS, our OTT and Internet TV platform development team ships the TV apps alongside the web and mobile clients, and our video streaming software development work covers the packaging and dual-DRM backend those apps depend on.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook, 9,000+ pages, that takes the video stack from a single pixel to production — encoding, delivery, audio and AI — and someone who works through it can design and build a platform end to end. For a television build, start with volume 3: players, DRM and license delivery, the layer where PlayReady, Widevine and the device security level decide what a 2018 TV can play. Volume 2 covers HLS, MPEG-DASH and CMAF packaging, where the webOS HLS rule and the cenc-or-cbcs choice are made, and volume 1 covers the encoding ladder those TVs decode. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. Common Encryption in ISO base media file format files — ISO/IEC 23001-7. ISO/IEC. Defines the cenc (AES-CTR) and cbcs (AES-CBC) schemes that decide whether a given TV model year can decrypt your content. Tier 1. https://www.iso.org/standard/68042.html
2. Encrypted Media Extensions (EME). W3C Recommendation, 18 September 2017. The browser standard Tizen and webOS use to request keys for PlayReady and Widevine without exposing the raw key. Tier 1. https://www.w3.org/TR/encrypted-media/
3. HTTP Live Streaming — IETF RFC 8216. IETF, 2017. The HLS format webOS supports natively and AVPlay plays on Tizen. Tier 1. https://www.rfc-editor.org/rfc/rfc8216
4. Dynamic adaptive streaming over HTTP (MPEG-DASH) — ISO/IEC 23009-1. ISO/IEC. The DASH format AVPlay handles on Tizen and which webOS does not officially support. Tier 1. https://www.iso.org/standard/83314.html
5. Common Media Application Format (CMAF) — ISO/IEC 23000-19. ISO/IEC. The fragmented-MP4 segment format that lets one package serve both HLS and DASH. Tier 1. https://www.iso.org/standard/79106.html
6. Streaming Protocol and DRM — webOS TV Developer. LG Electronics. Lists HLS (v7 on webOS TV 5.0+) and not MPEG-DASH, PlayReady and Widevine Modular versions per webOS release (webOS 26: PlayReady 4.6, Widevine 17), Widevine Classic deprecated from webOS TV 23, and equal audio/video segment durations. Tier 3 (first-party). https://webostv.developer.lge.com/develop/specifications/streaming-protocol-drm
7. Playback Using AVPlay — Samsung Developer. Samsung. The native media API for adaptive streaming, 4K UHD, subtitle formats, and DRM configuration on Tizen TVs. Tier 3 (first-party). https://developer.samsung.com/smarttv/develop/guides/multimedia/media-playback/using-avplay.html
8. Registering and distributing applications — Samsung TV Seller Office. Samsung. The Tizen widget package, model-group selection, and per-version certification flow. Tier 3 (first-party). https://developer.samsung.com/tv-seller-office/guides/applications/registering-application.html
9. App Approval Process — webOS TV Developer. LG Electronics. The Seller Lounge submission and App Self Checklist gate for webOS TV apps. Tier 3 (first-party). https://webostv.developer.lge.com/distribute/app-approval-process
10. PlayReady content encryption modes. Microsoft Learn. PlayReady support for the CENC (CTR) and CBCS (CBC) schemes, the basis of the scheme-coverage decision. Tier 3 (first-party). https://learn.microsoft.com/en-us/playready/packaging/content-encryption-modes
11. Analysis of DRM Ciphers for Samsung Tizen TVs. Bitmovin (Stream Lab device testing), updated April 2026. Finds cbcs (CBC) support limited on pre-2019 Tizen TVs while Widevine + cenc (CTR) covers most of the fleet. Tier 5 (industry testing). https://bitmovin.com/blog/analysis-drm-ciphers-samsung-tizen-tvs/
12. Samsung Electronics Marks 20 Consecutive Years as the World's No.1 TV Brand. Samsung Newsroom, 9 March 2026. 29.1% global TV market share in 2025 (Omdia). Tier 3 (first-party). https://news.samsung.com/us/samsung-electronics-marks-20-consecutive-years-as-the-worlds-no-1-tv-brand/
13. Roku OS (28%) and Samsung's Tizen OS (23%) account for the largest share of TV operating system usage in the US. Parks Associates research, reported April 2026. Tier 5 (industry research). https://appleworld.today/2026/04/roku-os-28-and-samsungs-tizen-os-23-account-for-the-largest-share-of-tv-operating-system-usage-in-the-us/
14. Samsung Expands Tizen OS Licensing Program with New Global Partners. Samsung Newsroom, 11 August 2025. Tier 3 (first-party). https://news.samsung.com/my/samsung-expands-tizen-os-licensing-program-with-new-global-partners-and-enhanced-offerings
15. Samsung to offer 7 years of free Tizen OS upgrades for AI TVs. KED Global, August 2024. Tier 5 (press). https://www.kedglobal.com/electronics/newsView/ked202408230003
16. Tizen TV extension for Visual Studio Code. Samsung Developer. Project templates, signing, launch on TV/Emulator/Simulator, Chrome Web Inspector debugging, live reload on 2017+ models. Tier 3 (first-party). https://developer.samsung.com/smarttv/develop/tools/additional-tools/vscode-extension.html
17. Tizen Development Environment Focused on VSCode. Samsung Tizen OS, March 2025 (updated November 2025). Eclipse-based Tizen Studio phased out, maintenance until end of 2025; new tooling targets VS Code. Tier 3 (first-party). https://samsungtizenos.com/blog/tizen-development-environment-focused-on-vscode/
18. LG webOS integrated into more than 240 million devices. DigiTimes, 24 September 2025. Tier 5 (press). https://www.digitimes.com/news/a20250924PD219.html
19. LG Begins webOS 26 Rollout For Older TVs. ChannelNews, 24 August 2026. webOS Re:New: yearly OS upgrades for five years. Tier 5 (press). https://www.channelnews.com.au/lg-begins-webos-26-rollout-for-older-tvs/
20. What's New in PlayReady Version 4.8. Microsoft Learn, last updated 25 August 2026. New CRL address for Server SDK 4.8, old list no longer updated. Tier 3 (first-party). https://learn.microsoft.com/en-us/playready/overview/what-is-new/what-is-new-4-8
21. PlayReady Revocation. Microsoft Learn, updated March 2026. Weekly CRL update requirement for PlayReady servers. Tier 3 (first-party). https://learn.microsoft.com/en-us/playready/overview/revocation
22. PlayReady DRM Leak Triggers Microsoft Takedown. TorrentFreak, 2025. SL2000/SL3000 certificate leak. Tier 5 (press). https://torrentfreak.com/playready-drm-leak-triggers-microsoft-takedown-and-amazon-account-suspensions/

Where sources disagreed, the official spec was followed. The popular "encrypt once with cbcs and serve every device" advice — correct for mobile — was overridden for the TV fleet by ISO/IEC 23001-7 read together with public device testing, which shows the older Tizen base needs the cenc (CTR) scheme. The "smart TVs use the same DRM as phones" assumption was overridden by the platform docs: FairPlay is Apple-only and absent on TV, where PlayReady and Widevine rule.