On Sun, 23 Jan 2011 12:13:15 +0100, Glenn Maynard <gl...@zewt.org> wrote:
On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt <phil...@opera.com>
wrote:
I do think that in the basic case of a user pressing play on a video
player, it's good to be able to make that respond instantly rather
than waiting for a round-trip to begin playing.
Have you found this to be an actual problem in Firefox, which does
suspend
download after reaching HAVE_METADATA?
It's not a big problem, but a user experience one: user interfaces are
cleaner when they're immediately responsive. I'd sooner give a crisp
interface to users than one that feels delayed.
Just to be clear, I'd be happy to add a fourth preload state to cater to
this, I just want to be very clear that there is an actual problem first.
Another use case is the background of a game, where you want the video
ready to start when gameplay begins.
For that you should really use <audio preload=auto>, no?
Not if all you want is for the video to start with the rest of the game,
and
not to download the whole video.
But presumably you want some kind of guarantee that the video will be able
to keep playing without waiting for the network, right? So if you don't
use preload=auto, you'll at least need preload=playthrough or similar.
Maybe that's precisely what you mean by preload=buffer?
They're both minor, of course; helpful side-effects of preload=buffer,
not
sufficient justifications by themselves.
Hmm. To get this effect without preload=buffer, you could set
preload=auto,
watch the buffered attribute to see when some data is actually
downloaded,
then set it to preload=metadata to stop autoloading. That's a minor
hack,
and would need to watch out for browsers that don't autoload on
preload=auto, but it's probably good enough for the above cases. It'd
only
work if runtime changes to preload are applied, which would also be
needed
for scripts to implement "preload=auto only when paused".
I intend to make that impossible by only allowing scripts to increase the
effective buffering strategy, because:
1. preload->none makes no sense.
2. I haven't seen any use cases for auto->preload other than working
around browser buffering bugs.
3. It would be a silly API, because you can't reasonably mean "I need it
all! No, I need only metadata! No, I need it all!", you're clearly trying
to do something else.
By not catering to that, we can instead focus on fixing the
API/implementations to support the actual use cases authors might have.
--
Philip Jägenstedt
Core Developer
Opera Software
