Résumé

  • Avec application/ogg, la présence de Skeleton est une exigence d’inventaire; le fait qu’un codec familier produise du son ou une image ne prouve pas la conformité du conteneur.
  • Il faut séparer type déclaré, structure Ogg, liste des flux logiques, capacité de décodage, traitement de chaque flux et résultat présenté.

Le succès local masquait le défaut du contrat

Un service reçoit un objet application/ogg. Le lecteur trouve un flux Vorbis connu et commence à le jouer. La supervision conclut que le fichier est valide. Pourtant, le conteneur ne contient aucun flux Skeleton. Pour RFC 5334, ce détail n’est pas décoratif: les données servies sous ce type doivent fournir Skeleton afin d’identifier les autres flux logiques.

Le succès du lecteur prouve seulement qu’un chemin local a su décoder quelque chose. Il ne dit pas combien de flux existaient, lesquels ont été ignorés, ni si une application scientifique ou un contrôle scriptable a perdu une composante essentielle. Une implémentation tolérante peut rendre l’objet utilisable tout en laissant son contrat descriptif incomplet.

Cette asymétrie est dangereuse dans les chaînes industrielles. Le premier lecteur transforme «j’ai décodé un flux» en «le fichier est conforme». Le catalogue reprend cette conclusion. Un transcodeur conserve uniquement ce qu’il reconnaît. À la fin, l’absence d’inventaire initial devient une prétendue preuve que les flux supprimés n’ont jamais existé.

Trois types, trois usages dominants

RFC 5334 corrige l’emploi historique de application/ogg comme étiquette universelle. Cette généralité cachait la nature audio ou vidéo de contenus ordinaires. Le texte redéfinit donc application/ogg pour les ensembles complexes et multiplexés, recommande video/ogg lorsqu’une interface visuelle est requise, et audio/ogg lorsque l’audio prédomine.

Ces classes ne sont pas trois boîtes étanches. Une présentation vidéo peut réunir image, son, texte temporisé et métadonnées. Un objet principalement audio peut conserver paroles, métadonnées et pochette. L’étiquette oriente l’interface et le traitement initial; elle ne décrit pas exhaustivement chaque flux interne.

Le mot «principalement» doit survivre au passage dans les bases de données. Remplacer audio/ogg par un attribut containsOnlyAudio=true est une invention. Remplacer video/ogg par «chaque piste est visuelle» l’est aussi. Le type est exact dans sa portée et trompeur seulement quand un système agrandit cette portée sans preuve.

Skeleton nomme; il ne décode pas

Un flux physique Ogg peut multiplexer plusieurs flux logiques. Skeleton fournit des identifiants capables d’annoncer ces composants sans décoder d’abord toutes leurs pages d’en-tête. L’exigence est forte pour application/ogg et seulement recommandée pour video/ogg et audio/ogg.

Cette différence interdit deux raccourcis. L’absence de Skeleton dans application/ogg ne devient pas acceptable parce qu’un flux connu fonctionne. Et son absence dans audio/ogg ne démontre pas que le conteneur est simple ou monoflux. Dans ce second cas, l’inventaire peut encore nécessiter l’analyse des en-têtes logiques.

Même présent, Skeleton ne garantit pas la disponibilité d’un décodeur. Il établit une description, non une capacité. Un flux peut être correctement identifié puis refusé, ignoré, limité pour consommation excessive ou rendu impossible par des paramètres particuliers. L’inventaire est la condition du diagnostic, pas son verdict final.

Ignorer un flux inconnu peut être conforme

RFC 5334 recommande de poursuivre le décodage des flux compris lorsqu’un autre flux identifié ne peut pas être décodé. Cette règle protège la compatibilité ascendante et descendante. Elle permet à un ancien lecteur de produire une partie utile d’un conteneur enrichi.

Mais «ouvert» ne signifie alors pas «complet». Un service d’écoute grand public peut accepter la perte d’une piste auxiliaire. Une archive, un outil d’accessibilité ou une chaîne de preuve peut l’interdire. La politique doit préciser quels flux sont obligatoires et comparer cette exigence au résultat par flux.

L’erreur inverse consiste à rejeter tout le conteneur au premier identifiant inconnu. Le RFC ne commande pas ce comportement général. Il décrit un modèle où la partie comprise continue. Un rejet total peut être légitime pour un produit précis, mais sa source est la politique locale, pas le simple nom du type de média.

codecs et OggS sont des indices bornés

Le paramètre codecs est facultatif. Son absence n’annonce pas un conteneur sans codec; elle signifie que cette déclaration n’a pas été placée dans le type de média. Les identifiants réels restent dans les premières pages des flux logiques. Sa présence ne prouve pas non plus que le destinataire possède, active ou exécute correctement les décodeurs annoncés.

Les quatre octets OggS sont communs aux trois types. Ils indiquent la famille du conteneur, pas le choix entre application, vidéo et audio. Ils ne fournissent ni inventaire, ni intégrité, ni authenticité, ni résultat de lecture. De même, .ogg, .oga, .ogv ou .ogx reste un indice de compatibilité. Changer le suffixe ne change aucun flux.

Ogg n’apporte enfin ni signature ni chiffrement générique. Il peut transporter des données protégées ou être protégé extérieurement. Il peut aussi contenir du code ou demander des ressources excessives. La familiarité du conteneur ne vaut donc ni confiance dans l’origine ni autorisation d’exécution.

Sources et limite des preuves

Ces sources établissent le texte normatif, les enregistrements et leur évolution. Elles ne prouvent aucun fichier, serveur, lecteur, incident, taux de déploiement ou résultat actuel.