Open haudiobe opened 10 years ago
The profile should not guarantee the use of root and leaf licenses and should be open e.g. for all licenses to be the same (e.g. all root licenses, incl key that change).
Niels' answer does not answer the question. We need to clarify that the keys need to be available for segments to decode in time. This is the requirement. Hence, the above situation may occur, but it should avoided and the content provider should be aware of the consequences when doing this. It is unlikely that it is possible to acquire the root license in real-time.
Please add clarification on this, if considered suitable. => Niels
Q>When root license is acquired at startup the client wouldn't have to repeat that. A> Actually Root License can be changed every 2 to 24 hours depending on content provider policy. Such extreme scenario is allow to cut channel faster if a user canceled their subscription.
Q>Do you think DASH264 profile guarantees this A> No DASH264 profile not guarantees this.
Q> or should the client be prepared for a root license change as well? A> Yes client must be prepared for a root license change as well.
Q>I can see it constrains it within an adaptation set but is it across periods also? A>There is no limitations. Period can have different keys.
Q>Say when a new period starts, should the client expect new root license information (e.g. pssh with LA URL or new MPD@ContentProtection) because the content in new period is served by a different license server? A>Client should expect new root license information. Basically client should always check if there is license present to decrypt segment. If not then license must be received from license server.
It is unlikely that it is possible to acquire the root license in real-time.
I think this is a good point and we should consider the timing here that could be allowed for key acquisition or provide means for advanced notice since the acquisition may take time.
Q> or should the client be prepared for a root license change as well? A> Yes client must be prepared for a root license change as well. As long as it is a new Period and it fetches a new Initialization Segment, and you don’t expect that license acquisition to be seamless.
Kilroy Hughes | Senior Digital Media Architect | Azure Media Services | Microsoft Corporation [cid:image001.png@01CDABBA.71FD8800]http://www.windowsazure.com/media
From: Niels [mailto:notifications@github.com] Sent: Monday, March 31, 2014 9:25 PM To: Dash-Industry-Forum/DRM Subject: Re: [DRM] Contact License Server during Operation? (#15)
It is unlikely that it is possible to acquire the root license in real-time. I think this is a good point and we should consider the timing here that could be allowed for key acquisition or provide means for advanced notice since the acquisition may take time.
— Reply to this email directly or view it on GitHubhttps://github.com/Dash-Industry-Forum/DRM/issues/15#issuecomment-39130115.
in DRM discussion we do agree that there is a potential timing problem for live content if the key is always required immediately and for clients in the same time. it's the responsibility of the DRM to signal information about when to fetch next keys. we added to 1.4.3 : a section: License and key delivery scheduling It is recommended for the DRM client to a) prefetch the license as soon as the MPD is received (in particular before the content start time)to allow more time for multiple recipients to perform the acquisition. b) prefetch license at the start of each Period to avoid media synchornized requests from all users. c) predeliver keys referenced by Sample Groups...
intend is to turn this into content requirements, action item on Kilroy
A key issue is to minimize the chances of client having to contact license server once playback has started. In a DRM system with scalable root/leaf licenses, this would typically mean that once a root license is acquired at startup the client wouldn’t have to repeat that. Do you think DASH264 profile guarantees this or should the client be prepared for a root license change as well? I can see it constrains it within an adaptation set but is it across periods also? i.e. Say when a new period starts, should the client expect new root license information (e.g. pssh with LA URL or new MPD@ContentProtection) because the content in new period is served by a different license server?