qui dit première dit "last but not least" non ? (ha !!! les joies du gros oeuvre) . Et donc clap clap clap !!!
Maintenant utiliser un binaire sur une autre machine que celle sur laquelle il a été compilé mmmh.... un coup oui, un coup non . Les binaires des dépôts .deb sont compilés en environnement "chroot" un peu particulier pour être universels ou du moins génériques (flags des processeurs etc...) .
Il y a des débats en cours chez debian (et donc ses dérivées) pour revenir à ffmpeg en place du libav actuel qui oblige à ce genre de manoeuvres (une version statique) pour cause d'incompatibilité . Croisons les doigts .
Dernière modification par sakramh (2014-11-20 13:02:04)
Hors ligne
suite à un retour vers le passé (2014) j'ai trouvé une petite astuce qui permet de gagner un bon 5% de cpu avec [pix_snap] . Ne pas lui imposer de vitesse et il appuie sur le champignon, le bougre .
@Tepaze : elle permettra peut-être d'optimiser ton usine à gaz ffmpeg etc ... (vitesse variable de ~18 à 25 ips)
ps: on doit pouvoir simplifier et se passer du spigot etc ... eu la flemme de vérifier
GROS EDIT :
ben j'aurais dû . En fait il faut que ce soit synchronisé par le [t a b] et j'ai l'impression que si on sort de la vitesse de [gemwin] (ici 25ips) le résultat est bizarre (par paquets) .
(j'avais fait l'essai avec une webcam qui sort au mieux 12 ips en éclairage artificiel d'où pas vu le souci)
Avec un film à 25 ips si on descend à 5 sur le [metro] la conso cpu remonte de 5% et pas de diff à l'oeil .
A 10 y a un léger effet de ralenti sans "stretch" temporel et la conso redescend de 5% . En dehors des sous multiple de 25 c'est n'importe quoi (et donc le [metro] plutôt 5, 10, 15, etc...) . Bon ben çà fera un effet pas cher
Dernière modification par sakramh (2015-01-02 13:53:35)
Hors ligne