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 ?
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>
Les tests sur les gros fichiers ont donné quoi ? Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Le 27/09/2020 Í 16:28, Olivier B. a écrit :
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
Les tests sur les gros fichiers ont donné quoi ? Un problème potentiel
que je vois c'est que l'option "-ss" est dans certains cas (pas
toujours) bizarrement implémentée et qu'au lieu de sauter directement au
temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur
un fichier de quelques heures ça peut faire beaucoup de décodage
complètement inutile pour les segments loin dans la video...
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>
Les tests sur les gros fichiers ont donné quoi ? Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Olivier B.
On Wed, 11 Nov 2020 13:03:48 +0100, pehache wrote:
Les tests sur les gros fichiers ont donné quoi ?
c'est concluant :-)
Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option https://trac.ffmpeg.org/wiki/Seeking de ce que j'ai pu tester l'input seeking est plus rapide mais nécéssite des fichiers correctement indexés pour être frame accurate. -- Mail .invalid
On Wed, 11 Nov 2020 13:03:48 +0100, pehache <pehache.7@gmail.com>
wrote:
Les tests sur les gros fichiers ont donné quoi ?
c'est concluant :-)
Un problème potentiel
que je vois c'est que l'option "-ss" est dans certains cas (pas
toujours) bizarrement implémentée et qu'au lieu de sauter directement au
temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur
un fichier de quelques heures ça peut faire beaucoup de décodage
complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option
https://trac.ffmpeg.org/wiki/Seeking
de ce que j'ai pu tester l'input seeking est plus rapide mais
nécéssite des fichiers correctement indexés pour être frame accurate.
On Wed, 11 Nov 2020 13:03:48 +0100, pehache wrote:
Les tests sur les gros fichiers ont donné quoi ?
c'est concluant :-)
Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option https://trac.ffmpeg.org/wiki/Seeking de ce que j'ai pu tester l'input seeking est plus rapide mais nécéssite des fichiers correctement indexés pour être frame accurate. -- Mail .invalid
pehache
Le 12/11/2020 Í 23:38, Olivier B. a écrit :
On Wed, 11 Nov 2020 13:03:48 +0100, pehache wrote:
Les tests sur les gros fichiers ont donné quoi ?
c'est concluant :-)
Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option https://trac.ffmpeg.org/wiki/Seeking
Ah putain on en apprend tous les jours avec ffmpeg !! Mais pour le coup je ne comprends pas bien l'intérêt de l'output seeking... C'est juste que les timestamps sont conservés ?
Le 12/11/2020 Í 23:38, Olivier B. a écrit :
On Wed, 11 Nov 2020 13:03:48 +0100, pehache <pehache.7@gmail.com>
wrote:
Les tests sur les gros fichiers ont donné quoi ?
c'est concluant :-)
Un problème potentiel
que je vois c'est que l'option "-ss" est dans certains cas (pas
toujours) bizarrement implémentée et qu'au lieu de sauter directement au
temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur
un fichier de quelques heures ça peut faire beaucoup de décodage
complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option
https://trac.ffmpeg.org/wiki/Seeking
Ah putain on en apprend tous les jours avec ffmpeg !!
Mais pour le coup je ne comprends pas bien l'intérêt de l'output
seeking... C'est juste que les timestamps sont conservés ?
On Wed, 11 Nov 2020 13:03:48 +0100, pehache wrote:
Les tests sur les gros fichiers ont donné quoi ?
c'est concluant :-)
Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option https://trac.ffmpeg.org/wiki/Seeking
Ah putain on en apprend tous les jours avec ffmpeg !! Mais pour le coup je ne comprends pas bien l'intérêt de l'output seeking... C'est juste que les timestamps sont conservés ?
Olivier B.
On Fri, 13 Nov 2020 08:56:12 +0100, pehache wrote:
Le 12/11/2020 Í 23:38, Olivier B. a écrit :
Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option https://trac.ffmpeg.org/wiki/Seeking
Ah putain on en apprend tous les jours avec ffmpeg !! Mais pour le coup je ne comprends pas bien l'intérêt de l'output seeking... C'est juste que les timestamps sont conservés ?
lÍ j'avoue que je ne maitrise pas, du peu que j'ai gratté j'ai compris ceci: l'output travaillerait au niveau flux (du coup ça décode Í minima) et permetrait d'être frame accurate sur des medias qui ne sont pas correctement indexés (y'a peut être un lien avec les timestamp), l'input seeking travaillierait au niveau fichier se basant sur le bitrate pour tomber plus ou moins au bon endroit (surtout moins en cas de VBR), mais beaucoup plus rapidement. Comme je travaille avec un format pivot MXF, j'utilise l'input, je suis sÍ»r que le comportement ne changera pas :-) -- Mail .invalid
On Fri, 13 Nov 2020 08:56:12 +0100, pehache <pehache.7@gmail.com>
wrote:
Le 12/11/2020 Í 23:38, Olivier B. a écrit :
Un problème potentiel
que je vois c'est que l'option "-ss" est dans certains cas (pas
toujours) bizarrement implémentée et qu'au lieu de sauter directement au
temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur
un fichier de quelques heures ça peut faire beaucoup de décodage
complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option
https://trac.ffmpeg.org/wiki/Seeking
Ah putain on en apprend tous les jours avec ffmpeg !!
Mais pour le coup je ne comprends pas bien l'intérêt de l'output
seeking... C'est juste que les timestamps sont conservés ?
lÍ j'avoue que je ne maitrise pas, du peu que j'ai gratté j'ai compris
ceci: l'output travaillerait au niveau flux (du coup ça décode Í
minima) et permetrait d'être frame accurate sur des medias qui ne sont
pas correctement indexés (y'a peut être un lien avec les timestamp),
l'input seeking travaillierait au niveau fichier se basant sur le
bitrate pour tomber plus ou moins au bon endroit (surtout moins en cas
de VBR), mais beaucoup plus rapidement.
Comme je travaille avec un format pivot MXF, j'utilise l'input, je
suis sͻr que le comportement ne changera pas :-)
On Fri, 13 Nov 2020 08:56:12 +0100, pehache wrote:
Le 12/11/2020 Í 23:38, Olivier B. a écrit :
Un problème potentiel que je vois c'est que l'option "-ss" est dans certains cas (pas toujours) bizarrement implémentée et qu'au lieu de sauter directement au temps spécifié, ffmpeg décode tout ce qu'il y a avant ce temps. Donc sur un fichier de quelques heures ça peut faire beaucoup de décodage complètement inutile pour les segments loin dans la video...
Le comportement dépend du positionnement de l'option https://trac.ffmpeg.org/wiki/Seeking
Ah putain on en apprend tous les jours avec ffmpeg !! Mais pour le coup je ne comprends pas bien l'intérêt de l'output seeking... C'est juste que les timestamps sont conservés ?
lÍ j'avoue que je ne maitrise pas, du peu que j'ai gratté j'ai compris ceci: l'output travaillerait au niveau flux (du coup ça décode Í minima) et permetrait d'être frame accurate sur des medias qui ne sont pas correctement indexés (y'a peut être un lien avec les timestamp), l'input seeking travaillierait au niveau fichier se basant sur le bitrate pour tomber plus ou moins au bon endroit (surtout moins en cas de VBR), mais beaucoup plus rapidement. Comme je travaille avec un format pivot MXF, j'utilise l'input, je suis sÍ»r que le comportement ne changera pas :-) -- Mail .invalid
