- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 6 Jul 2010 22:34:42 -0700
On Jul 6, 2010, at 06:19, Marques Johansson wrote: > 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. Well, if you are suggesting that your use case needs to be addressed by introducing browser-side features, putting the use case on trial is a routine part of how specs are developed at the WHATWG. In particular, it's worthwhile to examine if the use case or a close approximation thereof could be addressed without adding features to the browser side. One crude approximation would be breaking the video title into chunks similar to the chunks between commercials on TV such that each chunk would be a video file and a JS-based UI would continue from one chunk to the next. This way, billing could be per chunk. (But see below for an even better way.) > 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? I think it's not particularly natural to put bandwidth rate control on the browser side or on/above the HTTP layer. I think it's more natural to control bandwidth on the TCP level, and, of the two sides of TCP, the server is the one that you can trust to do it per your parameters. The server could write data into the TCP stream only a little ahead of the playback time. This way, you could assume that the video has been played to the precision of how much data you send ahead of the playback position. To know the playback position, you could have a JS-based video player send the current playback position to the server periodically using XHR or a Web Socket connection. Whenever you receive a playback position heartbeat, you'd flush a bit more data into the video file's TCP stream and account it as viewed. Downsides: Two TCP connections instead of one, but having two data channels isn't so different from RTSP/RTP. Upsides: No additional browser features required. No need to trust the browser to do bandwidth rate control according to your parameters, since you decide how often to send the heartbeat and how much data to send per heartbeat. Avoidance of the header overhead of multiple HTTP requests (in the Web Socket case--not in the XHR case). -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 6 July 2010 22:34:42 UTC