Ben honnêtement, pour avoir une connexion Free à la maison et Orange au bureau (toutes les deux en fibre), je ne vois aucune différence.
Que ce soit pour le loisir (gaming) et pour le taff (nombreux téléchargements et uploads vers différentes destinations).

merci pour ton retour, en te lisant, ça m'a fait creuser un peu plus et j'ai opté pour l'utilisation de tc à la place de nftables pour set les priorités.

de la sorte, je set en prio6 uniquement ce qu'il faut et dans la conf egress-qa-map de l'interface on a qqc de logique. Ca supprime la règle nftables par defaut en priorité 1 qui est ensuite remappé en COS0. De plus ça permet d'être explicite sur la règle ARP.

mon fichier /etc/config/tc-cos6.sh
#!/bin/sh

DEVICE="${1}"

# Configure a PRIO qdisc on a VLAN interface.
tc qdisc replace dev "${DEVICE}" root handle 1: prio
tc filter del dev "${DEVICE}"

# ARP
tc filter add dev "${DEVICE}" parent 1: prio 1 protocol 0x806 u32 \
  match u32 0 0 \
  action skbedit priority 0:6

# DHCPv4
tc filter add dev "${DEVICE}" parent 1: prio 2 u32 \
  match ip ihl 5 0xf \
  match u16 0x0000 0x1fff at 6 \
  match ip protocol 17 0xff \
  match ip sport 68 0xffff \
  match ip dport 67 0xffff \
  action skbedit priority 0:6 pipe \
  action pedit munge ip tos set 0xc0 retain 0xfc pipe \
  action csum ip4h
 
# DHCPv6
tc filter add dev "${DEVICE}" parent 1: prio 3 protocol ipv6 u32 \
  match ip6 dst fe00::/7 \
  match ip6 protocol 17 0xff \
  match ip6 sport 546 0xffff \
  match ip6 dport 547 0xffff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

# ICMPv6 Router Solicitation (133) to multicast (ff02::/16)
tc filter add dev "${DEVICE}" parent 1: prio 4 protocol ipv6 u32 \
  match ip6 dst ff02::/16 \
  match ip6 protocol 58 0xff \
  match ip6 icmp_type 133 0xff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

# ICMPv6 Neighbor Solicitation (135) to orange dhcp server (fe80::ba0:bab/128)
tc filter add dev "${DEVICE}" parent 1: prio 5 protocol ipv6 u32 \
  match ip6 dst fe80::ba0:bab/128 \
  match ip6 protocol 58 0xff \
  match ip6 icmp_type 135 0xff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

# ICMPv6 Neighbor Advertisement (136) to orange dhcp server (fe80::ba0:bab/128)
tc filter add dev "${DEVICE}" parent 1: prio 6 protocol ipv6 u32 \
  match ip6 dst fe80::ba0:bab/128 \
  match ip6 protocol 58 0xff \
  match ip6 icmp_type 136 0xff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

comme ça plus de règle nftables spécifiques et on simplifie la conf de l'interface:
config device
option name 'eth0.832'
option type '8021q'
option ifname 'eth0'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '6:6'
option macaddr 'xx:xx:xx:xx:xx:xx'


Une image valant mieux qu'un long discourt, regardez le très mauvais niveau de la bande 6 Ghz
Relevé fait ce matin avec un xiaomi 12
Je rappelle que 3 Db de moins, c'est deux fois moins de puissance.

Autrement la 4K passe très bien jusqu'à la version pour les pauvres de l'affaire, les Red, du moins tant qu'Optix ne vient pas s'en mêler 

Si ton opérateur savait respecter un contrat, j'aurais pas besoin de m'en méler.

...
Il me semble qu'aujourd'hui parler 1080p ou 720p est suffisamment compris du grand public pour que cela puisse être utilisé. Surtout face au terme "HD" qui est flou sur la définition réelle.
Cette définition pourrait être intégrée dans ton ableau sur https://tvradiozap.eu (une colonne de plus). Le débit max proposé pourrait aussi être rajouté.

Pour être franc, je me demande ce qui est compris aujourd'hui du "grand public"  . Ca ne tiendrait qu'à moi, je parlerais aussi en 1080p plutôt que full HD. Mme Michu serait sûrement incapable de dire ce qu'est du 1080p ou la différence entre HD et full HD mais ces 2 dernières appellations me semblaient quand même plus "grand public". J'ai donc pris les références qu'on voit partout, par ex ici :
https://fr.strong-eu.com/fr/blog/quelle-est-la-difference-entre-hd-fhd-uhd-et-4k/

Le problème de les afficher, outre la question d'une colonne de plus alors que le tableau est déjà chargé, c'est qu'il faut visualiser une chaîne un certain temps pour l'obtenir du lecteur HLS, d'où le choix de ne l'afficher qu'avec la chaîne qu'on regarde sinon on n'a pas l'info (et si on la mémorise dans la base de données, la gestion devient trop lourde).

Je serais intéressé pour les statistiques de connaitre le codec (c'est probablement plus de 90% pour H.264 / AVC) et savoir si le débit est fixe (ex ! encodage à 4 Mb/s) ou si le débit est variable (ce qui permet de ne pas gâcher des octets quand la scène est facile à encoder).

Hors youtube, dailymotion et twitch pour lesquels on n'a pas l'info (sauf outils en ligne pour l'obtenir) :
Pour l'audio, c'est majoritairement "mp4a.40.2", parfois "mp4a.40.5", et des cas avec "aac-lc-9600" ou "audio-aacl-69" ou 128
Pour la vidéo, c'est toujours "avc1." suivi d'une codification à 6 chiffres, majoritairement 6400xx, souvent aussi 4D40xx, 42xxyy, parfois 4D00xx.
Difficile de faire des stats, il faudrait faire un scan des chaînes en notant à chaque fois l'info, disponible souvent seulement 10 à 30s après le début de la visualisation (pourquoi un tel délai alors que le codec est indiqué dans le m3u8 de départ, je ne sais pas).

Je n'ai jamais vu une chaîne avec débit vraiment variable. Il y a bien des variations sur certaines chaînes mais dans de très faibles proportions (quelques %, donc peut-être simplement liées aux incertitudes du calcul).