···1043104310441044L'encodage vidéo étant fait par une bibliothèque totalement séparée de celle s'occupant de la rastérisation SVG, il y a un risque d'incompatibilité entre les formats de pixmap utilisés par les deux bibliothèques, ce qui est le cas ici.
1045104510461046-En effet, les SVG rasterisés sont stockées dans un array plat de valeurs RGBA:
10461046+En effet, les SVG rasterisés sont stockées dans un array plat de valeurs RGBA @pixmapvecu8:
1047104710481048#align(center)[
10491049 ```
···10511051 ```
10521052]
1053105310541054-Tandis que la bibliothèque utilisée, _rsvideo_, attend une matrice HWC, ou height-width-channels, de pixels:
10541054+Tandis que la bibliothèque utilisée, _video-rs_, attend une matrice HWC, ou height-width-channels, de pixels RGB @videorshwc, @videorshcwframe, @array3rust:
1055105510561056#align(center)[
10571057 ```
···1065106510661066Il est donc nécéssaire de convertir entre ces deux formats, ce qui est lent car demande de copier les données.
1067106710681068-Une autre solution est de faire proposer une contribution à la bibiothèque de rendu utilisée par _resvg_, _tiny_skia_, pour pouvoir instrumentaliser les lectures et écritures à sa pixmap, et ainsi écrire dans la représentation voulue par libx264 directement.
10681068+Une solution serait de passer à une bibiothèque plus bas niveau et voir s'il est possible de donner directement les données de pixmap à l'encodeur, sans conversion, ou tout du moins sans avoir à copier les données.
10691069+10701070+Une autre solution est de faire proposer une contribution à la bibiothèque de rendu utilisée par _resvg_, _tiny_skia_#footnote[Tiny-skia est notamment utilisé par Typst @typsttinyskia @typsttinyskiacargotoml, l'alternative moderne à LaTeX sur laquelle ce papier a été typeset], pour pouvoir instrumentaliser les lectures et écritures à sa pixmap, et ainsi écrire dans la représentation voulue par libx264 directement.
1069107110701072== SVG vers string vers SVG <perf-svgstring>
10711073