- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 31 Dec 2009 17:34:26 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "Anne van Kesteren" <annevk@opera.com>, "Edward O'Connor" <hober0@gmail.com>, "Jeremy Keith" <jeremy@adactio.com>, HTMLwg <public-html@w3.org>
On Thu, 31 Dec 2009 14:20:40 +0100, Julian Reschke <julian.reschke@gmx.de> wrote: > Tab Atkins Jr. wrote: > > ... >> It's really not what Gruber mentioned, though. He, and the rest of >> us, don't want a page with 3+ (or 50+) <video>s to start buffering all >> of them. That's obviously bad. But grabbing a little bit of >> information from each, to determine intrinsic ratios and duration? >> That's both fine, and roughly on par with downloading an image. We're >> fine with the performance of 50+ images on a page, so why do we need >> the ability to control <video> any more carefully? >> ... > > Potentially because of servers without proper partial request (byte > range) support... In such a case I think one can still decode the first frame and report the duration as +Inf (this is allowed per spec, and it is true if the resource is a live stream like a webcam). The spec also allows stalling the fetching process at any point, including just before starting it. I do think that's somewhat useful and wouldn't mind implementing it, but the behavior should be an opt-in and autobuffer="off" is a poor name for it. Perhaps autobuffer should just be renamed? -- Philip Jägenstedt Core Developer Opera Software
Received on Thursday, 31 December 2009 16:35:08 UTC