[whatwg] Video Element Events? - Use Case: Custom Progress Bar

[Eric Carlson]

Ian -

On Oct 28, 2008, at 10:36 PM, Chris Double wrote:

> On Wed, Oct 29, 2008 at 5:22 PM, Charles Iliya Krempeaux
> <supercanadian at gmail.com> wrote:
>>
>> Perhaps I didn't read the spec carefully enough, but I don't see  
>> any such
>> event.
>
> You're looking for the 'timeupdate' event. This gets raised whenever
> the current playback position changes. From the spec section 4.8.10.8:
>
> "If the time was reached through the usual monotonic increase of the  
> current
> playback position during normal playback, the user agent must then  
> queue a task
> to fire a simple event called timeupdate at the element. (In the  
> other cases,
> such as explicit seeks, relevant events get fired as part of the  
> overall
> process of changing the current playback position.)"
>
> Although this is hidden away in the cue ranges section, it happens on
> normal playback without cue ranges.
>
   I think requiring a user agent to post events as a movie plays is a  
mistake. It will mean that *every* page will incur the overhead, even  
if no scripts are listening for the events.

   I understand that some pages will need to keep scripted UI in sync  
with movie playback, but this can be done very easily with a  
JavaScript timer:

	document.addEventListener('play', updateTimeDisplay, true);
	document.addEventListener('pause', updateTimeDisplay, true);

	function updateTimeDisplay()
	{
		var vid = document.getElementById('video');
	
		if (!vid.paused && !vid.ended && vid.networkState >  
HTMLMediaElement.HAVE_FUTURE_DATA)
			setTimeout(updateTimeDisplay, 200);
		
		// update display here
	}

   Using a timer also allows a script to update at exactly the  
frequency they need instead of at whatever frequency the UA happens to  
post events.

   Video and audio playback is already extremely CPU intensive, we  
shouldn't require the UA to burn extra cycles doing unnecessary work.

eric