On Mon, Jul 5, 2010 at 10:25 PM, Henri Sivonen <span dir="ltr"><<a href="mailto:hsivonen@iki.fi">hsivonen@iki.fi</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Jul 5, 2010, at 13:10, Marques Johansson wrote:<br>
<br>
> 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.<br>
<br>
</div>There'd be no problem if you were selling content by title (plus free trailer for sampling) instead of selling it by minute.</blockquote><div> </div><div><div>If a user is paying for bandwidth why should they need to pay for a download of the full movie when they are only interested in a few scenes or a few key seconds of the video.</div>
</div><div><br></div><div><div>A friend of mine called this weekend to confirm that a scene in Back to the Future 3 that has been popping up online was actually in the movie and not just some Internet hoax. He called to have me watch a particular segment on the DVD. I watched all of 3 minutes of the movie to confirm the original scene contents. Doc Brown's young blond haired train companion (who only appears at the end of the movie) displays a very preverse set of gestures in his 10 seconds of screen time that should have been edited out (I dodged all spoilers). There is a market for this kind of viewing habit that does not insist on the consumer purchasing a full right/license to the entire video nor the bandwidth or storage to accommodate it.</div>
</div><div><br></div><div>When you are selling adult content - many users are much happier to pay for a few minutes of content that they seek through rather than a full movie that they will have little interest in watching again. The difference can easily be $.16 versus $16. As for trailers, many of our plans include additional time and all users that have ever purchased get 3 free 30 second plays weekly. That being said, I don't think the business models of one of the largest online video markets should put be on trial through a by a standards list.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> 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.<br>
<br>
</div>I think the technology providers shouldn't feel an obligation to cater to particular contract models--especially when it complicates the technology. It makes more sense to draft contracts that are reasonable given the technology. (An example of a contract that I think technology providers shouldn't attempt to cater for is a content licensing contract that tries to distinguish between desktops, mobile devices and TVs. Such a contract makes no sense when devices of any kind can support the same standards.)</blockquote>
<div> </div><div>I think providers cater to the technology that's available. At the time these contracts were drawn up Windows Media player and Real were leading the streaming video market. The contracts and services in place now were created pre-Youtube, when most users accessed the site with a 56 modem or less. The service was geared toward online streaming and streaming rentals rather than downloads - which could take some users days to complete - or longer when coupled with bad re-try behaviors in browsers. Cell phones couldn't play let alone download a video over their 14kbps connection. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> 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.<br>
<br>
</div>If the customers pay for seeing an entire title, why is it a problem if a customer once in a while downloads the bytes twice? Surely it is simpler to bake the average bandwidth cost into the price and not complicate the way the delivery technology behaves.</blockquote>
<div><br></div><div>We have different plans available. Some allow a user to stream a chosen video as often as they want. There are plans that allow users to stream an entire studios selection of videos on demand. This likens the service to a monthly membership site and the company I work for has found that many users prefer to not have that sort of commitment - preferring instead to pay for what they watch when they watch it. The choice is determined by the content provider and the user - we accomodate both parties to the best of our ability. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> 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.<br>
<br>
</div>Wouldn't this be a non-problem if the customers paid by title? In that case, it would seem pointless to worry about the content getting downloaded faster than it is played.<br>
<br>
It seems to me that your problem is picking a pricing model that's unnatural for the technology.</blockquote><div><br></div><div>Partial requests are native to HTTP and seeking is natural for a healthy streamed viewing habit - I'm look for a way to get the browser to take the servers recommendation that the content be fetched in a particular way - we have content negotiation of transfer encoding and image quality, why not allow the server to negotiate the transfer size for the benefit of the user and the server?</div>
</div>