[Moved to dev.tech.network] On Thu, 2012-03-01 at 12:51 +0100, Ashwin Rao wrote:
I have a suggestion regarding streaming HTML5 videos. Currently Firefox does not restrict the rate of data transfer while streaming HTML5 videos. Google Chrome and Internet Explorer however restrict the rate of data transfer. I have detailed out these rate restrictions in a preliminary work available at hal.inria.fr/inria-00638063/en/
On 03/01/2012 07:53 AM, Patrick McManus wrote:
This is actually a design item we've already incorporated for an upcoming implementation of the DASH framework. I don't recall having talked about it in the scope of normal video/webm stuff but you're absolutely right that it applies there.
Yes, we should do it for all video.
I've cc'd some folks who are hands on with the video projects - hopefully they can chime in here an incorporate this. Its an important topic. Can the right person file a bug?
One big question is: at what level should we be doing this? The obvious two choices are to 1) have the video layer control download speed by calling suspend/resume on the network channel as needed. That's a pretty blunt hammer; or 2) add some sort of API to necko that lets the consumer specify what sort of bitrate they need to get out of the channel, and have necko deal with controlling the rate. Of course, TCP doesn't exactly give us great tools for rate control either: besides simply not reading from the socket (same as suspending channel). we could fiddle with incoming OS socket buffer sizes, anything else? Perhaps we should start with suspend/resuming the channel, so we can make progress quickly, and keep an eye on how necko internally could facilitate things.
Thoughts? Jason
(jason, steve, josh, roc: here is a simple http://devfiles.myopera.com/articles/1891/sunflower-webm.html html5 video page with 22 seconds of video, which I see all come down in 1 chunk as fast as possible.. iirc some videos will use multiple chunks spread over time, but even that should be ratepaced where possible to share the network more effectively.. not sure how effectively that is currently happening) -Pat
_______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
