The company I work for, VOD.com (sfw) (aka Hotmovies .com and clips .com - nsfw (spaces added)), offer video on demand services to thousands of studios.  Our sites are central locations for customers who want to watch something - this is a service in itself.  We handle encoding and content distribution and streaming sales for these studios without any cost to them.  They send us video content and we send them a monthly check. Without services like the ones we provide many of these studios (some are mom and pop shops) wouldn't otherwise have the ability to sell their content online in this fashion.  <div>

<br></div><div>Customers can watch movies by purchasing packages of time or paying for DRM protected rentals or for some of our sites and videos they can pay for unprotected video.  The protected content (rentals) comes in the form of WMV or DivX files using either DivX's service of Windows Media Server.</div>

<div><br></div><div>For the content that is not protected the download or stream is metered so the client can be charged only for the time they spent watching the content.  We error on the customer's side for things like buffering and misreported play segments.</div>

<div><br></div><div>I think the discussion that DRM is irrelevant has its merits, but the contracts and services at play have a real value regardless of how distribution is restricted.</div><div><br></div><div>For my purposes I am interested in application-controlled video delivery.  I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way.  If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM.  If we need additionally protection we can add watermarking to legally go after content thieves since we know the IP and username of the viewer in most cases.</div>

<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>My requests have focused on things like "<video minbuffer=100k maxbuffer=200k>" which could also apply to a source element.  I want to make sure that the browser always uses "Range: bytes x-y" in requests (since I have no other way to require that a browser use ranges or use ranges with an upper bound).  I can use this tool to make sure UAs do not download more content than the user has watched (which costs them money in some way).  I've also been suggesting HTTP changes that would permit this UA behavior (a 4xx for Ranges Required, a 4xx for Range too large, or explicitly defining that a 206 response can include less bytes than requested and the UA should follow-up with additional ranged requests).</div>

<div><br></div><div>While an HTML5 solution is easy to make possible as their is no legacy to worry about and the spec is still floating about, an HTTP solution would allow me to provide metered content flow without leaving HTTP sessions open (throttling) and without the need for a video element - permitting users to use their native http streaming players.</div>

<div><br></div><div>These requests can be seen as generally allowing servers to reduce load for video or large file downloads.  Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content.  I would like to see the server have the ability to enforce this (through HTTP errors) or at least suggest it (through HTML5 attributes or additional HTTP headers).<br>

<div class="gmail_quote">On Mon, Jul 5, 2010 at 2:51 AM, Mikko Rantalainen <span dir="ltr"><<a href="mailto:mikko.rantalainen@peda.net">mikko.rantalainen@peda.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

2010-07-05 01:56 EEST: David Gerard:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 4 July 2010 13:57, bjartur<<a href="mailto:svartman95@gmail.com" target="_blank">svartman95@gmail.com</a>>  wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I fail to see how BBC would be harmed by the usage of alternative<br>
software. Its business model is about content, not software, right?<br>
</blockquote>
<br>
See, you're using logic and sense ... about half the BBC want to just<br>
*make their stuff available*, the other half are worried about the<br>
thicket of laws and agreements that made sense in the days of analogue<br>
tape broadcast on analogue television that, despite not making sense<br>
on the Internet, still bind them legally. (Broadcast rights, residuals<br>
for actors and writers, etc.) These are serious and real concerns and<br>
they can't just ignore them.<br>
</blockquote>
<br></div>
So, you're arguing that DRM is not required, right?<br>
<br>
Basically the whole problem is about how current content distributors (e.g. BBC) have made stupid contracts in the history and are trying to work around those stupid contracts with DRM instead of doing the right thing and do one of the following:<br>


<br>
(1) renegotiate the contracts to allow redistribution, or<br>
(2) stop trying to redistribute content you don't have proper rights to do.<br>
<br>
Especially, the content distributors should immediately stop pretending that DRM allows for any kind of protection. It's mathematically impossible. It's like trying to send an encrypted message to Bob with a requirement that Bob cannot have access to the message. That problem cannot be solved. For that problem, a decision needs to be made:<br>


<br>
(1) Bob is allowed to get access to the message, or<br>
(2) Bob is not allowed to get access to the message (never send it!)<br>
<br>
Notice how this is similar to the DRM case above?<br>
<br>
Introducing a DRM system is about *trying to not do the decision* if you really *want to distribute the content or not*. Such system should not ever be standardized because it really cannot ever work, by definition.<br>
<br>
-- <br><font color="#888888">
Mikko<br>
</font></blockquote></div><br></div>