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:frederic@juliana-multimedia.com |
| +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===========================Debian=GNU/Linux===

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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é :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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) [000055dd83cec5b0] 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'
[000055dd83d98c90] main playlist: playlist is empty
[00007f1a64003990] 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
[00007f1a7d1de040] 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)