- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 1 Jan 2010 12:42:43 +1100
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "Tab Atkins Jr." <jackalmage@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 Fri, Jan 1, 2010 at 4:02 AM, Philip Jägenstedt <philipj@opera.com> wrote: > On Thu, 31 Dec 2009 17:45:29 +0100, Julian Reschke <julian.reschke@gmx.de> > wrote: > >> Philip Jägenstedt wrote: >>> >>> ... >>>> >>>> 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). >>> ... >> >> In that case you'd need still to do a complete GET, and then abort the >> connection (unless I'm missing something). Not good.. >> >> Best regards, Julian >> > > Why is that not good, and how could the browser possibly know that the > resource is not seekable without trying to GET it? > > In any case, I think we should always try to get the first frame and > duration unless we spec an opt-out from that behavior, the implementation > details are quite beside the point. Yes, either the first frame or the poster frame. And since the duration could be done through a Content-Duration HTTP header, it would mean not downloading anything for the video, which is identical to putting a img there with a javascript link to replacing the img element with a video element. I like this approach. It may well be that autobuffer isn't the right name for this. I used the word "initialise" before, but I'm not sure that's a good word either for setting up the decoding pipeline. There is definitely a difference between "no download of video" - "decoding setup only" - and "full resource download". Regards, Silvia.
Received on Friday, 1 January 2010 01:43:35 UTC