Re: Problème de lecture vidéo (trop rapide)
didier gaumet a écrit :
>
> Je n'ai vraiment pas grande idée de ce qui peut causer ces problèmes
> mais en plus des bons conseils de Frédéric, peut-être:
>
> - prendre connaissance du changement de pilote par défaut VA-API des
> GPU Intel avec le passage à Bullseye (modifier la variable mentionnée
> permettra peut-être de voir ce qui se passe)
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.fr.html#new-vaapi-default-driver
>
> - vérifier que les paquets intel-microcode, firmware-linux, firmware-
> misc-nonfree sont installés: ils ne sont peut-être pas nécessaires mais
> pourraient être utiles
>
> - vérifier que les paquets va-api nécessaires sont installés et que les
> logiciels sont configurés pour utiliser va-api plutôt que vdpau ou
> autre (en automatique, normalement ça devrait être bon)
>
> - vérifier que le noyau et les modules ne sont pas chargés avec des
> options spécifiques ou que ces options spécifiques n'interfèrent pas
> avec le décodage vidéo
>
> - vérifier que l'ordonnanceur (scheduler) du noyau est celui par défaut
> ou que l'ordonanceur choisi n'interfère pas avec le décodage vidéo
> (j'émets là une supposition, je ne sais même pas dans le détail comment
> changer cet ordonnanceur, mais comme Joël descend plus profondément que
> moi dans la technique...)
>
> - pour éventuellement (je n'ai jamais utilisé) avoir plus d'infos sur
> ce qui se passe, installer le paquet intel-gpu-tools, vérifier si des
> outils permettent un diagnostic et les utiliser
>
> Voilà, tout ça est assez théorico-conditionnel, désolé :-)
Je vais regarder tout ça, merci.
\begin{mode déprime}
Plus loin sur la page
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.fr.html,
je lis que usrmerge sera bientôt obligatoire. Mais quand est-ce que ça
s'arrêtera de déconner ? Après systemd qui est un bloatware à problème
(des tas de choses merdoient joyeusement dès qu'on n'est plus dans une
configuration standard et se soldent par des verrues dans /etc/systemd,
ce serait acceptable si systemd n'était pas capable de mettre en vrac
une machine l'empêchant de booter jusqu'au bout !), on va se taper
obligatoirement usrmerge ? Mince, il n'y a pas que le poste de travail,
il y a aussi l'embarqué pour lequel on est contraint de partitionner aux
petits oignons (surtout lorsqu'on utilise des mémoires de type NAND). Il
y a aussi toutes les configurations à client lourds, diskless où systemd
se vautre lamentablement dans la configuration par défaut.
Ce que je reproche à systemd, c'est le fait d'être une usine à gaz avec
des fuites et des effets de bords rigolos (ou pas) empêchant par exemple
dans certaines configurations le démarrage del'un ou l'autre des daemons
(j'ai des exemples avec le daemon NFS, des bases de données, je n'ose
même pas parler des passades de franche rigolade avec des disques de
swap iSCSI)... Ou pire, empêchant le redémarrage d'un système sur un
noyau un peu ancien lors d'une mise à jour foirée parce qu'il dépend
beaucoup (trop) du noyau. Quant à usrmerge, c'est une mauvaise réponse à
une bonne question. Un Unix devrait pouvoir démarrer avec un / en ro (et
qui le reste), ne serait-ce que pour récupérer un système minimal
utilisable pour remettre d'équerre /usr, même à distance. Là, on va être
obligé de bidouiller un ramdisk pour monter au démarrage /usr, embarquer
une copie des modules nécessaires dans ledit ramdisk et la configuration
du bidule... Et si /usr est corrompu ? Mélanger / et /usr est la pire
chose qui puisse exister. Ou alors, il faut aller au bout de la démarche
et tout coller dans le même répertoire : /bin, /sbin, /usr/bin,
/usr/sbin, /usr/local/bin, /usr/local/sbin et toutes les bibliothèques
(pour qu'on sache exactement où elles se trouvent histoire de simplifier
la vie du chargeur dynamique).
Je vais aller prendre un Lexomil tant ce monde me déprime.
\end{mode déprime]
Bien cordialement,
JKB
Reply to: