FFMPEG Encodage massivement parallèle par segments/réassemblage
14 réponses
Olivier B.
salut,
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG",
potentiellement je peux activer des clients sur des centaines de
machine, mais chaque fichier est confronté à une limite incompressible
liée à sont affectation sur une machine.
Pour optimiser je pense àmodifier le moteur de workflow pour qu'il
c'ée des jobs d'encodage partiels distribués sur différentes machines,
par exemple
job1 de 00:00:00:00 à 00:00:59:24 --> PC1
job2 de 00:01:00:00 à 00:01:59:24 --> PC2
...
jobx de xx:xx:00:00 à la fin du fichier --> PCx
Ensuiteune fois toutes les parties codées un dernier job de
concaténation/remux réassemble le tout, l'optimisation serait énorme.
Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC
ou HEVC ?
salut, Dans ma boite on fait de l'encodage en "ferme FFMPEG", Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ?
ici, ce serait un miracle. par contre les dev de ffmpeg seraient surement intéressés https://ffmpeg.org/mailman/listinfo je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-)) bravo :-) jdd -- http://dodin.org
Le 28/07/2020 à 22:37, Olivier B. a écrit :
salut,
Dans ma boite on fait de l'encodage en "ferme FFMPEG",
Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC
ou HEVC ?
ici, ce serait un miracle. par contre les dev de ffmpeg seraient
surement intéressés
https://ffmpeg.org/mailman/listinfo
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de
cinelerra, il doit y avoir 15 ans :-))
salut, Dans ma boite on fait de l'encodage en "ferme FFMPEG", Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ?
ici, ce serait un miracle. par contre les dev de ffmpeg seraient surement intéressés https://ffmpeg.org/mailman/listinfo je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-)) bravo :-) jdd -- http://dodin.org
Alf92
Olivier B. (le 28/07/2020 à 22:37:02) :
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG", potentiellement je peux activer des clients sur des centaines de machine, mais chaque fichier est confronté à une limite incompressible liée à sont affectation sur une machine. Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme. Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ? Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques. la première concerne le besoin : en AVC l'encodage est relativement rapide sur une machine moderne (x4), un peu plus long pour du HEVC (x1). tu bosses probablement pour une chaine de TV. avez-vous vraiment besoin d'encoder si rapidement ? si le proc est multicore, ffmpeg peut fonctionner en multi-threads. et l'encodage matériel avec une carte graphique un peu costaude...? la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent galéré pour finir en général à la main avec MKVToolnix. quant au son c'est pareil, ça peut être casse gueule (pb synchro si une trame manque,...) bref, la mise en place du workflow n'est pas évidente, alors qu'avec un encodage image + son sur une seule machine rapaide...
Olivier B. (le 28/07/2020 à 22:37:02) :
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG",
potentiellement je peux activer des clients sur des centaines de
machine, mais chaque fichier est confronté à une limite incompressible
liée à sont affectation sur une machine.
Pour optimiser je pense àmodifier le moteur de workflow pour qu'il
c'ée des jobs d'encodage partiels distribués sur différentes machines,
par exemple
job1 de 00:00:00:00 à 00:00:59:24 --> PC1
job2 de 00:01:00:00 à 00:01:59:24 --> PC2
...
jobx de xx:xx:00:00 à la fin du fichier --> PCx
Ensuiteune fois toutes les parties codées un dernier job de
concaténation/remux réassemble le tout, l'optimisation serait énorme.
Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC
ou HEVC ?
Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques.
la première concerne le besoin : en AVC l'encodage est relativement rapide
sur une machine moderne (x4), un peu plus long pour du HEVC (x1).
tu bosses probablement pour une chaine de TV. avez-vous vraiment besoin
d'encoder si rapidement ?
si le proc est multicore, ffmpeg peut fonctionner en multi-threads.
et l'encodage matériel avec une carte graphique un peu costaude...?
la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent
galéré pour finir en général à la main avec MKVToolnix.
quant au son c'est pareil, ça peut être casse gueule (pb synchro si une
trame manque,...)
bref, la mise en place du workflow n'est pas évidente, alors qu'avec un
encodage image + son sur une seule machine rapaide...
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG", potentiellement je peux activer des clients sur des centaines de machine, mais chaque fichier est confronté à une limite incompressible liée à sont affectation sur une machine. Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme. Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ? Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques. la première concerne le besoin : en AVC l'encodage est relativement rapide sur une machine moderne (x4), un peu plus long pour du HEVC (x1). tu bosses probablement pour une chaine de TV. avez-vous vraiment besoin d'encoder si rapidement ? si le proc est multicore, ffmpeg peut fonctionner en multi-threads. et l'encodage matériel avec une carte graphique un peu costaude...? la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent galéré pour finir en général à la main avec MKVToolnix. quant au son c'est pareil, ça peut être casse gueule (pb synchro si une trame manque,...) bref, la mise en place du workflow n'est pas évidente, alors qu'avec un encodage image + son sur une seule machine rapaide...
Alf92
jdd (le 29/07/2020 à 08:32:44) :
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible qu'aujourd'hui
jdd (le 29/07/2020 à 08:32:44) :
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de
cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible
qu'aujourd'hui
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible qu'aujourd'hui
jdd
Le 29/07/2020 à 11:10, Alf92 a écrit :
jdd (le 29/07/2020 à 08:32:44) :
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible qu'aujourd'hui
en même temps nous ne connaissons rien des besoins d'Olivier... j'ai déjà entendu dire que la vidéo surveillance était gourmande, mais déjà si je pouvais mettre mes propres ordis en grappe pour gérer mes vidéos, ce serait bien - mais j'ai la flemme d'étudier la config. en ce moment, sur mon portable, j'ai régulièrement des baisses de vitesse proc pour surchauffe en moulinant mes vidéos (normalisation des archives) jdd -- http://dodin.org
Le 29/07/2020 à 11:10, Alf92 a écrit :
jdd (le 29/07/2020 à 08:32:44) :
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de
cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible
qu'aujourd'hui
en même temps nous ne connaissons rien des besoins d'Olivier...
j'ai déjà entendu dire que la vidéo surveillance était gourmande, mais
déjà si je pouvais mettre mes propres ordis en grappe pour gérer mes
vidéos, ce serait bien - mais j'ai la flemme d'étudier la config.
en ce moment, sur mon portable, j'ai régulièrement des baisses de
vitesse proc pour surchauffe en moulinant mes vidéos (normalisation des
archives)
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible qu'aujourd'hui
en même temps nous ne connaissons rien des besoins d'Olivier... j'ai déjà entendu dire que la vidéo surveillance était gourmande, mais déjà si je pouvais mettre mes propres ordis en grappe pour gérer mes vidéos, ce serait bien - mais j'ai la flemme d'étudier la config. en ce moment, sur mon portable, j'ai régulièrement des baisses de vitesse proc pour surchauffe en moulinant mes vidéos (normalisation des archives) jdd -- http://dodin.org
Olivier B.
On Wed, 29 Jul 2020 11:07:08 +0200, Alf92 wrote:
Olivier B. (le 28/07/2020 à 22:37:02) :
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG", potentiellement je peux activer des clients sur des centaines de machine, mais chaque fichier est confronté à une limite incompressible liée à sont affectation sur une machine. Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme. Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ? Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques. la première concerne le besoin : en AVC l'encodage est relativement rapide sur une machine moderne (x4), un peu plus long pour du HEVC (x1). tu bosses probablement pour une chaine de TV. avez-vous vraiment besoin d'encoder si rapidement ?
ce serait inovant
si le proc est multicore, ffmpeg peut fonctionner en multi-threads.
c'est le cas pas defaut, mais chaques codec a ensuite ses propres limites en nombre de threads simultanés, on dispose de machines Xeon avec plusieurs dizaines de coeurs, même en forçant le nombre les librairies avc et hevc ffmpeg n'exploitent qu'une partie des pcocs, du coup avec l'encodage en ferme on a un produit disposant d'un rapport efficacité/cout assez surprenant.
et l'encodage matériel avec une carte graphique un peu costaude...? la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent galéré pour finir en général à la main avec MKVToolnix. quant au son c'est pareil, ça peut être casse gueule (pb synchro si une trame manque,...)
merci pour le retour
bref, la mise en place du workflow n'est pas évidente, alors qu'avec un encodage image + son sur une seule machine rapaide...
l'innovant n'a jamais rien eu d'évident :-) disons qu'on se garde ça sous le coude... -- Mail .invalid
On Wed, 29 Jul 2020 11:07:08 +0200, Alf92 <alf921@gmail.com> wrote:
Olivier B. (le 28/07/2020 à 22:37:02) :
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG",
potentiellement je peux activer des clients sur des centaines de
machine, mais chaque fichier est confronté à une limite incompressible
liée à sont affectation sur une machine.
Pour optimiser je pense àmodifier le moteur de workflow pour qu'il
c'ée des jobs d'encodage partiels distribués sur différentes machines,
par exemple
job1 de 00:00:00:00 à 00:00:59:24 --> PC1
job2 de 00:01:00:00 à 00:01:59:24 --> PC2
...
jobx de xx:xx:00:00 à la fin du fichier --> PCx
Ensuiteune fois toutes les parties codées un dernier job de
concaténation/remux réassemble le tout, l'optimisation serait énorme.
Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC
ou HEVC ?
Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques.
la première concerne le besoin : en AVC l'encodage est relativement rapide
sur une machine moderne (x4), un peu plus long pour du HEVC (x1).
tu bosses probablement pour une chaine de TV.
avez-vous vraiment besoin d'encoder si rapidement ?
ce serait inovant
si le proc est multicore, ffmpeg peut fonctionner en multi-threads.
c'est le cas pas defaut, mais chaques codec a ensuite ses propres
limites en nombre de threads simultanés, on dispose de machines Xeon
avec plusieurs dizaines de coeurs, même en forçant le nombre les
librairies avc et hevc ffmpeg n'exploitent qu'une partie des pcocs, du
coup avec l'encodage en ferme on a un produit disposant d'un rapport
efficacité/cout assez surprenant.
et l'encodage matériel avec une carte graphique un peu costaude...?
la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent
galéré pour finir en général à la main avec MKVToolnix.
quant au son c'est pareil, ça peut être casse gueule (pb synchro si une
trame manque,...)
merci pour le retour
bref, la mise en place du workflow n'est pas évidente, alors qu'avec un
encodage image + son sur une seule machine rapaide...
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG", potentiellement je peux activer des clients sur des centaines de machine, mais chaque fichier est confronté à une limite incompressible liée à sont affectation sur une machine. Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme. Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ? Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques. la première concerne le besoin : en AVC l'encodage est relativement rapide sur une machine moderne (x4), un peu plus long pour du HEVC (x1). tu bosses probablement pour une chaine de TV. avez-vous vraiment besoin d'encoder si rapidement ?
ce serait inovant
si le proc est multicore, ffmpeg peut fonctionner en multi-threads.
c'est le cas pas defaut, mais chaques codec a ensuite ses propres limites en nombre de threads simultanés, on dispose de machines Xeon avec plusieurs dizaines de coeurs, même en forçant le nombre les librairies avc et hevc ffmpeg n'exploitent qu'une partie des pcocs, du coup avec l'encodage en ferme on a un produit disposant d'un rapport efficacité/cout assez surprenant.
et l'encodage matériel avec une carte graphique un peu costaude...? la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent galéré pour finir en général à la main avec MKVToolnix. quant au son c'est pareil, ça peut être casse gueule (pb synchro si une trame manque,...)
merci pour le retour
bref, la mise en place du workflow n'est pas évidente, alors qu'avec un encodage image + son sur une seule machine rapaide...
l'innovant n'a jamais rien eu d'évident :-) disons qu'on se garde ça sous le coude... -- Mail .invalid
Olivier B.
On Wed, 29 Jul 2020 11:23:18 +0200, jdd wrote:
Le 29/07/2020 à 11:10, Alf92 a écrit :
jdd (le 29/07/2020 à 08:32:44) :
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible qu'aujourd'hui
en même temps nous ne connaissons rien des besoins d'Olivier... j'ai déjà entendu dire que la vidéo surveillance était gourmande, mais déjà si je pouvais mettre mes propres ordis en grappe pour gérer mes vidéos, ce serait bien - mais j'ai la flemme d'étudier la config. en ce moment, sur mon portable, j'ai régulièrement des baisses de vitesse proc pour surchauffe en moulinant mes vidéos (normalisation des archives)
Et quand les archives des clients représentes des centaines de To ça commence à faire ;-) -- Mail .invalid
On Wed, 29 Jul 2020 11:23:18 +0200, jdd <jdd@dodin.org> wrote:
Le 29/07/2020 à 11:10, Alf92 a écrit :
jdd (le 29/07/2020 à 08:32:44) :
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de
cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible
qu'aujourd'hui
en même temps nous ne connaissons rien des besoins d'Olivier...
j'ai déjà entendu dire que la vidéo surveillance était gourmande, mais
déjà si je pouvais mettre mes propres ordis en grappe pour gérer mes
vidéos, ce serait bien - mais j'ai la flemme d'étudier la config.
en ce moment, sur mon portable, j'ai régulièrement des baisses de
vitesse proc pour surchauffe en moulinant mes vidéos (normalisation des
archives)
Et quand les archives des clients représentes des centaines de To ça
commence à faire ;-)
je n'avais pas entendu parler de "ferme d'encodage" depuis l'ancêtre de cinelerra, il doit y avoir 15 ans :-))
il y a 15 ans ça se justifiait : puissance de calcul bcp plus faible qu'aujourd'hui
en même temps nous ne connaissons rien des besoins d'Olivier... j'ai déjà entendu dire que la vidéo surveillance était gourmande, mais déjà si je pouvais mettre mes propres ordis en grappe pour gérer mes vidéos, ce serait bien - mais j'ai la flemme d'étudier la config. en ce moment, sur mon portable, j'ai régulièrement des baisses de vitesse proc pour surchauffe en moulinant mes vidéos (normalisation des archives)
Et quand les archives des clients représentes des centaines de To ça commence à faire ;-) -- Mail .invalid
Alf92
Olivier B. (le 24/08/2020 à 15:20:41) :
On Wed, 29 Jul 2020 11:07:08 +0200, Alf92 wrote:
Olivier B. (le 28/07/2020 à 22:37:02) :
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG", potentiellement je peux activer des clients sur des centaines de machine, mais chaque fichier est confronté à une limite incompressible liée à sont affectation sur une machine. Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme. Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ? Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques. la première concerne le besoin : en AVC l'encodage est relativement rapide sur une machine moderne (x4), un peu plus long pour du HEVC (x1). tu bosses probablement pour une chaine de TV. avez-vous vraiment besoin d'encoder si rapidement ?
ce serait inovant
si le proc est multicore, ffmpeg peut fonctionner en multi-threads.
c'est le cas pas defaut, mais chaques codec a ensuite ses propres limites en nombre de threads simultanés, on dispose de machines Xeon avec plusieurs dizaines de coeurs, même en forçant le nombre les librairies avc et hevc ffmpeg n'exploitent qu'une partie des pcocs, du coup avec l'encodage en ferme on a un produit disposant d'un rapport efficacité/cout assez surprenant.
et l'encodage matériel avec une carte graphique un peu costaude...? la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent galéré pour finir en général à la main avec MKVToolnix. quant au son c'est pareil, ça peut être casse gueule (pb synchro si une trame manque,...)
merci pour le retour
bref, la mise en place du workflow n'est pas évidente, alors qu'avec un encodage image + son sur une seule machine rapaide...
l'innovant n'a jamais rien eu d'évident :-) disons qu'on se garde ça sous le coude...
https://tech.showmax.com/2019/01/divide-encode-1/
Olivier B. (le 24/08/2020 à 15:20:41) :
On Wed, 29 Jul 2020 11:07:08 +0200, Alf92 <alf921@gmail.com> wrote:
Olivier B. (le 28/07/2020 à 22:37:02) :
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG",
potentiellement je peux activer des clients sur des centaines de
machine, mais chaque fichier est confronté à une limite incompressible
liée à sont affectation sur une machine.
Pour optimiser je pense àmodifier le moteur de workflow pour qu'il
c'ée des jobs d'encodage partiels distribués sur différentes machines,
par exemple
job1 de 00:00:00:00 à 00:00:59:24 --> PC1
job2 de 00:01:00:00 à 00:01:59:24 --> PC2
...
jobx de xx:xx:00:00 à la fin du fichier --> PCx
Ensuiteune fois toutes les parties codées un dernier job de
concaténation/remux réassemble le tout, l'optimisation serait énorme.
Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC
ou HEVC ?
Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques.
la première concerne le besoin : en AVC l'encodage est relativement rapide
sur une machine moderne (x4), un peu plus long pour du HEVC (x1).
tu bosses probablement pour une chaine de TV.
avez-vous vraiment besoin d'encoder si rapidement ?
ce serait inovant
si le proc est multicore, ffmpeg peut fonctionner en multi-threads.
c'est le cas pas defaut, mais chaques codec a ensuite ses propres
limites en nombre de threads simultanés, on dispose de machines Xeon
avec plusieurs dizaines de coeurs, même en forçant le nombre les
librairies avc et hevc ffmpeg n'exploitent qu'une partie des pcocs, du
coup avec l'encodage en ferme on a un produit disposant d'un rapport
efficacité/cout assez surprenant.
et l'encodage matériel avec une carte graphique un peu costaude...?
la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent
galéré pour finir en général à la main avec MKVToolnix.
quant au son c'est pareil, ça peut être casse gueule (pb synchro si une
trame manque,...)
merci pour le retour
bref, la mise en place du workflow n'est pas évidente, alors qu'avec un
encodage image + son sur une seule machine rapaide...
Dans ma boite oOn fait de l'encodage en "ferme FFMPEG", potentiellement je peux activer des clients sur des centaines de machine, mais chaque fichier est confronté à une limite incompressible liée à sont affectation sur une machine. Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme. Quelqu'un ici aurait-il tenté ce type de connfiguration avec le l'AVC ou HEVC ? Pour le son, une seule passe serait faite.
aucune idée de la solution mais 2 remarques. la première concerne le besoin : en AVC l'encodage est relativement rapide sur une machine moderne (x4), un peu plus long pour du HEVC (x1). tu bosses probablement pour une chaine de TV. avez-vous vraiment besoin d'encoder si rapidement ?
ce serait inovant
si le proc est multicore, ffmpeg peut fonctionner en multi-threads.
c'est le cas pas defaut, mais chaques codec a ensuite ses propres limites en nombre de threads simultanés, on dispose de machines Xeon avec plusieurs dizaines de coeurs, même en forçant le nombre les librairies avc et hevc ffmpeg n'exploitent qu'une partie des pcocs, du coup avec l'encodage en ferme on a un produit disposant d'un rapport efficacité/cout assez surprenant.
et l'encodage matériel avec une carte graphique un peu costaude...? la seconde : la concaténation n'est pas le fort de ffmpeg, j'ai souvent galéré pour finir en général à la main avec MKVToolnix. quant au son c'est pareil, ça peut être casse gueule (pb synchro si une trame manque,...)
merci pour le retour
bref, la mise en place du workflow n'est pas évidente, alors qu'avec un encodage image + son sur une seule machine rapaide...
l'innovant n'a jamais rien eu d'évident :-) disons qu'on se garde ça sous le coude...
Evidement, mais ça ne m'avance guère... -- Mail .invalid
Olivier B.
On Tue, 28 Jul 2020 22:37:02 +0200, Olivier B. wrote:
Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme.
bon les premiers tests sur un clim musical timecodé dans l'image sont probants en lecture vlc et ffplay tant en H264 qu'en HEVC, le seul problème a concerné l'intégrité du son à l'issu du concat, quasiment toujours un gap plus ou moins audible aux points de jonction, l'usage du PCM a réglé le problème j'imagine donc que le soucis se trouve dans la constituion des trames audio, ceci dit je ne comptais ne faire qu'une passe pour intégrer l'audio après le concat... reste donc à tester sur des fichiers de quelques heures, et avec une seule passe/remux audio.. les deux fichiers d'encodage/concaténation </ffcod_multipart.cmd> set file=original_timecode.mkv set acodec=pcm_u8 set vcodec=libx265 ffmpeg.exe -y -ss 00:00:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p0.mkv ffmpeg.exe -y -ss 00:00:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p1.mkv ffmpeg.exe -y -ss 00:01:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p2.mkv ffmpeg.exe -y -ss 00:01:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p3.mkv ffmpeg.exe -y -ss 00:02:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p4.mkv ffmpeg.exe -y -ss 00:02:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p5.mkv ffmpeg.exe -y -ss 00:03:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p6.mkv ffmpeg.exe -y -ss 00:03:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p7.mkv ffmpeg -y -f concat -safe 0 -i mylist.txt -c copy multipart_output.mkv </ffcod_multipart.cmd> <mylist.txt> file out_p0.mkv file out_p1.mkv file out_p2.mkv file out_p3.mkv file out_p4.mkv file out_p5.mkv file out_p6.mkv file out_p7.mkv </mylist.txt> -- Mail .invalid
On Tue, 28 Jul 2020 22:37:02 +0200, Olivier B.
<olivier.2a@free.invalid> wrote:
Pour optimiser je pense àmodifier le moteur de workflow pour qu'il
c'ée des jobs d'encodage partiels distribués sur différentes machines,
par exemple
job1 de 00:00:00:00 à 00:00:59:24 --> PC1
job2 de 00:01:00:00 à 00:01:59:24 --> PC2
...
jobx de xx:xx:00:00 à la fin du fichier --> PCx
Ensuiteune fois toutes les parties codées un dernier job de
concaténation/remux réassemble le tout, l'optimisation serait énorme.
bon les premiers tests sur un clim musical timecodé dans l'image sont
probants en lecture vlc et ffplay tant en H264 qu'en HEVC, le seul
problème a concerné l'intégrité du son à l'issu du concat, quasiment
toujours un gap plus ou moins audible aux points de jonction, l'usage
du PCM a réglé le problème j'imagine donc que le soucis se trouve dans
la constituion des trames audio, ceci dit je ne comptais ne faire
qu'une passe pour intégrer l'audio après le concat...
reste donc à tester sur des fichiers de quelques heures, et avec une
seule passe/remux audio..
les deux fichiers d'encodage/concaténation
</ffcod_multipart.cmd>
set file=original_timecode.mkv
set acodec=pcm_u8
set vcodec=libx265
On Tue, 28 Jul 2020 22:37:02 +0200, Olivier B. wrote:
Pour optimiser je pense àmodifier le moteur de workflow pour qu'il c'ée des jobs d'encodage partiels distribués sur différentes machines, par exemple job1 de 00:00:00:00 à 00:00:59:24 --> PC1 job2 de 00:01:00:00 à 00:01:59:24 --> PC2 ... jobx de xx:xx:00:00 à la fin du fichier --> PCx Ensuiteune fois toutes les parties codées un dernier job de concaténation/remux réassemble le tout, l'optimisation serait énorme.
bon les premiers tests sur un clim musical timecodé dans l'image sont probants en lecture vlc et ffplay tant en H264 qu'en HEVC, le seul problème a concerné l'intégrité du son à l'issu du concat, quasiment toujours un gap plus ou moins audible aux points de jonction, l'usage du PCM a réglé le problème j'imagine donc que le soucis se trouve dans la constituion des trames audio, ceci dit je ne comptais ne faire qu'une passe pour intégrer l'audio après le concat... reste donc à tester sur des fichiers de quelques heures, et avec une seule passe/remux audio.. les deux fichiers d'encodage/concaténation </ffcod_multipart.cmd> set file=original_timecode.mkv set acodec=pcm_u8 set vcodec=libx265 ffmpeg.exe -y -ss 00:00:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p0.mkv ffmpeg.exe -y -ss 00:00:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p1.mkv ffmpeg.exe -y -ss 00:01:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p2.mkv ffmpeg.exe -y -ss 00:01:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p3.mkv ffmpeg.exe -y -ss 00:02:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p4.mkv ffmpeg.exe -y -ss 00:02:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p5.mkv ffmpeg.exe -y -ss 00:03:00.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p6.mkv ffmpeg.exe -y -ss 00:03:30.000 -t 30 -i %file% -vcodec %vcodec% -preset ultrafast -acodec %acodec% out_p7.mkv ffmpeg -y -f concat -safe 0 -i mylist.txt -c copy multipart_output.mkv </ffcod_multipart.cmd> <mylist.txt> file out_p0.mkv file out_p1.mkv file out_p2.mkv file out_p3.mkv file out_p4.mkv file out_p5.mkv file out_p6.mkv file out_p7.mkv </mylist.txt> -- Mail .invalid
