- El evento playing se activa únicamente cuando el contenido multimedia comienza a reproducirse realmente, diferenciándose del evento play que solo indica la intención de inicio.
- Su ejecución depende directamente del readyState del elemento, requiriendo que este alcance el estado HAVE_FUTURE_DATA o superior.
- Se complementa con la API de promesas del método .play() para gestionar las restricciones de autoplay impuestas por los navegadores modernos.
Si alguna vez te has preguntado cómo demonios sabe el navegador cuándo empezar a reproducir un vídeo o un audio después de que el usuario le ha dado al botón de play, la respuesta está en el evento playing de HTMLMediaElement. Este pequeño pero poderoso mecanismo es el que nos avisa que el contenido multimedia finalmente ha arrancado, ya sea porque estábamos pausados o porque el navegador se había quedado colgado cargando datos (el famoso buffering) y por fin ha podido seguir adelante.
Entender cómo funciona este evento y en qué se diferencia de otros similares, como el evento play, es fundamental para cualquier desarrollador que quiera crear experiencias multimedia fluidas. No es lo mismo que el navegador intente reproducir algo a que realmente lo esté haciendo, y es precisamente ahí donde entra en juego la lógica de los estados de carga y los disparadores de eventos en el DOM.
La diferencia crucial entre el evento play y playing
A menudo se confunden, pero tienen funciones totalmente distintas. El evento play se dispara en el preciso instante en que la propiedad paused pasa de true a false. Es decir, es la intención de reproducir, ya sea porque llamaste al método .play() o porque el atributo autoplay hizo su magia. Sin embargo, que quieras reproducir no significa que el vídeo se mueva inmediatamente.
Aquí es donde entra el evento playing. Este se activa cuando el medio está realmente en marcha. Si el vídeo tiene que esperar a que se descarguen unos cuantos megas más para poder mostrar la primera imagen, el evento play ocurrirá primero, pero el evento playing esperará a que haya datos suficientes para que la reproducción sea efectiva. En resumen, uno es la orden y el otro es la ejecución real.
Estados de preparación del medio (readyState)
Para que el evento playing se dispare, el elemento debe alcanzar un estado de preparación específico. El navegador utiliza el atributo readyState para rastrear cuánta información tiene disponible:
- HAVE_NOTHING: No hay nada cargado. El evento playing no tiene ninguna posibilidad de ocurrir aquí.
- HAVE_METADATA: Ya conocemos la duración y el tamaño del vídeo, pero aún no hay datos reales para reproducir.
- HAVE_CURRENT_DATA: Tenemos el frame actual, pero no el siguiente. Es posible que el vídeo se detenga casi al instante.
- HAVE_FUTURE_DATA: Aquí es donde la cosa se pone interesante. Hay datos suficientes para avanzar un poco sin detenerse. El evento playing se dispara generalmente cuando pasamos a este estado o superior y no estamos pausados.
- HAVE_ENOUGH_DATA: El navegador estima que puede reproducir todo el archivo sin cortes por falta de buffering.
Cómo implementar el evento en tu código
Para capturar este momento, lo más recomendable es usar el método addEventListener, ya que permite añadir varios escuchadores sin pisarse unos a otros. Por ejemplo, puedes seleccionar tu elemento de vídeo y asignarle una función que ejecute una acción justo cuando el contenido empiece a moverse.
También existe la propiedad onplaying, que es más directa, pero tiene una pega: si asignas una función a onplaying y luego otra, la segunda borrará a la primera. Por eso, si quieres mantener un código limpio y escalable, quédate con addEventListener. Recuerda que este evento no es cancelable ni burbujea, por lo que debes escucharlo directamente en el elemento de audio o vídeo.
Otros eventos multimedia que debes conocer
El ecosistema de HTMLMediaElement es amplio y el evento playing convive con otros que te permiten controlar el flujo del usuario. Por ejemplo, el evento seeking se dispara cuando el usuario mueve la barra de progreso para saltar a otra parte del vídeo, mientras que el evento seeked nos avisa que el salto se ha completado y el nuevo frame ya es visible.
También tenemos el evento waiting, que es el archienemigo del usuario: ocurre cuando la reproducción se detiene porque no hay datos suficientes en el buffer. Lo curioso es que, una vez que el buffer se llena y el vídeo vuelve a arrancar, se dispara nuevamente el evento playing, cerrando así el ciclo de espera y reproducción.
El desafío del autoplay y las promesas
Hoy en día, los navegadores son muy estrictos con el sonido automático para evitar sustos al usuario. Por eso, el método .play() ahora devuelve una promesa de JavaScript. Si la reproducción comienza con éxito, la promesa se resuelve; si el navegador la bloquea (porque no hubo una interacción previa del usuario), la promesa se rechaza.
Esto es vital porque, en algunos casos, el navegador puede retrasar la reproducción (por ejemplo, si la pestaña no está visible). La promesa no se cumplirá hasta que el medio realmente empiece a sonar o verse, lo que hace que sea una herramienta mucho más fiable que intentar adivinar el momento exacto basándose solo en el evento playing.
Gestión de pistas y metadatos
Más allá de la reproducción, los elementos de medios gestionan pistas de texto, audio y vídeo. Las TextTracks permiten añadir subtítulos o descripciones que se sincronizan con la línea de tiempo. Estos elementos tienen sus propios eventos, como cuechange, que nos indica cuándo un subtítulo entra o sale de la pantalla.
Es importante mencionar que el manejo de estas pistas puede afectar al rendimiento. Por eso, se recomienda que los desarrolladores liberen los recursos del elemento multimedia cuando ya no se necesiten, ya sea eliminando todas las referencias al objeto o vaciando el atributo src, evitando así que la memoria del dispositivo se sature innecesariamente.
La interacción entre los estados de red, la preparación de los datos y los disparadores del DOM permite que el evento playing sea la señal definitiva de que el contenido multimedia está activo y visible para el usuario, diferenciándose de la simple intención de reproducir y coordinándose con el sistema de promesas moderno para garantizar que la experiencia sea estable independientemente de las restricciones del navegador.