128,4 i/smédiane · direct · 16 min 04
11,31 Mbit/sAV1 1440p · médiane
11 msRTT médian · session AV1
20,2 msdécodage RG557 · médiane
Sessions représentatives
Médiane et P95 sont publiés ensemble quand ils sont disponibles. Une session trop courte ou incomplète est signalée.
| Date et chemin | Configuration | Résultat mesuré | Lecture honnête |
|---|---|---|---|
| 08/07 · AV1 direct | 2560×1440 · AMD → Chrome | 11,31 Mbit/s médiane · P95 14,74 · 60,1 i/s · RTT 11/18 ms · decode 0,9 ms | Bon chemin AV1 sur cette paire uniquement ; pas une preuve tous navigateurs. |
| 11/08 · HEVC direct | 1920×804 · 16 min 04 | 6,59 Mbit/s médiane · P95 7,84 · 128,4 i/s médiane · P95 140 · RTT 25/32 ms | Plus de 120 i/s prouvés sur cette session ; 144 i/s verrouillés non prouvés. |
| 11/08 · HEVC direct cible 8M | 1920×804 · 12 min 54 | 7,46 Mbit/s médiane · 60 i/s · RTT 25/35 ms · 5 gels / 4,539 s | Session longue exploitable, mais pertes et gels mesurés. |
| 28/07 · Android RG557 | 1920×1080 · HEVC | 5,10 Mbit/s médiane · 31,5 i/s · RTT 39,5/48 ms · decode 20,2 ms | Le décodeur et le tampon de ce petit appareil sont le facteur limitant. |
| 12/08 · Windows natif local | H.264 puis HEVC · 5 s chacun | 14,18 puis 11,46 Mbit/s · 50,9 puis 61,9 i/s · decode P95 0,05/0,34 ms | Preuve locale très courte ; WAN et distribution signée non validés. |
| 12/08 · HEVC direct | 1920×1080 · 26 min | 3,17 Mbit/s médiane · 59,9 i/s · RTT 12/20 ms · decode 1,5/2,1 ms · 27 gels / 6,975 s | Débit et décodage stables, mais gels et audio discontinu mesurés. |
| 11/08 · relais / arrière-plan | 92 min | 1,37 Mbit/s médiane · RTT 25,5 ms · tampon P95 478 · 471 gels / 403,576 s | Incident long : ce scénario ne représente pas une qualité acceptable. |
| 05/08 · Apple TV 4K | 4K60 · tvOS · ~60 s | 49 gels / 15,741 s · decode 11–15 ms · audio et ICE actifs | Incident de capture/encodage hôte ; preuve qu’une résolution seule ne suffit pas. |
Comment les résultats sont lus
- Identifier la sessionDate, durée, client, résolution, codec et chemin direct ou relais sont conservés avec le relevé.
- Lire la distributionLa médiane décrit le centre de la session ; le P95 révèle les pointes que masque une simple moyenne.
- Séparer les étagesFréquence d’images, RTT, décodage, tampon, pertes et gels ne mesurent pas la même chose.
- Publier la réserveUne session courte, locale, sans audio ou perturbée garde explicitement cette limite.
Ce que ces compteurs ne prouvent pas
- Le RTT WebRTC n’est pas la latence verre-à-verre.
- NAL → affichage ou décodage client ne couvre pas la capture, l’encodage et l’écran physique complet.
- Un pic de fréquence d’images n’équivaut pas à une cadence verrouillée pendant toute la session.
- Une session sur un GPU, un téléphone ou un réseau ne s’extrapole pas à toute la gamme.
Mesure verre-à-verre encore à produire
La preuve correcte exige une caméra externe à haute fréquence filmant simultanément l’action sur l’hôte et son affichage client. Tant que ce protocole n’est pas réalisé, Lume ne publie pas de chiffre verre-à-verre.
Suivre les nouvelles validations
Le journal et la roadmap publient les corrections, les expériences et ce qui reste ouvert.