Il y a quelque chose qui coince chez toi, alors, puisque j'obtiens bien le résultat attendu : à CRF équivalent mais preset changeant, la taille diminue suivant l'augmentation de la complexité du preset.

Cela s'explique peut-être par ma version de SVT-AV1, la version 2.3.0 ?

Oui, je sais. Ce n'est pas si simple sous Linux sans devoir recompiler pleins de trucs. J'ai compilé la dernière version d SVT-AV, mais j'ai eu plus de mal pour ffmpeg et toutes ses dépendances. C'est une veille version car la compilation de svt-av1 échoue sur i386 en raison de l'absence de libcpuinfo-dev (nouvelle dépendance ajoutée dans la version 3.0.2+dfsg-1) sur i386.

Dans ton dernier test, on voit que la variation de la taille n'est pas tout à fait logique (vidéo preset 10 plus petite que preset 6 et 8 ).

Si tu as un peu de temps CPU, tu pourrais faire tourner mon script et afficher la taille des fichiers ? (ce sera donc strictement la même ligne de commande que moi)
Vidéo source : https://lafibre.info/videos/loi/202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs.mkv

Taille de mon côté : le numéro à la fin du fichier est le preset, qui varie de -1 à 13 :
44618624 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs.mkv
14110360 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs-1.mp4
14110653 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs0.mp4
14162832 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs1.mp4
14161718 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs2.mp4
14333407 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs3.mp4
14286806 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs4.mp4
14379078 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs5.mp4
14113725 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs6.mp4
13839929 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs7.mp4
14264847 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs8.mp4
14315064 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs9.mp4
13424865 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs10.mp4
13186735 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs11.mp4
13186735 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs12.mp4
13186735 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs13.mp4

Oui, le preset 10 doit être tellement extrême en terme de compromis qu'il en finit par casser certains raisonnements concernant le calcul simultané de la qualité ?

J'ai converti ton script en Powershell & utilisé la dernière nightly ffmpeg disponible pour Windows, qui contient SVT-AV1 4.0.1. J'ai exclu les presets 11/12/13 (qui ne sont prévus que pour les appels vidéo) et le preset -1 (rapidité)

Preset	Taille du fichier (Mo)	Vitesse d'encodage (i/s)	Débit vidéo (Kb/s)
0	14,74	3,19	941,36
1	14,81	8,64	945,56
2	14,83	18,09	947,43
3	14,24	31,71	906,78
4	14,20	53,32	903,69
5	14,16	77,61	901,43
6	14,26	107,92	907,89
7	14,95	145,59	955,30
8	15,60	215,42	1000,35
9	14,23	298,90	905,86
10	13,07	331,70	826,32

Je pense que ce comportement atypique pourrait s'expliquer par le fait que la source est déjà pas mal compressée et que les deux paliers visible dans la courbe rouge s'expliquent par l'activation/désactivation de certaines fonctionnalités de l'encodeur qui interagissent d'une certaine manière lorsque la source est déjà très compressée

Pour ce qui est de ta comparaison des 2 presets... ça a toujours été le cas avec toute sorte de comparaison d'encodage vidéo, mais ça l'est encore plus aujourd'hui : deux images fixes ne donnent pas assez d'info. C'est aussi la précision de la reconstitution du mouvement qui est primordiale et qui a une très grande importance psychovisuelle.

Je me suis permis de mettre tes différentes images en une seule animée, c'est plus facile pour comparer.

On voit bien la partie ou cela bouge beaucoup à la fin de la vidéo. Je suis étonné que le débit descende compéltement à zéro au milieu de la vidéo (ce sont des images fixes).
Pour le bug du temps, c'est peut-être lié au fait que ton outil pense que la vidéo a 30 images/ seconde alors que c'est 25.

Avec quel outil tu arrives à faire ça ? cela m'intéresse vraiment pour analyser des flux, en voir ceux qui sont en CBR (le flux source était en CBR par exemple, encodé par Arte à 3000 Kbit/s). Les variations de débits ne peuvent se faire qu'entre deux périodes très proches. Je suis curieux de voir ce que cela donne sur le fichier source.

La vidéo en question : (CRF45 et Preset -1 )