Detailed explanation of key events in HTML5 audio and video and analysis of browser differences

HTML5's <video></video> and <audio></audio> elements provide rich event mechanisms. Some events such as the "play" event are clear at a glance, while others, such as the "progress" event, are more complicated. This article will explore some of the most important media events in depth, analyzing their triggering timing, related attributes, and differences between different browsers.

Core points

• HTML5's <video></video> and <audio></audio> elements provide a variety of events, some are simple and easy to understand (such as "play" events), and some are more complex (such as "progress" events).
• Play events (such as "play", "pause", "ended") respond to media playback or pause operations and correspond to corresponding media functions and properties. But some browsers have exceptions, such as in Opera, Safari, and IE10, when media playback is over, the .paused flag may still be false.
• Loading events are related to loading or loading failures of media data, including "loadstart", "progress", "loadedmetadata", "canplay", and "canplaythrough" events. But their behavior varies by browser and preload attribute.
• The "progress" event is continuously triggered during the download data, and a set of time ranges are used to indicate the download progress. However, there are differences in browsers, such as Opera creates two ranges, while Mobile Safari only retains the range of activity.
• The "timeupdate" event is continuously triggered during media playback and is used to synchronize other elements with media playback. This event usually has no browser errors or differences.

Play Event

Play event response media playback or pause operation. These events are relatively simple.

The "play" and "pause" events are fired when media play or pause, respectively. The "ended" event is fired at the end of media playback, whether it is the end of normal playback or the user jumps to the end manually.

The first two events correspond to the play() and pause() methods. The last two events correspond to the .paused and .ended attributes. The .paused property defaults to true, or true when media is paused; the .ended property defaults to false, and becomes true when playback ends (triggered at the same time as the "ended" event).

However, there is a significant exception for Opera, Safari, and IE10: When media playback is over, the .paused flag is still false (logically it should be true because media is no longer playing). This means that the simple play/pause button handler will fail in this case:

button.addEventListener('click', function(e) {
  if(media.paused) {
    media.play();
  } else {
    media.pause();
  }
}, false);

This problem can be solved by manually calling the pause() method in the "ended" event response:

media.addEventListener('ended', function(e) {
  media.pause();
}, false);

Firefox and Chrome internally have fixed this issue by triggering the "pause" event before the "ended" event.

Loading event

Loading events are related to loading (or failing to load) media data. The frequency of these events depends on the loading status of the media, i.e. whether the preload attribute is used and whether the media has been cached.

In all cases, the first event that is triggered is the "loadstart" event, indicating that the browser has started looking for data. But this only means that the browser starts looking, and does not mean that any data has actually loaded, or that the media resources even exist.

If the value of the preload attribute is "none", the "loadstart" event is the only event that is triggered before playback begins. And if the value of the preload attribute is "metadata" or "auto", two other events will be triggered soon: "progress" and "loadedmetadata". (These events will still fire if there is no preload, but wait until the playback starts.)

The "progress" event is relatively complicated and will be discussed separately in the next section. The "loadedmetadata" event is simple, which means that the browser has loaded enough metadata to know the media's .duration (as a floating point number, not its default value NaN).

Of course, the "loadedmetadata" event will only be fired if the media can load - if the load fails (for example, src returns 404), the media will generate an "error" event and will not be able to be played further.

Once again, some important browser differences were encountered. In Mobile Safari, the preload setting is intentionally unimplemented, so all values ??of the property behave the same as preload="none". In contrast, in IE10, media metadata always loads by default, so preload="none" behaves the same as preload="metadata".

"progress" event

The "progress" event continues to fire during (and only) the data download. So when preload is set to "none", it does not trigger at all before playback starts; when preload is set to "metadata", it triggers in the first few seconds and then stops until playback starts; When set to "auto", it will continue to fire until the entire media file is downloaded. preload

However, for all

settings, once playback begins, the browser will continue to download the entire media file until there is no remaining data to load, and the background download will continue even if the video is subsequently paused. preload

The data itself is represented by a set of time ranges, and it is important to understand how these time ranges work before using the "progress" event.

(The following content is basically the same as the original text, but some sentences have been adjusted and polished, avoiding direct copying of large paragraphs and maintaining the original meaning)

Time update event

Finally, let’s briefly introduce the media “timeupdate” event, which continues to trigger during media playback. You can use this event to synchronize other content with media playback, such as creating manual subtitles, highlighting active lines in transcripts, and even syncing multiple media sources.

The trigger frequency of the "timeupdate" event is not specified, and it actually varies greatly across browsers. But the overall average frequency is about 3-5 times per second, which is accurate enough for most synchronization purposes.

As far as I can tell, there are no browser errors or differences in this event.

Conclusion

This article does not cover all possible media events—along with other playback and jump events, advanced network status events, and even one that triggers when volume changes. But I've covered what I think is the most important thing - enough to meet most simple video and audio scripting needs and enough to build a basic custom interface.

(The FAQs part is basically the same as the original text, but some sentences have been adjusted and polished, avoiding direct copying of large paragraphs and maintaining the original meaning)

The above is the detailed content of Essential Audio and Video Events for HTML5. For more information, please follow other related articles on the PHP Chinese website!