Ça fait un moment que j'essaye les différentes options de lecture vidéo pour que la batterie tienne un maximum dans le train… ma dernière trouvaille est la ligne de commande gstreamer, puisque ni totem ni dragonplayer n'activent VAAPI.
Quelques défauts, on ne peut pas faire pause ni naviguer dans le film, et la suspension de la veille écran ne se fait pas.
Voici les consommations obtenues avec in Intel i3-4000 avec un MKV en 1080p:
- vaplay : ~7500mW
- mplayer (VDPAU) : ~9000mW
- mplayer (SOFTWARE) ou vlc : ~12000mW
vaplay est un simple script d'une ligne perso :
gst-launch-1.0 -v filesrc location="$1" ! matroskademux name=de de. ! queue ! vaapidecode ! vaapisink fullscreen=true de. ! queue ! decodebin ! audioconvert ! audioresample ! pulsesink
pour mesurer la consommation, j'utilise ça :
while echo $(($(cat /sys/bus/acpi/drivers/battery/PNP0C0A\:00/power_supply/BAT1/power_now)/ ( $(cat /sys/bus/acpi/drivers/battery/PNP0C0A\:00/power_supply/BAT1/voltage_now) /10000 ) ))mW $(date); do sleep 20; done
ça donne un chiffre qui correspond à celui indiqué par powertop.
# VLC
Posté par Olivier Esver (site web personnel) . Évalué à 4.
Ton utilisation de VLC c'est avec l'accélération hardware ?
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: VLC
Posté par hugoL . Évalué à 2. Dernière modification le 07 janvier 2015 à 11:18.
Oui ça serait intéressant, en théorie VLC supporte VAAPI.
[^] # Re: VLC
Posté par ʭ ☯ . Évalué à 9.
En pratique VLC 2.1.x saccade avec VAAPI ou VDPAU sur matériel Intel. Le vrai support viendra avec vlc 2.2.x, qui aura des modifications en profondeur car actuellement il y a un va et vient entre le décodeur matériel et vlc, qui fait perdre tout le bénéfice batterie.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: VLC
Posté par davandg . Évalué à 2.
vlc 2.2 qui vient d'arriver dans debian-multimedia testing !
[^] # Re: VLC
Posté par ʭ ☯ . Évalué à 5.
Alors qu'il n'y a toujours pas de tarball, c'est une version de développement.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: VLC
Posté par fcartegnie . Évalué à 3.
VAAPI (2.1) et VDPAU (2.2)
# mpv
Posté par Reihar . Évalué à 7.
Mpv supporte VA-API et VDPAU. Mplayer aussi, même s'il faut passer par des hacks.
Les options de driver video pour mpv sont par là. La page d'options peut aussi être intéressante.
[^] # Re: mpv
Posté par ʭ ☯ . Évalué à 2.
J'utilise mplayer avec vdpau. Je ne pense pas que mpv fasse mieux, vu qu'il utilise le même code pour l'instant…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: mpv
Posté par Reihar . Évalué à 2.
Au temps pour moi, j'avais lu un peu vite. C'est pour va-api qu'il faut passer par des hacks pour mplayer.
Mpv ne fera pas forcément mieux, en effet, je l'ai plus mis en avant pour plusieurs raisons. Déjà, parce que c'est celui que j'utilise donc je suis plus apte à donner des conseils ou à en parler mais aussi parce que mpv vient avec plusieurs améliorations pratiques, comme par exemple une normalisation des options qui est grandement bienvenue, tellement c'est n'importe quoi pour mplayer.
[^] # Re: mpv
Posté par Pseudo007 . Évalué à 7.
J'ai beaucoup utilisé mplayer, maintenant j'utilise mpv depuis 4 ou 6 mois, clairement mpv est meilleur. J'utilise mpv avec vaapi, j'ai utilisé mplayer avec vaapi (avec un vieux patch qui n'était pas tenu à jour). Je peux pas dire lequel des deux consomme le moins, j'ai oublié pour mplayer.
Les différences entre mpv et mplayer sont assez massives pour qu'il soit très délicat aujourd'hui de dire qu'ils utilisent le même code. mpv a 2 fois moins de code que mplayer car il y a eu un énorme nettoyage et le développement est beaucoup beaucoup plus dynamique. Puis mpv se base sur mplayer ET mplayer 2. Enfin, se basait, car maintenant c'est séparé, mpv ne récupère plus rien de mplayer(2) depuis des mois.
C'est la même chose grosso-modo pour l'interface utilisateur, la même philosophie, mais les différences internes sont énormes entre mpv et mplayer. J'ai pas utilisé mplayer 2.
Goûter à mpv, c'est l'adopter.
À toutes fins utiles : http://mpv.io/
# Autre piste
Posté par Janfi . Évalué à 5.
Il fut un temps où j'avais le même genre de préoccupations, mais pas le même matériel.
Une "astuce" que j'employais, c'était de charger l'intégralité de la vidéo en RAM (mais avec une vidée HD c'est sans doute plus compliqué) afin qu'il n'y ait plus d'accès disque, et donc permettre un passage en veille du disque dur.
Je ne me souviens plus du gain, mais il était suffisamment intéressant pour que je le fasse à chaque fois.
[^] # Re: Autre piste
Posté par Plume . Évalué à 1.
Pourrait-on pousser l'idée plus loin ?
Avec un système ayant suffisamment de RAM (4-8 Go), serait-il possible de configurer un boot de manière à lancer le système, charger ce qu'il faut en RAM et d'ensuite éteindre le DD totalement et faire toutes ses opérations en RAM ?
Après tout, si l'on sait que tout ce qu'on va faire sera regarder une vidéo et que la RAM consomme moins qu'un DD, pourquoi ne pas tous mettre en RAM ?
[^] # Re: Autre piste
Posté par Olivier Serve (site web personnel) . Évalué à 1.
Tu veux dire mettre tout le système en initramfs et ne monter aucune partition ?
[^] # Re: Autre piste
Posté par Plume . Évalué à 1.
Je ne connais pas tous les détails du boot sous Linux, mais j'ai plutôt l'impression qu'il s'agit de cela.
[^] # Re: Autre piste
Posté par SChauveau . Évalué à 2.
C'est probablement se donner beaucoup de mal pour pas grand chose.
Pour maximiser le temps que le disque passe en veille, il suffit de bien configurer son système pour éviter les accès inutiles.
Voici quelques astuces que j'utilisais avant d'acheter un SSD.
(1) Mettre /tmp en ramdisk
(2) Surveiller /var/log pour détecter les services qui écrivent trop souvent dans les logs.
(3) Utiliser un programme comme iotop pour détecter les services qui utiliseraient encore le disque.
(4) Augmenter (pas trop quand même) la valeur de dirty_writeback_centisecs (avec sysctl) pour 'flusher' moins souvent les écritures sur les disques. Par défaut c'est 500 (= 5 secondes).
[^] # Re: Autre piste
Posté par Marotte ⛧ . Évalué à 2.
Tu as une méthode à conseiller ?
[^] # Re: Autre piste
Posté par SChauveau . Évalué à 2.
Pour trouver tout les fichiers de log modifiés depuis moins de 3 minutes
find /var/log -type f -mmin -3
Et pour les trier par ordre chronologique (en bash):
ls -ltr $(find /var/log -type f -mmin -3)
J'utiliserai ensuite 'tail -f' pour surveiller un fichier suspect en temps réel:
tail -f /var/log/syslog
[^] # Re: Autre piste
Posté par Donk . Évalué à 1.
Slitaz le permet
http://www.slitaz.org/fr/about/
[^] # Re: Autre piste
Posté par Kerro . Évalué à 2.
Les caches de systèmes de fichiers font déjà cela. Sauf que bien souvent on écrit dans les journaux système, on écrit ici et là. Et pour écrire, il faut que le disque tourne.
Ou alors on décide d'écrire en mémoire et de ne copier sur disque que toutes les 25 minutes. Pour un ordinateur portable, je pense que ça ne pose pas de problème tant qu'on n'est pas en train d'éditer sa thèse.
[^] # Re: Autre piste
Posté par Marotte ⛧ . Évalué à 3.
On peut éventuellement copier son travail sur un périphérique USB, toute les 5 voir 1 minute, et avoir tout l'OS en RAM. Comme ça on peut écrire sa thèse l'esprit libre et limiter son impact sur la fonte de la banquise et des glaciers…
[^] # Re: Autre piste
Posté par karteum59 . Évalué à 3.
Vu la fiabilité des clés USB (à peine meilleure que les disquettes), je n'aurais personnellement pas l'esprit très libre…
Mouais, l'utilisation d'une machine ne pèse pas grand chose par rapport à l'impact de sa fabrication => le meilleur moyen de limiter son impact serait plutôt de changer de machine moins souvent… (ce qui peut impliquer d'avoir de vieux disques énergivores, et peut-être de ne pas avoir assez de RAM pour y faire tenir tout le système !).
[^] # Re: Autre piste
Posté par Marotte ⛧ . Évalué à 2.
Les clés USB et autres cartes SD (voir DD portables) sont actuellement le moyen le plus efficace de stocker des données en les dispersant de manière physique afin d'accentuer la rémanence des données… C'est clairement les disquettes du 21e siècle… et je pense que leur fiabilité est meilleure (on parle de circuits intégrés vs disque en plastic vaguement magnétisé…).
[^] # Re: Autre piste
Posté par karteum59 . Évalué à 3.
ça implique de s'organiser pour faire du RAID "à la mano" (ce que personne ne fait. Au mieux, on a un joyeux bazar avec en partie les mêmes données (souvent dans des versions différentes) sur plusieurs clés USB)
Mouais bof… je ne compte plus le nombre de cartes SD et de clés USB qui ont cramé aléatoirement (alors qu'elles n'étaient pas si anciennes). Et pour le coup: lorsque ça crame et qu'elles ne sont plus reconnu, il n'existe aucun moyen de récupérer (même partiellement) les données !
[^] # Re: Autre piste
Posté par Boa Treize (site web personnel) . Évalué à 2.
Bien sûr, je le fais régulièrement avec une clé USB. Quand je n'ai pas besoin de parcourir mon disque dur de données (surf sur Internet, etc.), je l'éteins, c'est assez impressionnant de n'avoir pratiquement plus aucun bruit ni vibration ou chaleur qui sort de l'ordi portable (qui est de base assez discret). Il ne reste qu'un très léger fond de ventilo CPU, mais c'est quasi-rien.
[^] # Re: Autre piste
Posté par ʭ ☯ . Évalué à 2.
Sans s'embêter à ce point, il faut désactiver les journaux système (journald pour ma part), et utiliser pm-powersave quand on passe en batterie. J'ai un portable où le ventilo du cpu ne démarre pas en dessous de 60°, c'est silence absolu!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Mon expérience
Posté par Pseudo007 . Évalué à 1. Dernière modification le 08 janvier 2015 à 06:57.
En consommation en utilisant vaapi, mpv consomme nettement moins que vaplay. Enfin, j'ai pas utilisé vaplay, mais totem qui utilise gstreamer.
Utilisation CPU avec vaapi pour mpv pour lire un dvd (47 Go) qui est sur mon disque dur, 5 % d'un thread CPU (i7-4770S 3.1 Ghz, 8 threads). Les doigts dans le nez quoi.
En consommation énergétique, je peux seulement dire que le cpu/gpu est à plein plus chaud que si le PC ne fout rien.
[^] # Re: Mon expérience
Posté par ʭ ☯ . Évalué à 3.
Relis le journal : "puisque ni totem ni dragonplayer n'activent VAAPI." Tu crois que je m'embêterais à bricoler un script si Totem rendait le même service?
Ensuite pour l'utilisation CPU, j'ai bien indiqué en 1080p, car le DVD est un format trop léger pour que la différence de consommation soit notable.
Enfin pour la température, c'est moins évident car bien qu'elle soit proportionnelle à la consommation, le BIOS peut être programmé pour altérer la vitesse du ventilateur suivant les usages.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Mon expérience
Posté par Pseudo007 . Évalué à 1. Dernière modification le 09 janvier 2015 à 08:57.
Chez moi Totem active vaapi (ya une case à cocher). Et je vois bien la différence en consommation CPU entre les deux. Y a pas de doute, la seule accélération hardware que je peux avoir est vaapi.
Le Totem que j'ai utilisé est simplement celui livré avec Fedora 20.
EDIT : il faut bien sûr installer le paquet gstreamer1-vaapi.
Là j'ai fait une erreur. Je parlais d'un bluray, donc 1080p. Et vraiment 1080p (1920x1080) car c'est Avatar que j'ai utilisé qui est en 16:9. J'ai indiqué que ça pèse 47 Go, c'est pas le poids d'un dvd, mais d'un bluray.
J'ai pas de ventilateur (mais un radiateur), je suis fanless (CPU et le reste). NB: c'est un i7-4770S (S! et pas K, faible consommation.). La température varie nettement avec la charge du CPU. de 40° à 85°. En lisant un bluray, je dépasse pas les 50° en faisans d'autres trucs bureautique à côté.
[^] # Re: Mon expérience
Posté par ʭ ☯ . Évalué à 2.
Pas de souci, on se comprend. J'avais vraiment compris DVD, me disant que 47Go était une coquille pour 4,7Go ;-)
Par contre, je ne trouve pas où activer VAAPI dans Totem… J'ai le 3.14, avec Mageia 5. Une piste? Merci.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.