[resolu] Re: Problème de lecture vidéo (trop rapide)
Résolu. Visiblement, un vieux bug qui dépend à la fois du CPU et de l'écosystème et qui n'affecte pas tous les haswell. Le noyau 4.19 était touché comme les noyaux les plus récents, mais il ne se produisait pas chez moi avec le 4.19. Le fichier de conf de PXE est maintenant : LABEL linux KERNEL pxelinux.cfg/vmlinuz-5.15.0-2-amd64-heisenberg APPEND root=/dev/nfs initrd=pxelinux.cfg/initrd.img-5.15.0-2-amd64-heisenberg nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp rw splash intel_iommu=on,igfx_off PROMPT 0 DEFAULT linux Notez bien intel_iommu=on,igfx_off à la fin de la ligne APPEND. JKB
Re: Problème de lecture vidéo (trop rapide)
didier gaumet a écrit : > > > Le jeudi 20 janvier 2022 à 21:36 +0100, BERTRAND Joël a écrit : >>> Bon, je vais commencer par virer l'intrus que je n'ai >>> jamais installé à >>> la main. Je serais assez curieux de voir par quel dépendance >>> miraculeuse >>> il est arrivé jusque là... >> >> Mauvaise pioche. >> >> Le résultat est toujours le même. En plein écran, plus aucun >> son. Mais >> si je bascule la sortie sur l'interface casque, analogique, toute >> bête, >> ça fonctionne. Le problème est donc plus autour du pilote HDMI que du >> son lui-même. > > - tu peux éventuellement envisager la piste du mauvauis contact dans le > câble HDMI (essayer un autre câble si tu en as un), verifier les specs > HDMI des 2 ports (PC et l'appareil à l'autre bout, et tester d'autres > prises HDMI si tu en as plusieurs sur le PC ou l'appareil) Je n'y crois pas, c'est beaucoup trop reproductible. Ça fonctionne, je passe n plein écran, ça ne fonctionne plus. Le câble n'a aucune raison de se synchroniser sur mes actions. > - en ligne de commande tu peux exécuter pa-info (pas en root, en simple > utilisateur), qui va donner pas mal d'infos sur le fonctionnement et la > configuration de Pulseaudio et alsa sur ton système Là non plus, pulseaudio n'est pas en cause, c'est après pulseaudio que ça merdoie. Pulseaudio envoie des trames à la sortie matérielle qui gère la chose n'importe comment. JKB
Re: Problème de lecture vidéo (trop rapide)
Le jeudi 20 janvier 2022 à 21:36 +0100, BERTRAND Joël a écrit : > > Bon, je vais commencer par virer l'intrus que je n'ai > > jamais installé à > > la main. Je serais assez curieux de voir par quel dépendance > > miraculeuse > > il est arrivé jusque là... > > Mauvaise pioche. > > Le résultat est toujours le même. En plein écran, plus aucun > son. Mais > si je bascule la sortie sur l'interface casque, analogique, toute > bête, > ça fonctionne. Le problème est donc plus autour du pilote HDMI que du > son lui-même. - tu peux éventuellement envisager la piste du mauvauis contact dans le câble HDMI (essayer un autre câble si tu en as un), verifier les specs HDMI des 2 ports (PC et l'appareil à l'autre bout, et tester d'autres prises HDMI si tu en as plusieurs sur le PC ou l'appareil) - en ligne de commande tu peux exécuter pa-info (pas en root, en simple utilisateur), qui va donner pas mal d'infos sur le fonctionnement et la configuration de Pulseaudio et alsa sur ton système
Re: Problème de lecture vidéo (trop rapide)
BERTRAND Joël a écrit : > Bon, je vais commencer par virer l'intrus que je n'ai jamais installé à > la main. Je serais assez curieux de voir par quel dépendance miraculeuse > il est arrivé jusque là... Mauvaise pioche. Le résultat est toujours le même. En plein écran, plus aucun son. Mais si je bascule la sortie sur l'interface casque, analogique, toute bête, ça fonctionne. Le problème est donc plus autour du pilote HDMI que du son lui-même. JKB
Re: Problème de lecture vidéo (trop rapide)
didier gaumet a écrit : > > > Le jeudi 20 janvier 2022 à 19:39 +0100, BERTRAND Joël a écrit : > > [...] >> Jan 20 19:37:26 heisenberg systemd[2719]: PipeWire Multimedia System >> Socket was skipped because of a failed condition check >> (ConditionUser=!root). > [...] >> Jan 20 19:37:26 heisenberg systemd[2719]: >> pipewire-media-session.service: Bound to unit pipewire.service, but >> unit >> isn't active. >> Jan 20 19:37:26 heisenberg systemd[2719]: Dependency failed for >> PipeWire >> Media Session Manager. >> Jan 20 19:37:26 heisenberg systemd[2719]: >> pipewire-media-session.service: Job pipewire-media- >> session.service/start >> failed with result 'dependency'. >> Jan 20 19:37:26 heisenberg systemd[2719]: Sound Service was skipped >> because of a failed condition check (ConditionUser=!root). > > Il semblerait (conditionnel) que ton système veuille utiliser Pipewire > en tant que service Systemd restreint à la session utilisateur mais que > ce système ne puisse être démarré parce que lancé avec le user root > (démarrage d'un service Systemd global système?) > > Sous Bullseye, je ne savais même pas que le service Pipewire est > démarré par défaut: j'ai laissé la config standard qui installe des > bibliothèques et exécutables mais ne remplace pas le serveur > Pulseaudio. > > didier@hp-notebook14:~$ systemctl --user | grep -i pipe > pipewire.service > loaded active running Multimedia Service > pipewire.socket > loaded active running Multimedia System > didier@hp-notebook14:~$ systemctl --user | grep -i pulse > pulseaudio.service > loaded active running Sound Service > pulseaudio.socket > loaded active running Sound System > > Je ne connais pas bien Pipewire mais en gros il me semble comprendre > que c'est à la fois un framework audio-vidéo avec des bibliothèques et > des utilitaires (créé au départ, entre autres, pour que des > applications en bac-à-sable puissent jouer du son facilement), mais > aussi potentiellement un serveur audio-vidéo, susceptible de remplacer > Pulseaudio. > > Donc en gros, là, je pense que tu peux regarder les pages Pipewire du > wiki Debian, éventuellement du wiki Archlinux et la doc de Pipewire, > pour cerner si tu veux utiliser Pipewire, quels sont les différents cas > d'usage et comment paramétre tout ça: > https://wiki.debian.org/PipeWire > https://wiki.archlinux.org/title/PipeWire > https://pipewire.org/ Bon, je vais commencer par virer l'intrus que je n'ai jamais installé à la main. Je serais assez curieux de voir par quel dépendance miraculeuse il est arrivé jusque là... En tout cas, bien vu, merci. JKB
Re: Problème de lecture vidéo (trop rapide)
Le jeudi 20 janvier 2022 à 19:39 +0100, BERTRAND Joël a écrit : [...] > Jan 20 19:37:26 heisenberg systemd[2719]: PipeWire Multimedia System > Socket was skipped because of a failed condition check > (ConditionUser=!root). [...] > Jan 20 19:37:26 heisenberg systemd[2719]: > pipewire-media-session.service: Bound to unit pipewire.service, but > unit > isn't active. > Jan 20 19:37:26 heisenberg systemd[2719]: Dependency failed for > PipeWire > Media Session Manager. > Jan 20 19:37:26 heisenberg systemd[2719]: > pipewire-media-session.service: Job pipewire-media- > session.service/start > failed with result 'dependency'. > Jan 20 19:37:26 heisenberg systemd[2719]: Sound Service was skipped > because of a failed condition check (ConditionUser=!root). Il semblerait (conditionnel) que ton système veuille utiliser Pipewire en tant que service Systemd restreint à la session utilisateur mais que ce système ne puisse être démarré parce que lancé avec le user root (démarrage d'un service Systemd global système?) Sous Bullseye, je ne savais même pas que le service Pipewire est démarré par défaut: j'ai laissé la config standard qui installe des bibliothèques et exécutables mais ne remplace pas le serveur Pulseaudio. didier@hp-notebook14:~$ systemctl --user | grep -i pipe pipewire.service loaded active running Multimedia Service pipewire.socket loaded active running Multimedia System didier@hp-notebook14:~$ systemctl --user | grep -i pulse pulseaudio.service loaded active running Sound Service pulseaudio.socket loaded active running Sound System Je ne connais pas bien Pipewire mais en gros il me semble comprendre que c'est à la fois un framework audio-vidéo avec des bibliothèques et des utilitaires (créé au départ, entre autres, pour que des applications en bac-à-sable puissent jouer du son facilement), mais aussi potentiellement un serveur audio-vidéo, susceptible de remplacer Pulseaudio. Donc en gros, là, je pense que tu peux regarder les pages Pipewire du wiki Debian, éventuellement du wiki Archlinux et la doc de Pipewire, pour cerner si tu veux utiliser Pipewire, quels sont les différents cas d'usage et comment paramétre tout ça: https://wiki.debian.org/PipeWire https://wiki.archlinux.org/title/PipeWire https://pipewire.org/
Re: Problème de lecture vidéo (trop rapide)
Bon, autres tests. Je démarre la machine, je me connecte à kde, je peux tester les voies gauche et droite. Le son fonctionne. Je lance vlc, j'arrive à lire une vidéo. Je mets vlc en plein écran, plus de son. Je passe en mode fenêtré, plus de son non plus. Je test alors les voies gauche et droite, plus rien n'est envoyé (et pavucontrol m'indique que les données envoyées sont de toute façon trop courtes). Je sors de vlc, je teste le son. Rien. Au bout de quelques dizaines de secondes, ça revient !? Je refais la manipulation plusieurs fois, ça ne rate pas, le résulat est toujours le même. Lorsqu'il n'y a plus de son, pulseaudio est toujours actif. Le relancer par un pulseaudio -k ne sert à rien. Je vais donc regarder les logs de plus près et j'ai les messages d'erreur suivant sui ne me parlent pas : Jan 20 19:37:26 heisenberg systemd[2719]: PipeWire Multimedia System Socket was skipped because of a failed condition check (ConditionUser=!root). Jan 20 19:37:26 heisenberg systemd[2719]: Listening on debconf communication socket. Jan 20 19:37:26 heisenberg systemd[2719]: Sound System was skipped because of a failed condition check (ConditionUser=!root). Jan 20 19:37:26 heisenberg systemd[2719]: Listening on D-Bus User Message Bus Socket. Jan 20 19:37:26 heisenberg systemd[2719]: Reached target Sockets. Jan 20 19:37:26 heisenberg systemd[2719]: Reached target Basic System. Jan 20 19:37:26 heisenberg systemd[2719]: PipeWire Multimedia Service was skipped because of a failed condition check (ConditionUser=!root). Jan 20 19:37:26 heisenberg systemd[2719]: pipewire-media-session.service: Bound to unit pipewire.service, but unit isn't active. Jan 20 19:37:26 heisenberg systemd[2719]: Dependency failed for PipeWire Media Session Manager. Jan 20 19:37:26 heisenberg systemd[2719]: pipewire-media-session.service: Job pipewire-media-session.service/start failed with result 'dependency'. Jan 20 19:37:26 heisenberg systemd[2719]: Sound Service was skipped because of a failed condition check (ConditionUser=!root). JKB
Re: Problème de lecture vidéo (trop rapide)
didier gaumet a écrit : > > > Je t'aurais bien dit que ta 1ère config est nettement plus musclée que > la 2ème, mais vu que la charge est très faible Oui, enfin, de la video FullHD, ça tient sur un rPI 1... Avec ce type de machine, je tiens normalement deux écrans FullHD (c'était ce genre de configuration que je mettais dans les écrans numériques qu'on vendait). > un peu au hasard, regarde là, des problèmes relatifs à la lecture vidéo > de partages NFSv3 dans certains environnements et pas d'autres: > https://bugzilla.kernel.org/show_bug.cgi?id=211471 Ça m'étonnerait que ce soit cela. Sur la "grosse" machine, dans la même configuration (diskless), ça fonctionne parfaitement. > Une question me vient, NFSv4 semble déjà très mature, alors pourquoi > rester en v3? (tu as peut-être d'excellentes raisons de rester en v3 > mais c'est peut-être que tu n'as jamais fait le saut à v4, par > habitude?) C'est surtout que j'ai la flemme de coder le support NFSv4 dans NetBSD ;-) https://wiki.netbsd.org/projects/project/nfsv4/ > et le paramétrage (vieille doc mais bon) de NFS au niveau des timers, > tailles de blocs et de paquets, retransmissions, etc... > http://nfs.sourceforge.net/nfs-howto/ar01s05.html Côté serveur, rien n'a changé. Les paramètres nfs sont les mêmes sur tous les clients. Je ne vois pas pourquoi seul ce client aurait un problème. Le noyau est exactement le même sur l'i9 et l'i5 (seule différence notable, le son sur l'i9 ne sort par par la liaison HDMI et, naturellement, la carte graphique qui est une carte de compétition car c'est un poste de CAO). Il n'y a pas de problème réseau, il n'est jamais saturé. Le serveur sort sur un switch qui fait de l'agrégation et les clients sont connectés de la même manière. Il n'y a pas de problème de câblage non plus. > Enfin bref tout ça et moi ça fait 2, désolé, mais je suis sûr que de > beaucoup plus au fait que moi vont se manifester :-) J'espère ;-) JKB
Re: Problème de lecture vidéo (trop rapide)
Je t'aurais bien dit que ta 1ère config est nettement plus musclée que la 2ème, mais vu que la charge est très faible un peu au hasard, regarde là, des problèmes relatifs à la lecture vidéo de partages NFSv3 dans certains environnements et pas d'autres: https://bugzilla.kernel.org/show_bug.cgi?id=211471 Une question me vient, NFSv4 semble déjà très mature, alors pourquoi rester en v3? (tu as peut-être d'excellentes raisons de rester en v3 mais c'est peut-être que tu n'as jamais fait le saut à v4, par habitude?) et le paramétrage (vieille doc mais bon) de NFS au niveau des timers, tailles de blocs et de paquets, retransmissions, etc... http://nfs.sourceforge.net/nfs-howto/ar01s05.html Enfin bref tout ça et moi ça fait 2, désolé, mais je suis sûr que de beaucoup plus au fait que moi vont se manifester :-)
Re: Problème de lecture vidéo (trop rapide)
BERTRAND Joël a écrit : > En retirant l'option intr et en rajoutant nolock sur /home et > /opt/video, j'arrive à ouvrir KDE sans que cela ne plante. Mais il y a > toujours des problèmes de vidéo. De temps en temps, ça fonctionne, puis > ça se met à ne plus fonctionner. J'ai essayé à partir d'un compte avec > un VLC correctement paramétré et le résultat est le même que le décodage > soit fait par VAAPI ou en soft (libplacebo). Au bout d'un certain temps, > la sortie son fini par devenir inactive et il me faut redémarrer la > machine pour qu'elle fonctionne à nouveau. Je précise que la sortie son est la sortie HDMI. On retombe peut-être sur un bug du pilote video.
Re: Problème de lecture vidéo (trop rapide)
BERTRAND Joël a écrit : > Bonjour, > > Y a-t-il un problème sur la liste ? J'ai envoyé deux messages qui > n'apparaissent pas alors que j'en ai reçu plusieurs autres plus récents... > Comme celui-ci est passé, je reposte mes message. Désolé si les deux premiers passeront en double... Copie du message de ce matin : Bonjour à tous, J'avoue que le problème me dépasse et n'est visiblement pas restreint aux vidéos. Je pense même que les erreurs NFS proviennent de la même cause. J'ai actuellement deux machines en Debian/testing. Elles sont diskless toutes les deux et tournent toutes les deux en testing à jour. hilbert: - cpu : Intel(R) Core(TM) i9-10900F CPU @ 2.80GHz - carte graphique : VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) - fstab : 192.168.10.128:/srv/hilbert /nfs tcp,nfsvers=3,async 0 0 192.168.10.128:/home /home nfs tcp,nfsvers=3,async,nolock 0 0 192.168.10.128:/opt/video /opt/video nfstcp,nfsvers=3,async,nolock 0 0 heisenberg: - cpu : Intel(R) Core(TM) i5-4570 @ 2.90GHz - GPU intel - fstab 192.168.10.128:/srv/heisenberg / nfs intr,tcp,nfsvers=3,async 0 0 192.168.10.128:/home/home nfs intr,tcp,nfsvers=3,async 0 0 192.168.10.128:/opt/video /opt/video nfsintr,tcp,nfsvers=3,async 0 0 Hilbert fonctionne normalement (aucune erreur). Je constate qu'il y a une option intr qui traîne, mais celle-ci est ignorée si j'en crois la page man (ce qui prouve que l'OS a été installé avant le noyau 2.6.25...). Je vais retirer cette option. De la même façon, j'ai un nolock sur /home et /opt/video sur hilbert que je n'ai pas sur heisenberg. Cependant, avec le noyau 4.19, tout se passait correctement et si je vois bien le rapport entre les options NFS et les erreurs dans la console, je ne vois pas trop le rapport avec les timers. Il faut cependant noter qu'avec le noyau 4.19, tout se passait correctement (aucune erreur NFS, aucun problème pour lire des vidéos). J'ai bien essayé de redémarrer un 4.19, mais ce de systemd est tellement imbriqué avec le noyau qu'il refuse de fonctionner normalement et le démarrage d'un 4.19 échoue ! Je ne suis toutefois pas convaincu que le fait de retirer l'option nolock va résoudre le problème puisque /var/log/syslog montre que les erreurs NFS proviennent de / et non de /home (les erreurs sont tracées avant que /home ne soit montée). Je n' ai rien vu de particulier dans le dmesg de heisenberg. Le serveur NFS est un serveur NetBSD 9.2 (i7-4770, 16 Go, treize disques en grappes Raid1, Raid5, Raid6 et Ccd pour les swaps), largement dimensionné et le daemon NFS fonctionne avec 16 threads. J'ai essayé d'augmenter le nombre de threads, mais cela dégrade les performances (il vaut mieux qu'un client se prenne une erreur NFS de temps en temps plutôt que de faire monter la charge du serveur, j'ai fait des benchmarks sur le sujet). NFS est en V3/TCP (j'avais essayé UDP, mais ça n'améliore pas les choses et ça peut poser des problèmes sporadiques). Typiquement, la charge du serveur est inférieure à 1 et il répond sans problème. En retirant l'option intr et en rajoutant nolock sur /home et /opt/video, j'arrive à ouvrir KDE sans que cela ne plante. Mais il y a toujours des problèmes de vidéo. De temps en temps, ça fonctionne, puis ça se met à ne plus fonctionner. J'ai essayé à partir d'un compte avec un VLC correctement paramétré et le résultat est le même que le décodage soit fait par VAAPI ou en soft (libplacebo). Au bout d'un certain temps, la sortie son fini par devenir inactive et il me faut redémarrer la machine pour qu'elle fonctionne à nouveau. Je prends toute idée... Bien cordialement, JKB
Re: Problème de lecture vidéo (trop rapide)
Bonjour, Y a-t-il un problème sur la liste ? J'ai envoyé deux messages qui n'apparaissent pas alors que j'en ai reçu plusieurs autres plus récents...
Re: Problème de lecture vidéo (trop rapide)
didier.gau...@gmail.com a écrit : > Le mercredi 19 janvier 2022 à 19:35 +0100, BERTRAND Joël a écrit : >> >> Mais avec ma malchance coutumière ;-) >> >> En fait, le bon pilote était chargé (i965). J'ai tout de même >> désinstallé le pilote iHD. >> >> Le problème est assez étrange. J'arrive de temps en temps à >> passer une >> vidéo correctement mais la plupart du temps, j'ai le son qui saute >> (et >> pas de la même façon sous vlc ou mplayer). >> >> vlc : le son est haché (du son, un blanc, du son) mais la >> vidéo passe à >> la bonne vitesse. >> >> mplayer : le son est continue, mais la video saute (elle >> semble passer >> au moins deux fois plus vite, ce qui est aussi le cas sous firefox). >> >> Je n'arrive pas à voir une erreur ou un truc bozarre dans les >> logs. >> Typiquement, vlc m'indique dans la console : >> >> $ vlc >> VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2) >> [55dd83cec5b0] main libvlc: Lancement de vlc avec l'interface par >> défaut. Utiliser « cvlc » pour démarrer VLC sans interface. >> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to >> '/tmp/runtime-multimedia' >> [55dd83d98c90] main playlist: playlist is empty >> [7f1a64003990] gl gl: Initialized libplacebo v4.157.0 (API v157) >> libva info: VA-API version 1.13.0 >> libva info: User environment variable requested driver 'i965' >> libva info: Trying to open /usr/lib/x86_64-linux- >> gnu/dri/i965_drv_video.so >> libva info: Found init function __vaDriverInit_1_8 >> libva info: va_openDriver() returns 0 >> [7f1a7d1de040] avcodec decoder: Using Intel i965 driver for >> Intel(R) >> Haswell Desktop - 2.4.1 for hardware decoding >> >> Normalement, tout est bon de ce côté-là. Ça pourrait >> ressembler à une >> base de temps côté noyau qui n'est pas à la bonne vitesse. Je sèche >> lamentablement. >> >> Bien cordialement, >> >> JKB > > Euh là, je crains de ne pas être d'un quelconque secours, j'ai un peu > épuisé mes maigres idées :-) > > effectivement y a la grosse artillerie noyau (type et emploi des > schedulers et timers), mais peut-être aussi regarder si tu ne te > traines pas une vielle configuration perso de vlc et mplayer au noveau > du choix des types de sorties audio et vidéo: un choix inadapté peut > vite foutre la bazar, tu ne risques rien à vérifier, voire à essayer > d'autres types de sortie (surtout vidéo) Mauvaise pioche, c'est la première chose que j'ai virée... JKB
Re: Problème de lecture vidéo (trop rapide)
Le mercredi 19 janvier 2022 à 19:35 +0100, BERTRAND Joël a écrit : > > Mais avec ma malchance coutumière ;-) > > En fait, le bon pilote était chargé (i965). J'ai tout de même > désinstallé le pilote iHD. > > Le problème est assez étrange. J'arrive de temps en temps à > passer une > vidéo correctement mais la plupart du temps, j'ai le son qui saute > (et > pas de la même façon sous vlc ou mplayer). > > vlc : le son est haché (du son, un blanc, du son) mais la > vidéo passe à > la bonne vitesse. > > mplayer : le son est continue, mais la video saute (elle > semble passer > au moins deux fois plus vite, ce qui est aussi le cas sous firefox). > > Je n'arrive pas à voir une erreur ou un truc bozarre dans les > logs. > Typiquement, vlc m'indique dans la console : > > $ vlc > VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2) > [55dd83cec5b0] main libvlc: Lancement de vlc avec l'interface par > défaut. Utiliser « cvlc » pour démarrer VLC sans interface. > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to > '/tmp/runtime-multimedia' > [55dd83d98c90] main playlist: playlist is empty > [7f1a64003990] gl gl: Initialized libplacebo v4.157.0 (API v157) > libva info: VA-API version 1.13.0 > libva info: User environment variable requested driver 'i965' > libva info: Trying to open /usr/lib/x86_64-linux- > gnu/dri/i965_drv_video.so > libva info: Found init function __vaDriverInit_1_8 > libva info: va_openDriver() returns 0 > [7f1a7d1de040] avcodec decoder: Using Intel i965 driver for > Intel(R) > Haswell Desktop - 2.4.1 for hardware decoding > > Normalement, tout est bon de ce côté-là. Ça pourrait > ressembler à une > base de temps côté noyau qui n'est pas à la bonne vitesse. Je sèche > lamentablement. > > Bien cordialement, > > JKB Euh là, je crains de ne pas être d'un quelconque secours, j'ai un peu épuisé mes maigres idées :-) effectivement y a la grosse artillerie noyau (type et emploi des schedulers et timers), mais peut-être aussi regarder si tu ne te traines pas une vielle configuration perso de vlc et mplayer au noveau du choix des types de sorties audio et vidéo: un choix inadapté peut vite foutre la bazar, tu ne risques rien à vérifier, voire à essayer d'autres types de sortie (surtout vidéo)
Re: Problème de lecture vidéo (trop rapide)
didier gaumet a écrit : > > > Le dimanche 16 janvier 2022 à 16:46 +0100, BERTRAND Joël a écrit : > > [...] >> Le pilote graphique est bien intel-media-va-driver. > [...] > > - les specs de ton CPU sont là: > https://www.intel.com/content/www/us/en/products/sku/75044/intel-core-i54570s-processor-6m-cache-up-to-3-60-ghz/specifications.html > c'est une génération Haswell, GPU HD4600 > > - les plateformes supportées par ce nouveau backend VA-API sont là > (supported platforms): > https://github.com/intel/media-driver > et Haswell n'est pas mentionné > > - donc d'après ce sous-lien du lien précédemment indiqué: > https://wiki.debian.org/HardwareVideoAcceleration#VA-API > c'est peut-être justement le problème: sous Buster tu devais > fonctionner avec l'ancien backend i965-va-driver et ton matériel > devrait a priori toujours fonctionner avec ce backend et c'est > vraisemblablement une erreur (bug) qu'il soit détecté compatible avec > le nouveau backend intel-media-va-driver > > La solution serait de supprimer le paquet intel-media-va-driver et de > ne garder que le paquet i965-va-driver à sa place, ou si tu veux garder > les deux paquest installés, de modofoer la variable tel qu'iundiqué > dans le lien https://wiki.debian.org/HardwareVideoAcceleration#VA-API > > Avec un peu de chance... Mais avec ma malchance coutumière ;-) En fait, le bon pilote était chargé (i965). J'ai tout de même désinstallé le pilote iHD. Le problème est assez étrange. J'arrive de temps en temps à passer une vidéo correctement mais la plupart du temps, j'ai le son qui saute (et pas de la même façon sous vlc ou mplayer). vlc : le son est haché (du son, un blanc, du son) mais la vidéo passe à la bonne vitesse. mplayer : le son est continue, mais la video saute (elle semble passer au moins deux fois plus vite, ce qui est aussi le cas sous firefox). Je n'arrive pas à voir une erreur ou un truc bozarre dans les logs. Typiquement, vlc m'indique dans la console : $ vlc VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2) [55dd83cec5b0] main libvlc: Lancement de vlc avec l'interface par défaut. Utiliser « cvlc » pour démarrer VLC sans interface. QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-multimedia' [55dd83d98c90] main playlist: playlist is empty [7f1a64003990] gl gl: Initialized libplacebo v4.157.0 (API v157) libva info: VA-API version 1.13.0 libva info: User environment variable requested driver 'i965' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_8 libva info: va_openDriver() returns 0 [7f1a7d1de040] avcodec decoder: Using Intel i965 driver for Intel(R) Haswell Desktop - 2.4.1 for hardware decoding Normalement, tout est bon de ce côté-là. Ça pourrait ressembler à une base de temps côté noyau qui n'est pas à la bonne vitesse. Je sèche lamentablement. Bien cordialement, JKB
Re: Problème de lecture vidéo (trop rapide)
didier gaumet a écrit : > > > Le dimanche 16 janvier 2022 à 16:46 +0100, BERTRAND Joël a écrit : > > [...] >> Le pilote graphique est bien intel-media-va-driver. > [...] > > - les specs de ton CPU sont là: > https://www.intel.com/content/www/us/en/products/sku/75044/intel-core-i54570s-processor-6m-cache-up-to-3-60-ghz/specifications.html > c'est une génération Haswell, GPU HD4600 > > - les plateformes supportées par ce nouveau backend VA-API sont là > (supported platforms): > https://github.com/intel/media-driver > et Haswell n'est pas mentionné > > - donc d'après ce sous-lien du lien précédemment indiqué: > https://wiki.debian.org/HardwareVideoAcceleration#VA-API > c'est peut-être justement le problème: sous Buster tu devais > fonctionner avec l'ancien backend i965-va-driver et ton matériel > devrait a priori toujours fonctionner avec ce backend et c'est > vraisemblablement une erreur (bug) qu'il soit détecté compatible avec > le nouveau backend intel-media-va-driver > > La solution serait de supprimer le paquet intel-media-va-driver et de > ne garder que le paquet i965-va-driver à sa place, ou si tu veux garder > les deux paquest installés, de modofoer la variable tel qu'iundiqué > dans le lien https://wiki.debian.org/HardwareVideoAcceleration#VA-API > > Avec un peu de chance... Il faut le noyau de testing et virer intel-media-va-driver pour que ça fonctionne à nouveau presque correctement. Je dis _presque_ parce que kde/x11 ne démarre plus. Soit j'ai le fond d'écran (mais sans le tableau de bord), soit le logo sur fond noir (et systemd-udev qui mouline). À suivre. Merci, JKB
Re: Problème de lecture vidéo (trop rapide)
Le dimanche 16 janvier 2022 à 16:46 +0100, BERTRAND Joël a écrit : [...] > Le pilote graphique est bien intel-media-va-driver. [...] - les specs de ton CPU sont là: https://www.intel.com/content/www/us/en/products/sku/75044/intel-core-i54570s-processor-6m-cache-up-to-3-60-ghz/specifications.html c'est une génération Haswell, GPU HD4600 - les plateformes supportées par ce nouveau backend VA-API sont là (supported platforms): https://github.com/intel/media-driver et Haswell n'est pas mentionné - donc d'après ce sous-lien du lien précédemment indiqué: https://wiki.debian.org/HardwareVideoAcceleration#VA-API c'est peut-être justement le problème: sous Buster tu devais fonctionner avec l'ancien backend i965-va-driver et ton matériel devrait a priori toujours fonctionner avec ce backend et c'est vraisemblablement une erreur (bug) qu'il soit détecté compatible avec le nouveau backend intel-media-va-driver La solution serait de supprimer le paquet intel-media-va-driver et de ne garder que le paquet i965-va-driver à sa place, ou si tu veux garder les deux paquest installés, de modofoer la variable tel qu'iundiqué dans le lien https://wiki.debian.org/HardwareVideoAcceleration#VA-API Avec un peu de chance...
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é :-) C'est incompréhensible. intel-microcode, firmware-linux, firmware-misc-nonfree sont installés (ainsi que d'autres). Le pilote graphique est bien intel-media-va-driver. Je me suis aperçu que le noyau était un 5.10.0-9 alors que le 5.10.0-10 est dans /boot (la machine est diskless, je dois changer le noyau à la main côté serveur tftp et j'ai oublié lors de la dernière mise à jour sans doute silencieuse.). J'ai changé la ligne du daemon tftp et la machine est actuellement en 5.10.0-10. Ça fonctionne mieux avec ce dernier noyau. En revanche, le son n'est toujours pas net (il peut y avoir des grésillements) et il y a un autre truc bizarre. Lorsque vlc est en taille maximale (mais pas en plein écran au sens de la touche F), il fonctionne à peu près. Lorsqu'il est en plein écran, le son redevient saccadé. J'ai vérifié, il utilise à ce moment moins de 10% d'un coeur de CPU (Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz). Le réseau n'est pas saturé non plus. Je viens aussi de m'apercevoir qu'après quelques manipulations (ouverture et fermetures de vlc par exemple), la sortie son (HDMI3 dans mon cas) peut partir en sucette et ne plus rien renvoyer du tout. Ça pue un problème de noyau, je suis en train de tout passer en testing pour voir. JKB
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
Re: Problème de lecture vidéo (trop rapide)
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é :-)
Re: Problème de lecture vidéo (trop rapide)
Le 15/01/2022 à 22:27, BERTRAND Joël a écrit : Bonjour à tous, J'utilise une debian/stable comme lecteur multimédia. Cette machine fonctionnait très bien avec oldstable mais je l'ai mise à jour récemment vers stable. Depuis, les vidéos sont lues trop vite. Toutes les vidéos, quelle que soit la source et le logiciel utilisé. Un replay dans firefox tourne à peu près deux fois trop vite. Idem dans mplayer. Dans vlc, c'est un peu différent : vlc essaye de synchroniser le nombre d'images par seconde et le son ne suit pas (il est saccadé). En d'autres termes, vlc se débrouille pour synchroniser l'image sur le temps réel, mais le son est produit par à-coups. La machine possède 8Go de mémoire (pas de swap) et le cpu est un i5/4xxx (2900 MHz), ce qui est normalement bien assez puissant pour lire des vidéos, même avec le GPU intégré. La distribution est une stable à jour (noyau 5.10). J'avoue ne pas savoir où chercher, le problème ne semble pas provenir d'un logiciel en particulier, mais du système. Il doit peut être te rester des scories de l'ancien système ? Est-ce que tu peux booter la machine sur un live cd récent et lire les vidéos ? Pour voir si ça vient de la machine ou de la mise à jour ? -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux===
Problème de lecture vidéo (trop rapide)
Bonjour à tous, J'utilise une debian/stable comme lecteur multimédia. Cette machine fonctionnait très bien avec oldstable mais je l'ai mise à jour récemment vers stable. Depuis, les vidéos sont lues trop vite. Toutes les vidéos, quelle que soit la source et le logiciel utilisé. Un replay dans firefox tourne à peu près deux fois trop vite. Idem dans mplayer. Dans vlc, c'est un peu différent : vlc essaye de synchroniser le nombre d'images par seconde et le son ne suit pas (il est saccadé). En d'autres termes, vlc se débrouille pour synchroniser l'image sur le temps réel, mais le son est produit par à-coups. La machine possède 8Go de mémoire (pas de swap) et le cpu est un i5/4xxx (2900 MHz), ce qui est normalement bien assez puissant pour lire des vidéos, même avec le GPU intégré. La distribution est une stable à jour (noyau 5.10). J'avoue ne pas savoir où chercher, le problème ne semble pas provenir d'un logiciel en particulier, mais du système. Je prends donc toute idée ;-) Merci par avance, JKB
