Re: [Hls-interest] Determining which EXT-X-SESSION-KEY is correct

Roger Pantos <rpantos@apple.com> Thu, 21 May 2020 15:55 UTC

Return-Path: <rpantos@apple.com>
X-Original-To: hls-interest@ietfa.amsl.com
Delivered-To: hls-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065E53A0366; Thu, 21 May 2020 08:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NL7X_Hj0Y7v; Thu, 21 May 2020 08:55:00 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BD33A03F3; Thu, 21 May 2020 08:54:56 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04LFfInS021922; Thu, 21 May 2020 08:54:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=U08GcBqXwSoOR8I0e5IxGCEcaWOLJ0FcJl3h5P+xC5o=; b=KiMf/0I3aaE16IM3nOwbqNBlcNGV6L82ahVtXrtAGrVM94JL1JQwW6nC/pUfqc9wLL9f fZrvcodQj4ee3gntMTOHvyYmsLummQisKPa0g0PjpalVeV8WLK0CRcPuYAb/WRgJqVQq j1JM174WAXyvuhYuxDMgsf0lJo7Sj8cVsjIdRzRWlZZwgdkz6TUs1sZ7P10mfVdWsKt8 12H7T0w5s8V7H8uDJ49tavgpqw38w/PxFjWfAQqcX47DC/t6Z8zvqz9WmAyYr+H66NAT L+Cee4vzkqptbvgUQh22WjVbBJJBxHviFVp+0AaCvnlnh4g9gS4rJ1HayoWl9RdZvzpI Fg==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 312eu4mx74-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 May 2020 08:54:54 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QAO00W1MUVHTCE0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Thu, 21 May 2020 08:54:53 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QAO00C00TPP5U00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 21 May 2020 08:54:53 -0700 (PDT)
X-Va-A:
X-Va-T-CD: dfdea9760c77dd2123ec545208e44389
X-Va-E-CD: db2e1ff49c545fd99aea1efc9a7c47e3
X-Va-R-CD: 324940ba49fd72f3edfddca74703ec58
X-Va-CD: 0
X-Va-ID: 67748967-102f-4888-99ff-f300908c1bfc
X-V-A:
X-V-T-CD: dfdea9760c77dd2123ec545208e44389
X-V-E-CD: db2e1ff49c545fd99aea1efc9a7c47e3
X-V-R-CD: 324940ba49fd72f3edfddca74703ec58
X-V-CD: 0
X-V-ID: c01be699-5176-4547-b3ec-5b9e1feaa984
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-21_09:2020-05-21, 2020-05-21 signatures=0
Received: from [17.234.104.61] (unknown [17.234.104.61]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QAO00PEOUVFG900@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 21 May 2020 08:54:52 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3641.0.1.2.1\))
From: Roger Pantos <rpantos@apple.com>
In-reply-to: <24D51B8B-E877-4573-8FE2-D258223B68B7@disneystreaming.com>
Date: Thu, 21 May 2020 08:54:51 -0700
Cc: "hls-interest@ietf.org" <hls-interest@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <71F318AC-E60E-4534-97E2-F2F50AA88140@apple.com>
References: <24D51B8B-E877-4573-8FE2-D258223B68B7@disneystreaming.com>
To: "May, Bill" <Bill.May=40disneystreaming.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3641.0.1.2.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-21_09:2020-05-21, 2020-05-21 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/SCUOqRDfRDYfTRcisdL2OY-XN-g>
Subject: Re: [Hls-interest] Determining which EXT-X-SESSION-KEY is correct
X-BeenThere: hls-interest@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions about HTTP Live Streaming \(HLS\)." <hls-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hls-interest/>
List-Post: <mailto:hls-interest@ietf.org>
List-Help: <mailto:hls-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 15:55:02 -0000

Hi Bill,

> On May 19, 2020, at 11:14 AM, May, Bill <Bill.May=40disneystreaming.com@dmarc.ietf.org> wrote:
> 
> Hi, 
> 
> In our Disney+ service, we can encode content with multiple different codecs (avc, HEVC SDR, HEVC HDR-10 and DolbyVision for video, etc).
> 
> Each of these has its own DRM requirements (hardware/software, HDCP, etc).  Each codec has its own requirement, and some require more than one key within that codec.
> 
> Some DRMs require or allow all keys to be fetched at a single time; the EXT-X-SESSION-KEY needs to reflect that (ie: for a CODEC that has more than 1, we need a SESSION-KEY entry for all combinations).
> 
> We also have a necessity to only fetch the keys that are required.
> 
> Given these requirements, we can create a number of master playlists or create them dynamically; however, these approaches really do not scale.
> 
> We’d like to be able to create a single master playlist with all CODECS and SESSION-KEYS that are available.
> 
> So, we would like a mechanism to associate a EXT-X-STREAMINF with an EXT-X-SESSION-KEY.  

I think that we could address this by allowing the EXT-X-STREAM-INF tag and the EXT-X-SESSION-KEY tag to carry the CHARACTERISTICS attribute that is already defined for the EXT-X-MEDIA tag. Something like:

4.4.6.2.  EXT-X-STREAM-INF
...
      CHARACTERISTICS

      The value is a quoted-string containing one or more Uniform Type
      Identifiers [UTI] separated by comma (,) characters.  This
      attribute is OPTIONAL.  Each UTI indicates an individual
      characteristic of the Variant Stream or of the Media Playlist
      specified by the EXT-X-STREAM-INF tag . When a Variant Stream
      has a Rendition Group for a particular media type, the CHARACTERISTICS
      of the EXT-X-MEDIA tag take precedence over the CHARACTERISTICS
      of the Variant Stream for that media type.

4.4.6.5.  EXT-X-SESSION-KEY
...
      CHARACTERISTICS

      The EXT-X-SESSION-KEY tag MAY contain a CHARACTERISTICS 
      attribute. Its value is a quoted-string containing one or more Uniform Type
      Identifiers [UTI] separated by comma (,) characters.  This
      attribute is OPTIONAL.  Each UTI indicates an individual
      characteristic of the key or keys described by the tag.

As an example of usage, say that a content vendor offers three tiers, two decodable via software-only DRM and one requiring hardware DRM support. It could have the following tags in its Master Playlist:

#EXT-X-STREAM-INF:BANDWIDTH=1000000,CODECS="avc1.640028”,RESOLUTION=640x480,CHARACTERISTICS=“com.example.sw1"
1M.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2000000,CODECS="avc1.640028”,RESOLUTION=1280x720,CHARACTERISTICS=“com.example.sw2"
1M.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4000000,CODECS="avc1.640028”,RESOLUTION=1920x1080,CHARACTERISTICS=“com.example.hw1"
4M.m3u8

#EXT-X-SESSION-KEY: METHOD=SAMPLE-AES,URI=“sw1.bin",CHARACTERISTICS=“com.example.sw1"
#EXT-X-SESSION-KEY: METHOD=SAMPLE-AES,URI=“sw2.bin",CHARACTERISTICS=“com.example.sw2"
#EXT-X-SESSION-KEY: METHOD=SAMPLE-AES,URI=“hw1.bin",CHARACTERISTICS=“com.example.hw1"

Or, for DRMs that support bundling multiple keys in a single request:

#EXT-X-SESSION-KEY: METHOD=SAMPLE-AES,URI=“sw1.bin",CHARACTERISTICS=“com.example.sw1"
#EXT-X-SESSION-KEY: METHOD=SAMPLE-AES,URI=“sw1-and-sw2.bin",CHARACTERISTICS=“ com.example.sw1,com.example.sw2"
#EXT-X-SESSION-KEY: METHOD=SAMPLE-AES,URI=“sw1-and-sw2-and-hw1.bin",CHARACTERISTICS=“ com.example.sw1,com.example.sw2,com.example.hw1"

There's some question about how far the spec would need to go in defining those semantics. In order to support a certain degree of interoperability, I could see adding a recommendation for SESSION-KEY, something like “A Client SHOULD expect a key specified by an EXT-X-SESSION-KEY tag to be required by a Media Playlist defined by an EXT-X-STREAM-INF tag or EXT-X-MEDIA tag with at least one matching characteristic in its CHARACTERISTICS attribute.”


Roger Pantos
Apple Inc.

> 
> Thanks,
> Bill May
> Disney Streaming Services
> -- 
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest