On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson
<marq...@displague.com> wrote:
On Mon, Jul 5, 2010 at 4:26 PM, Aryeh Gregor
<simetrical+...@gmail.com<simetrical%2b...@gmail.com>
wrote:
On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson
<marq...@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.
If the UA didn't follow the prescribed size constraints they would get a
403
response (or a better 4xx range too large if it existed).
The benefit to the user is that they could have less open network
connections while streaming video from server controlled sites and those
sites will have the ability to meter their usage more accurately.
Inserting an extra clip at the end is more of a playlist or scripting
answer. Or perhaps a a live re-encoding answer. I'm looking for a way
to
give the user the raw video file in a metered way. A 200 response or
partial 206 responses that returns less than the full requested range is
not
handled by browsers in a consistent or usable way (for this purpose).
Only
Chrome will continue to fetch where the previous short 206 response left
off
(request 1-10, server replies 1-5, request 6-10, server replies 6-10).
The
HTTP spec isn't clear about whether UAs should take this behavior - and
so
they don't.
Some UAs request video without sending "Range: bytes 0-". The server
has no
way to negotiate that the UA (a) must use ranges to complete the request
or
that (b) the range requested is too large, retry will a smaller range.
The first request is tricky for the browser too. Having no idea of how big
the resource is or what the bitrate is, there is no bounded request that
makes sense, in my opinion. The downside is that for a conservative
approach, the only solution is to abort the connection half way through,
with the server having no idea when this will happen. I haven't seen any
negative effects of this in practice yet, but this thread has me thinking
that it could be better. Handling a short reply gracefully would be a good
start.
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.
All of the current video clients make requests like "Range: 0-" or (when
you
seek) "Range: 0-end_of_file". I don't want to give them the whole 2gb
file
right now, they may seek to the end of the video at any moment while the
server is paying to send that data and the transfer will have been
wasted.
I don't want to throttle the connection because that is also a waste of
resources. I want the UA to request X many bytes (which equates to some
fragment of time), disconnect if they will be busy beyond the keep-alive
time, and come back when they need more video data. A 200 response and
an
unbounded 206 response do not permit this.
If the <video> tag included a minbuffer and a maxbuffer (at least the
latter) then the client would always have an upper bound on video ranges
requested. If the UA failed to include this the server can give them a
403,
416, or some 4xx that does not yet exist.
Let's wait until preload="" is actually implemented to see if more
fine-grained control is actually needed.
--
Philip Jägenstedt
Core Developer
Opera Software
