[whatwg] More YouTube response

On Mon, Jul 5, 2010 at 11:45 AM, Nils Dagsson Moskopp
<nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:
> Practically, I think the ball is / was in Apple's court to decide this.
> While to this day other browser makers have decided to ship two (!)
> royalty-free video formats (Theora and VP8), Apple is the single H.264
> holdout, and they have a tight itegration to their hardware as well.

Internet Explorer 9 will not support VP8 unless the user manually
installs the codec.  This puts it at the same level of support as
Safari has for Theora, as far as I know.  So even if we assume every
user upgraded to the latest alphas of the browser they used, H.264 is
supported by about 65% of users' browsers, and VP8 by about 40%.  Of
course, in reality, less than half of users' browsers support <video>
at all right now, and given IE uptake rates, that's only going to
change slowly.

On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson <marques at displague.com> wrote:
> 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.

There's no way to stop this at the markup level, since the user could
just configure a user-agent to ignore the attributes, or manually
remove them with a tool like Firebug.  More to the point, since this
feature doesn't provide significant benefit to many users or authors,
no user agent would bother implementing it in the first place.

You should instead look into to writing server-side scripts that meet
your needs.  When the user requests a video, have the script check how
much video the user is authorized to view, and just truncate it after
that point.  Or have it insert an extra clip at the end of what
they're allowed to view saying "you have to pay more to keep viewing",
then truncate it.  Or whatever.  This is pretty easy to do, and not
possible for the user to circumvent.

> 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).

Well-written clients should already buffer only as much as they need
to ensure the video will play smoothly.  The preload="" attribute is
already provided to allow authors to control this behavior.  When the
client has read enough for now, it will just stop reading new content
from the server until it needs more.  If the server thinks that the
client is reading too fast, on the other hand, it can just send fewer
packets.  Again, I don't think anything needs to be changed in HTML
here.

Received on Monday, 5 July 2010 13:26:44 UTC