YouTube HTML5 API - is it possible to get a better time resolution when polling the player for the current time?

Question

I have been looking for a solution for this for a while, and I still have not found it. Our application should poll the YouTube video object using player.getCurrentTime() to control some screen animations. Using the flash API, it was great because we could poll the player at 40ms intervals (25 FPS) and get very accurate current player time values. Now we started using the iFrame API, which, unfortunately, does not allow anything close to this level of accuracy. I did some research, and it seems that since iFrame, a postMessage used to display the state of players in the player.getCurrentTime() call. Unfortunately, this dismissal message is very rare - sometimes only 4 times per second. Worse, the actual speed of the message seems to depend on the rendering engine for the browser.

Does anyone know if it is possible to force the rendering engine to run these messages more often, so that you can achieve more time resolution when polling the player? I tried requestAnimationFrame and this does not solve the problem. Has anyone managed to get the iFrame player to report more accurate time and more often?

Answer 1

I came up with a workaround for my original problem. I wrote a simple twin function that will test the iFrame player at the desired frequency and interpolate the time intervals between them. The player itself updates the current time every 250 ms or so, depending on the rendering mechanism and platform. If you conduct a survey more often, it will return the same current time value on several consecutive polls. However, if you apply some logic, you can detect when the player returns the new current time and updates your own timer accordingly. I run the function below on the timer at intervals of 25 ms. At each iteration, I add 25 ms to the current time, except when I detect a change in the current time indicated by the player. In this case, I update my own timer with a new “current” current time. There may be a small jump or non-linearity at the time you do this, but if you interview a player at a high enough speed, this should be invisible.

  window.setInterval(tween_time, 25); function tween_time() { time_update = (ytplayer.getCurrentTime()*1000) playing=ytplayer.getPlayerState(); if (playing==1){ if (last_time_update == time_update) { current_time_msec += 25; } if (last_time_update != time_update) { current_time_msec = time_update; } } do_my_animations(); last_time_update = time_update; } 

Answer 2

In HTML5, it is likely that the getCurrentTime () and postMessage functions in the Youtube API are associated with the currentTime property and the timeupdate event of the HTML5 media item specification.

The speed with which the timeupdate event fires varies between browsers and today cannot be adjusted to the level of accuracy you are looking for (Flash is still a bit ahead of this). According to specification :

If the time was reached by the usual monotonous increase in the current playback position during normal playback, and if the user agent has not fired a timeupdate event in the element in the last 15-250 ms and has not yet completed event handlers for such an event, then the user agent must queue the task for fire a simple event called timeupdate in the element. (In other cases, such as explicit requests, the corresponding events are activated as part of the overall process of changing the current playback position.)

An event, therefore, should not fire faster than about 66 Hz or slower than 4 Hz (provided that the event handlers do not take more than 250 ms to fire). It is recommended that user agents change the frequency of the event based on the system load and the average cost of processing the event each time, so user interface updates are not more frequent than the user agent can comfortably process when decoding video.

For the currentTime property, precision is expressed in seconds . Any accuracy below the second is a browser-specific implementation and should not be taken for granted (in reality, you will get secondary accuracy in modern browsers like Chrome, but with variable performance).

In addition, the Youtube API can throttle all of these things to get to a larger common point with an accuracy of 250 ms and make all browsers happy (therefore, 4 events per second and what you noticed in your tests). For your scenario, you should try to scale the animation to this accuracy value of 250 ms and provide some margin of error for better user convenience. In the future, browsers and HTML5 will improve, and I hope we get true millisecond accuracy.