FFMPEG Encodage massivement parallèle par segments/réassemblage

Le
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 ?

Pour le son, une seule passe serait faite.

Mreci

--
Mail .invalid
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
jdd
Le #26552134
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 :-))
bravo :-)
jdd
--
http://dodin.org
Alf92
Le #26552144
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...
Alf92
Le #26552143
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 #26552145
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
Olivier B.
Le #26553314
On Wed, 29 Jul 2020 11:07:08 +0200, 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 ?

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.
Le #26553313
On Wed, 29 Jul 2020 11:23:18 +0200, 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)

Et quand les archives des clients représentes des centaines de To ça
commence à faire ;-)
--
Mail .invalid
Alf92
Le #26553442
Olivier B. (le 24/08/2020 à 15:20:41) :
On Wed, 29 Jul 2020 11:07:08 +0200, 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 ?

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/
jdd
Le #26553449
Le 27/08/2020 à 01:19, Alf92 a écrit :
https://tech.showmax.com/2019/01/divide-encode-1/

intéressant :-)
jdd
--
http://dodin.org
Olivier B.
Le #26553500
On Thu, 27 Aug 2020 07:54:29 +0200, jdd
Le 27/08/2020 à 01:19, Alf92 a écrit :
https://tech.showmax.com/2019/01/divide-encode-1/

intéressant :-)

Evidement, mais ça ne m'avance guère...
--
Mail .invalid
Olivier B.
Le #26555194
On Tue, 28 Jul 2020 22:37:02 +0200, Olivier B.
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
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
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

--
Mail .invalid
Poster une réponse
Anonyme