Ai-je oublié un paramètre de temporisation dans FFMPEG ?

Question

Je lance une commande ffmpeg comme ceci :

ffmpeg -loglevel quiet -report -timelimit 15 -timeout 10 -protocol_whitelist file,http,https,tcp,tls,crypto -i ${inputFile} -vframes 1 ${outputFile} -y

Cette opération s'exécute dans une fonction AWS Lambda. Mon délai d'attente Lambda est de 30 secondes. Pour une raison quelconque, je reçois toujours des messages "Task timed out". Je dois noter que j'enregistre avant et après la commande, donc je sais que le délai d'attente est dépassé pendant cette tâche.

Mise à jour

En ce qui concerne l'exécution complète de la lambda, je procède comme suit :

• Invoquer une lambda pour obtenir un jeton d'accès. Cette lambda effectue une demande d'API. Le délai d'attente est de 5 secondes. Le temps maximum était de 660MS pour une requête.

• Effectuez une autre demande d'API pour vérifier les données. Le temps maximum était de 1,6 secondes.

• Exécuter FFMPEG

timelimit est censé Exit after ffmpeg has been running for duration seconds in CPU user time. . Théoriquement, cette opération ne devrait pas durer plus de 15 secondes, plus peut-être 2 ou 3 secondes avant les autres demandes.

timeout est probablement superflu ici. Il y avait beaucoup de définitions dans le manuel, mais je pense que c'était surtout en attente de données ? Quoi qu'il en soit, je pense que timelimit couvrirait mes arrières.

Mise à jour 2

J'ai vérifié mon journal de débogage et j'ai vu ceci :

Reading option '-timelimit' ... matched as option 'timelimit' (set max runtime in seconds) with argument '15'.
Reading option '-timeout' ... matched as AVOption 'timeout' with argument '10'.

Il semble que les deux options soient supportées par ma version

Mise à jour 2

J'ai mis à jour mon code avec beaucoup de logs. Je vois définitivement la commande FFMPEG comme la dernière chose qui s'exécute, avant de s'arrêter pour le délai de 30 secondes.

Mise à jour 3 Je peux reproduire le comportement en pointant une piste au lieu du manifeste complet. J'ai défini la commande comme suit :

ffmpeg -loglevel debug -timelimit 5 -timeout 5 -i 'https://streamprod-eastus-streamprodeastus-usea.streaming.media.azure.net/0c495135-95fa-48ec-a258-4ba40262e1be/23ab167b-9fec-439e-b447-d355ff5705df.ism/QualityLevels(200000)/Manifest(video,format=m3u8-aapl)' -vframes 1 temp.jpg -y

Quelques éléments à ce sujet :

1. Je pointe généralement le manifeste (et non la piste), et les choses se déroulent généralement beaucoup plus rapidement.
2. J'ai abaissé le timelimit y timeout à 5. Malgré cela, lorsque je lance un timer, la commande s'exécute pendant ~15 secondes à chaque fois. Elle génère un tas d'erreurs, probablement dues au fait qu'il s'agit d'une piste plutôt que d'un manifeste complet, puis recrache l'image désirée.

La pleine puissance est à https://gist.github.com/DaveStein/b3803f925d64dd96cd45ae9db5e5a4d0

Answer 1

timelimit est censé Exit after FFmpeg has been running for duration seconds in CPU user time .

C'est vrai, mais vous ne pouvez pas utiliser cette métrique temporelle pour déterminer quand FFmpeg doit être quitté de force pendant son fonctionnement (Voir aquí ).

Le mieux est de surveiller le processus de l'extérieur et de le tuer de force en envoyant un TERM o KILL signal.

Je recommande le timeout qui fait partie des coreutils GNU.

En voici un exemple

timeout 14s -t 1s <FFMPEG COMMAND LINE>

Cela garantit que l'exécution de la commande FFmpeg dure jusqu'à 14 secondes et la force à être tuée ( SIGKILL ) une seconde après, au cas où il ne se serait pas arrêté avec la touche SIGTERM signal.

Vous pouvez consulter les pages de manuel de l'outil délai d'attente commande.

Answer 2

Vous pouvez essayer ces choses :

1. augmenter la limite de temps de votre fonction lambda.
2. augmenter l'allocation de mémoire à votre fonction lambda. Cela accélère votre fonction lambda.
3. Si vous obtenez toujours un timeout, vérifiez RequestTimeout et ConnectionTimeout de votre fonction lambda.