Mon blog

Ce court RFC expose les exigences portant sur les codecs vidéo de WebRTC. Le point principal était le choix du codec obligatoire. Après une très longue et très amère discussion à l'IETF, le choix a été plus politicien que technique : le codec H.264 est obligatoire au même titre que VP8.

Le système WebRTC (voir le RFC 7478) permet de faire de la vidéoconférence, notamment entre deux navigateurs Web. Il permet aux parties qui communiquent de choisir le codec. Un point important des protocoles IETF est que, lorsqu'il existe un tel choix, au moins un des choix doit être mis en œuvre dans toutes les implémentations. Le but est d'assurer l'interopérabilité, en vérifiant que les programmes ont tous au moins un codec en commun.

Mais quel codec choisir ? Il y avait deux concurrents, un codec de l'UIT, H.264 (normalisé ici), qui avait la faveur des compagnies de télécommunication traditionnelles, et un codec issu de l'Internet, VP8 (RFC 6386), qui était le plus apprécié par les entreprises Internet et par le monde du logiciel libre. Le débat a été très long et très houleux à l'IETF. Le problème n'était pas uniquement sentimental, il portait également sur les innombrables brevets qui verrouillent H.264 (son concurrent VP8 a aussi des brevets, mais avec une licence très libérale pour la plupart). Quant aux critiques sur VP8, elles portaient surtout sur sa relative jeunesse (en fait, certaines entreprises avaient investi pas mal dans H.264 et ne voulaient pas recommencer).

Le débat a donc duré, générant plus de mille messages sur la liste de diffusion du groupe de travail, et occupant une bonne partie des réunions physiques de l'IETF (réunions IETF 81, 82, 85, 86, et 88...), affectant notablement la patience des participants. Des tas de solutions ont été proposées pour sortir de l'affrontement, y compris un inhabituel vote (dans ce message, MTI = Mandatory To Implement). Le sujet est revenu sur le tapis et revenu encore. La solution, adoptée à la réunion IETF 91 à Honolulu, a finalement été de prendre les deux.

Notez bien que ce RFC n'est pas la description complète de WebRTC, loin de là. C'est juste le cahier des charges minimum des codecs (le cahier des charges du transport des données a été publié dans le RFC 8834).

D'abord, les considérations générales, indépendantes du codec (section 3). Par exemple, l'espace de couleur à utiliser est sRGB. Cette section conseille également sur l'utilisation de la caméra de capture : si elle le permet, il est recommandé d'utiliser ses capacités propres, comme la mise au point automatique, ou le réglage automatique de la luminosité. Le RFC rappelle également que la résolution de la source peut changer en cours de route (parce que la source est une fenêtre de l'écran qui change soudain de taille, ou bien parce que la source est la caméra d'un mobile qui change soudain d'orientation, cf. section 4) et que WebRTC doit donc s'y adapter.

La section 5 est le morceau sensible du RFC : la description du, ou plutôt des, codecs obligatoires. Le principe est que toute mise en œuvre de WebRTC doit accepter VP8 et H.264. Une note du RFC précise que, si le problème des brevets s'arrange pour un des codecs et pas pour l'autre, cette décision pourra être reconsidérée et un des codecs devenir optionnel (évidemment, tout le monde pense à H.264, beaucoup plus lardé de brevets avec licences hostiles). À noter que des codecs comme Theora ont été discutés, et sont possibles dans WebRTC, mais sans qu'il ait vraiment été envisagé de les rendre obligatoires.

La section 6 précise ensuite quelques exigences techniques pour chacun des codecs. Notamment, plusieurs options de H.264 ont une valeur fixe en WebRTC, pour simplifier la tâche des programmeurs. (H.264 a bien trop de variables possibles.)