Widevine L1 pro hotelovou televizi

Od výzkumného týmu COTT.TV Hospitality Technology | Výzkum září 2026

Widevine L1 je často považováno za odznak: zařízení hlásí L1, takže prémiové kanály budou fungovat. V praxi však výsledek závisí také na schématu šifrování, licenční politice, přehrávači, ochraně výstupu, handshake televizoru, provisioning a právech udělených poskytovatelem obsahu.

Hotel by měl slibovat šifrovaný obsah pouze poté, co přesný stream byl přehrán na přesném koncovém bodě a profilu zobrazení podle zamýšlené obchodní politiky.

Co Widevine dělá

Widevine je systém ochrany obsahu od Googlu pro prémiová média. Funguje s běžnými webovými a mediálními standardy, včetně Encrypted Media Extensions a Common Encryption. Google uvádí Android, AOSP, Chromecast, běžné prohlížeče a platformy chytrých televizí včetně Tizen a webOS mezi podporovanými kategoriemi platforem.

Na vysoké úrovni:

1. obsah je zabalen a zašifrován; 2. přehrávač načte prezentaci DASH nebo HLS; 3. klient vytvoří licenční výzvu; 4. licenční proxy operátora ověří nárok a politiku; 5. služba Widevine vrátí licenci specifickou pro zařízení; 6. klient dešifruje a zobrazuje prostřednictvím povolené cesty.

Licenční proxy je důležitá. Google uvádí, že klient nekomunikuje přímo se službou licencí Widevine; proxy provozovaná partnerem ověřuje žádost a aplikuje obchodní pravidla.

Úrovně zabezpečení v praktických termínech

L1: kryptografické zpracování a zpracování chráněných médií probíhá uvnitř důvěryhodného výpočetního prostředí. To je běžně vyžadováno pro prémiový obsah ve vysokém nebo ultra vysokém rozlišení.

L3: dešifrování se více spoléhá na běžné softwarové prostředí. Mnoho služeb omezuje rozlišení nebo odmítá přehrávání.

Diagnostická vlastnost zařízení je pouze jeden vstup. Špatně integrovaný firmware může hlásit L1, zatímco nesplňuje požadavky robustnosti nebo výstupu poskytovatele obsahu.

Schémata šifrování a kompatibilita

Dokumentace Widevine od Googlu ukazuje, že podpora platforem pro schémata Common Encryption se liší podle generace. Moderní verze Android TV a chytré televizory běžně podporují cenc a cbcs, ale starší koncové body mohou být užší.

Zaznamenejte pro každý kanál:

• 1kontejner a streamingový protokol;
• 2video a audio kodeky;
• 3šifrování cenc nebo cbcs;
• 4chování rotace klíčů;
• 5signalizaci manifestu a data PSSH;
• 6licenční URL a autentizační cestu;
• 7požadovanou ochranu výstupu;
• 8offline nebo trvalou politiku licencí, pokud je relevantní.

Neměňte režim šifrování napříč příspěvkovým a distribučním kanálem bez opětovného testování každého profilu koncového bodu.

L1 nezaručuje 4K

Rozlišení může být omezeno:

• 1licenční politikou poskytovatele obsahu;
• 2certifikací zabezpečení zařízení;
• 3úrovní HDCP na HDMI výstupu;
• 4EDID displeje a handshake;
• 5profilem kodeku a hardwarovým dekodérem;
• 6limity aplikace nebo prohlížeče;
• 7nárokem na účet nebo území;
• 8kapacitou sítě.

Záznam o přijetí by měl uvádět pozorované rozlišení a stav ochrany výstupu, nikoli pouze "DRM prošlo."

Přímo chytrá TV versus HDMI STB

Na aplikaci chytré TV přímo platforma ovládá mediální pipeline a zobrazení společně. Na STB chráněná cesta také prochází HDMI. To zavádí vyjednávání HDCP a kompatibilitu televizoru.

Otestujte zamýšlený kabel, port a sekvenci napájení. Stream, který funguje po ručním opětovném připojení HDMI, může stále selhat po nočním cyklu napájení pokoje.

Otázky licenční politiky

Zeptejte se poskytovatele obsahu nebo operátora DRM:

• 1které území a vlastnosti jsou autorizovány;
• 2zda je nárok na pokoj, zařízení, vlastnost nebo účet;
• 3požadovaná úroveň zabezpečení a minimální HDCP;
• 4maximální rozlišení podle profilu zařízení;
• 5limity souběžnosti a relací;
• 6trvání tokenu a licence;
• 7zda je podpora odvolání zařízení;
• 8požadavky na protokolování a reportování;
• 9oddělení testovacích a produkčních pověření;
• 10postup pro incidenty a rotaci klíčů.

Nedávejte produkční DRM pověření do stahovatelného televizního balíčku. Aplikace by měla požadovat krátkodobou autorizaci prostřednictvím řízeného backendu.

Skutečný test přijetí

Použijte jeden jasný kanál a jeden šifrovaný kanál se stejným přibližným video profilem. To izoluje DRM od základních problémů s dekódováním a sítí.

Pro každý profil koncového bodu:

1. potvrďte čas zařízení a důvěryhodné certifikáty; 2. zaznamenejte úroveň Widevine a systémový identifikátor; 3. spusťte jasný referenční kanál; 4. spusťte šifrovaný kanál a zaznamenejte výsledek licence; 5. ověřte rozlišení, kodek, audio a titulky; 6. přehrávejte alespoň 30 minut; 7. opakovaně měňte kanály; 8. přejděte do pohotovostního režimu a obnovte; 9. studený start a znovu přehrávejte; 10. přerušte síť během přehrávání; 11. obnovte síť a sledujte zotavení; 12. odvolejte nebo vypršete nárok a potvrďte odmítnutí; 13. obnovte nárok bez přeinstalování aplikace.

Zaznamenejte verze přehrávače, aplikace, firmwaru, televizoru, STB, HDMI portu a politiky DRM. Video na obrazovce je nezbytný důkaz, ale podpůrné týmy potřebují také dostatek telemetrie, aby pochopily budoucí selhání.

Diagnostika běžných vrstev selhání

Vyhněte se umisťování surových klíčů, kompletních tokenů nebo identifikátorů hostů do obecných protokolů aplikace.

DRM a autorizace streamu jsou různé vrstvy

DRM chrání mediální klíče a politiku přehrávání. Autorizace CDN kontroluje, kdo může získat manifesty a segmenty. Robustní služba obvykle potřebuje obojí:

• 1krátkodobý podepsaný přístup k cestě streamu;
• 2nárok na licenci vázaný na autorizovaný pokoj nebo zařízení;
• 3přístup k původu omezený na CDN nebo bránu;
• 4rotaci klíčů a podepisovacího tajemství;
• 5monitorování pro abnormální opětovné použití a geografii.

Jedna vrstva by neměla být považována za náhradu druhé.

Model ověřování COTT.TV

COTT.TV zaznamenává přehrávání šifrovaného kanálu jako součást profilu zařízení, místo aby to předpokládalo z technického listu. Platforma může autorizovat podle vlastnosti, území, pokoje a registrovaného zařízení, zatímco služba DRM vynucuje politiku obsahu.

Přečtěte si Ochrana hotelových TV streamů pro okolní distribuční kontroly a průvodce licencováním obsahu pro vrstvu práv.

Zdroje a další čtení

• 1Google: Přehled Widevine DRM
• 2Google: Dokumentace Widevine
• 3Google Cast: architektura přijímače
• 4AWS: omezování přístupu k soukromému obsahu

Certifikace DRM a práva na obsah jsou oddělené. Konečné schválení náleží příslušnému vlastníkovi obsahu, poskytovateli DRM a testovanému profilu zařízení.