Avec Media CDN, vous pouvez utiliser l'infrastructure étendue et à faible latence de Google pour la journalisation et la diffusion de journaux afin d'associer des journaux par requête à un seul événement de lecture. Cela vous permet de comprendre comment le trafic a été diffusé (emplacement périphérique, conditions du réseau, sélection d'origine et erreurs) pendant toute la durée de la lecture.
Cela est rendu possible :
- En vous permettant de fournir un ID de lecture généré par le client sur plusieurs requêtes.
- En offrant une intégration à Cloud Logging pour interroger les lectures et les requêtes individuelles
- En exportant et en interrogeant les données avec BigQuery ou avec la plate-forme de votre choix L'analyse de données à grande échelle vous permet d'examiner les latences agrégées et les formats de diffusion pendant toute la durée de lecture.
En association avec une journalisation en quasi-temps réel, le traçage de lecture vous permet de mettre en corrélation les sessions de lecture et la qualité globale de l'expérience par emplacement, par flux ou par réseau client, et d'agir rapidement en cas de problème.
Tracer une lecture
Pour associer plusieurs requêtes à une session de lecture d'utilisateur, vous devez générer un ID pour cette lecture dans votre client. Le traçage de lecture fonctionne en incluant la valeur d'un en-tête ou d'un paramètre de requête dans tous les journaux de requête associés.
Des lecteurs tels que Shaka, ExoPlayer et AVPlayer d'Apple vous permettent de capter des événements de démarrage de lecture et d'ajouter des paramètres de requête et des en-têtes HTTP aux requêtes effectuées pour cette source multimédia en streaming
Les en-têtes et les paramètres de requête sont définis comme suit :
- Un en-tête de requête HTTP :
Playback-Trace-ID - Un paramètre de requête d'URL :
playback-trace-id=
L'en-tête HTTP est utilisé à la place du paramètre de requête, s'ils existent tous les deux dans une requête.
- L'ID de lecture doit être compris entre 12 octets (96 bits) et 32 octets (256 bits au maximum) et être généré à partir d'une source aléatoire.
- Les ID de lecture inférieurs à 12 octets ne sont pas consignés. Cela permet d'éviter les conflits.
- Les ID de lecture de plus de 32 octets sont tronqués aux 32 premiers octets.
Les ID de lecture doivent être uniques sur une période de sept jours. Après cette période de sept jours, lorsque les ID de lecture sont réutilisés ou en conflit, chaque ensemble de requêtes est traité comme une lecture distincte.
Exemple : Générer un ID de lecture dans le lecteur Shaka
Pour bénéficier du traçage de lecture à grande échelle, chaque lecture de vidéo utilisateur doit inclure un ID de lecture pour toutes les requêtes effectuées pour des segments (et éventuellement, pour des fichiers manifestes). Cet ID de lecture doit être identique pour toutes les requêtes d'une lecture afin de cumuler les statistiques globales.
L'exemple suivant :
- Génère un ID de lecture lors du chargement de la vidéo.
- Ne l'envoie que lors des extractions de segments, et non pour les fichiers manifestes.
Si vous souhaitez utiliser un ID de lecture existant, tel que celui fourni par votre système de gestion de contenu et par vos outils d'analyse côté client, attribuez cette valeur à playbackSessionId.
let playbackSessionId;
player.addEventListener('loading', () => {
const randomBuffer = crypto.getRandomValues(new Uint8Array(16));
playbackSessionId = shaka.util.Uint8ArrayUtils.toBase64(randomBuffer);
});
player.getNetworkingEngine().registerRequestFilter((type, request) => {
// Remove this "type" check if you want the header on every request.
// Alternately, you can check the request.uris array to send the
// header to some servers and not others.
if (type == shaka.net.NetworkingEngine.RequestType.SEGMENT) {
request.headers['CPN'] = playbackSessionId;
}
});