[whatwg] More YouTube response

On Mon, 5 Jul 2010, Marques Johansson <marques at displague.com> wrote:
> 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.
If I understand correctly, you are content distributors and video encoders.

> 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.
So you sell copies for money and a promise to delete the copy after
it's use. That's like selling a book, printing "Burn after reading"
on it and calling yourself a library. Also the book shall not be used
for "unauthorized uses", e.g. put under a table foot, lent to a friend
or read repeatedly. The latter two cases may be solved by going to the
"library" and buying another copy, other can't.

Many people see DRM as an hybrid between a lock and a automagical fire
lighter.

> 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.
This seems like a saner alternative.
> 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.
> 
> 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.
Once a user has bought a copy, the copy has been bought and how
(often) he uses said copy isn't your probem. You've successfully
distributed and charged for the content. Job's done. A technical user
will probably be able to copy the video to permanent storage whatever
you do. Multi-pricing can also be achieved by other means, such as by
resolution crippling. Watermarking to aid with tracking down grand scale
pirates seems to be an OK thing to do.

> 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).
> 
> 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.
> 
> 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).
Server load can also be reduced by e.g. P2P, though users may want the
price to drop in proportion to their uploads.

Received on Monday, 5 July 2010 16:53:14 UTC