Bonjour à tous,

Voici une nouvelle énigme sous ffmpeg la libx265 utilise moins de 50% de la capacité  avec la même ligne de commande dans le terminal que la libx264

Avec plusieurs essais sa décolle pas à plus de 50%, est on en 32bits ?

exemple : ffmpeg -i source.h264.mp4 -c:v libx265 -preset=ultrafast -b:v 800k -c:a copy output.h265.mp4

 

 

 

 

C'est plus un problème de multi-thread que d'architecture 32/64.

Quel est le modèle de ton NAS ?

Utilisé son nas pour convertir ses vidéos, je l'avais jamais vue celle la 

il y a 26 minutes, PiwiLAbruti a dit :

C'est plus un problème de multi-thread que d'architecture 32/64.

Quel est le modèle de ton NAS

Ok pour cette piste mais alors pourquoi la libx264 fonctionne à  presque 100%

Mon modèle est un DS 916+ 2go pour l'instant,

il y a 7 minutes, Einsteinium a dit :

Utilisé son nas pour convertir ses vidéos, je l'avais jamais vue celle la 

Cote encodage par le nas = autant le faire bosser car il a les fichiers scr, il me libère les pc et de plus ils sont tous chez moi  moins puissant que lui

il y a une heure, Einsteinium a dit :

Utilisé son nas pour convertir ses vidéos, je l'avais jamais vue celle la 

C'est quoi le transcodage d'après toi ? 

il y a 53 minutes, boris21dd a dit :

Ok pour cette piste mais alors pourquoi la libx264 fonctionne à  presque 100%

Parce que la libx264 supporte le multi-thread.

Par contre le DS916+ étant équipé d'un quad-core natif (Pentium N3710, 4C/4T), ça voudrait dire que la libx265 serait limitée à 2 threads ? Ça me semble peu probable. Il y a peut-être des éléments de réponse dans les options de compilation de libx265, notamment au niveau du patch pour PPC.

Modifié le 24 mai 20178 a par PiwiLAbruti

il y a une heure, PiwiLAbruti a dit :

C'est quoi le transcodage d'après toi ? 

Ouai enfin y a celui à la volé pour le streaming, et celui ou tu as une bécane dédié pour faire un joli travail et avec une bien meilleure compression, le nas c'est vraiment pas pour ce genre de tâche..

Le rôle premier du transcodage chez Synology est de rendre un format vidéo compatible avec un lecteur multimédia, et dans un second temps de réduire un flux vidéo pour le rendre lisible en direct sur une connexion distante.

Même si un NAS mettra plus de temps qu'une machine taillée pour l'encodage, ça suffit dans beaucoup de cas et ça évite de devoir laisser un PC allumé pour encoder.

Dans le cas présent, je trouve même intéressant que l'encodage x265 n'utilise pas tout le CPU car ça laisse des ressources disponibles pour les autres tâches lors de l'encodage (par contre ça prend évidemment 2x plus de temps à encoder).

Pourquoi passer en h265 dans ma configuration ?

Si votre bande passante est limitée, il permet d'offrir un bitrate "mb/s" bien meilleur vs h264

Si les plusieurs utilisateurs ont une bande passante limitée, le x265 offre une meilleure chance de vous éviter le transcodage pour peut que les machines soient compatibles

il y a 18 minutes, PiwiLAbruti a dit :

Le rôle premier du transcodage chez Synology est de rendre un format vidéo compatible avec un lecteur multimédia, et dans un second temps de réduire un flux vidéo pour le rendre lisible en direct sur une connexion distante.

Même si un NAS mettra plus de temps qu'une machine taillée pour l'encodage, ça suffit dans beaucoup de cas et ça évite de devoir laisser un PC allumé pour encoder.

Dans le cas présent, je trouve même intéressant que l'encodage x265 n'utilise pas tout le CPU car ça laisse des ressources disponibles pour les autres tâches lors de l'encodage (par contre ça prend évidemment 2x plus de temps à encoder).

Effectivement l'idée de diviser la charge par deux du cpu peut être inintéressante pour laisser la place à d'autres applications mais sous windows je mets le processus en low priority ici on pourrait faire cela je crois :

root@Synology:~# renice --help
BusyBox v1.16.1 (2012-05-10 02:27:56 CST) multi-call binary.

Usage: renice {{-n INCREMENT} | PRIORITY} [[-p | -g | -u] ID...]

Change priority of running processes

Options:
   -n   Adjust current nice value (smaller is faster)
   -p   Process id(s) (default)
   -g   Process group id(s)
   -u   Process user name(s) and/or id(s)

Mais bon, on ne révolutionne pas le problème inverse qui était la base du post