[Bug 20964] EME depends on servers with a finite life.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20964

--- Comment #7 from Fred Andrews <fredandw@live.com> ---
(In reply to comment #6)
> (In reply to comment #5)
> > Firstly, the notion of 'streaming' is an artificial construct of the DRM
> > industry that has no technical foundation and is foreign to the working of
> > the web browser.  Web browsers are free to store content to their capacity
> > for presentation at the will of the user.  If videos content authors wish to
> > present content on the web browser then they need to respect the operation
> > of the platform rather than attempting to re-purpose it for their own market
> > segmentation goals.
> 
> You may be thinking only of streaming video in the VOD (video on demand)
> model. There are other use cases for streaming video, e.g. low latency
> live/near-live events, variable bitrate, large scale viewing, etc. This
> method for delivering content is useful entirely independent of whether or
> not DRM is in use.

I agree, 'streaming could be defined in many of these ways independently of
DRM, but these definitions would not be the artificially restrictive
definitions used in conjunction with DRM.

For example, in all the examples you give above the UA is able to store the
content and to control the presentation to be best of its ability, and this
gives the user a choice to view the content even after the server is
decommissioned.  

Granted, that if the user chose to only download a low bit rate version of the
content and this was stored, and the server was subsequently decommissioned,
then the user would not have access to the high bit rate version from the
server.  But this is the case even for access to HTML content requiring
authorization.

The artificial 'streaming' restriction supported by the EME model does not give
the user the choice to view content already received after the server is
decommissioned.  Granted, a particular CDM may not place this restriction on
content, but this is not the point - the EME standard should not ALLOW such
restrictions.

If the back channel was removed from the EME, or if it was a defined and
transparent channel for content selection then many of the issue would be
resolved and EME would be a better prospect for fitting within the web
architecture.  For example, a back channel that allows a request for a change
in the bit rate to be sent to the server would likely be consistent with the
web architecture, and so would a back channel that was used to request the next
segment of a video.  The UA would be able to store the received content and
replay it even after the server was decommissioned.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 21 February 2013 23:44:23 UTC