Forum

Bonjour,
yt-dlp nécessite désormais un environnement d'exécution JavaScript externe pour prendre entièrement en charge YouTube. Plus d'informations ici
https://github.com/yt-dlp/yt-dlp/issues/15012
Cette information s'adresse aussi bien aux développeurs qu'aux utilisateurs.

Brève synthèse de notre discussion :

Pour une prise en charge complète de YouTube (afin que tous les formats puissent être téléchargés depuis YouTube), installez yt-dlp et l’un des environnements d’exécution JavaScript :

ou

(quickjs n’est disponible que dans Cauldron/Mageia 10+, il exécute le JavaScript un peu plus lentement, mais occupe très peu d’espace disque).

Ajoutez ensuite dans les options de ligne de commande de yt-dlp :

ou


Pour éviter d’avoir à saisir ces options chaque fois, ajoutez-les dans ~/.config/yt-dlp/config.
Créez le dossier yt-dlp puis le fichier config sans extension, et placez chaque option sur une nouvelle ligne, par exemple :

Édité par deniums Le 18/11/2025 à 18h39

Bonjour,
Il me semble que nous disposons de nodejs. Les autres ne sont pas packagés.
J'ai regardé quickjs. Je n'arrive pas à le compiler, en partant d'un spec sur openbuild.
Les autres ne n'inspirent pas : l'un en rust, l'autre à la mode webkit.

Salut,
nodejs est le meilleur choix dans ce cas. Mais il nécessite l'option de ligne de commande yt-dlp --js-runtimes node.
quickjs fonctionne 3 à 4 fois plus longtemps (9s vs 2s), et quickjs-ng 25 minutes ! (exécution js)

Je pense qu'il vaut mieux faire de nodejs une dépendance recommandée (optional) et ajouter --js-runtimes node aux drapeaux par défaut (~/.config/yt-dlp/config)

Mais l'avantage de quickjs est la petite taille du fichier exécutable. Vous pouvez même en faire une dépendance obligatoire pour cette raison.

L'avantage de Deno est qu'il est recommandé et utilisé par défaut (sans drapeaux de ligne de commande supplémentaires). Mais Deno ne prend en charge que x64, bien qu'il puisse être compilé pour i686, peut-être.

J'ai un paquet construit pour quickjs-ng.
@ deniums : Voudrais-tu le tester ? Je peux le mettre sur les dépôts MLO. En quelle architecture ?
Quelle procédure de test aboutit aux résultats que tu cites ?

Je pourrais tester x86_64. Mais j'ai entendu dire que quickjs-ng était extrêmement lent.
quickjs (sans ng) est beaucoup plus optimisé. Je le recommanderais plutôt que quickjs-ng.

J'ai compilé quickjs et quickjs-ng et je n'ai rencontré aucun problème de compilation.
Papoteur, essaie également de compiler quickjs. Je vais le tester. Mais je peux aussi tester quickjs-ng, même si ce n'est probablement pas un bon choix.

Temps passé par les moteurs JS sur mon ordinateur pour télécharger une vidéo YouTube :
deno, node 2-4 secondes
quickjs 9 secondes
quickjs-ng >40 minutes (valeur exacte inconnue, j'ai annulé le téléchargement après 40 minutes. J'ai entendu dire que cela prenait 25 minutes pour certains utilisateurs)

edit: quickjs-ng effectue des calculs pendant 10 minutes sur un processeur AMD Ryzen 9 7950X3D

Édité par deniums Le 14/11/2025 à 17h41

deniums :

Temps passé par les moteurs JS sur mon ordinateur pour télécharger une vidéo YouTube :
deno, node 2-4 secondes
quickjs 9 secondes
quickjs-ng >40 minutes (valeur exacte inconnue, j'ai annulé le téléchargement après 40 minutes. J'ai entendu dire que cela prenait 25 minutes pour certains utilisateurs)

OK, je m'abstiens pour quickjs-ng, comme la motivation principale est yt-dlp, ça n'a pas d'intérêt pour l'instant.
La compilation de quickjs-ng utilise cmake et ça passe tout seul. Par contre, celle de quickjs utilise make et échoue à l'édition de lien dans la construction du paquet.

Compilation OK sur les machines Debian. Essaie de cloner ce dépôt https://github.com/bellard/quickjs Le projet a une seule dépendance : glibc-dev.
yt-dlp utilise le fichier qjs.
yt-dlp config : --js-runtimes quickjs

Édité par deniums Le 14/11/2025 à 19h04

Dans Alpine x86 Musl, quicksjs se compile également avec succès. Papoteur, quelle erreur apparaît lors du « Link time » ?
Peut-être faudrait-il désactiver LTO ou installer glibc-static-dev ?

Bonjour,
J'utilise la version 2025-09-13
Voici l'erreur pour Cauldron:

Bon, le paquet quickjs est importé dans Cauldron.

La compilation a réussi dans mon Cauldron Desktop.
ChatGPT a dit que la raison était --no-undefined.
Et en effet, si j'ajoute :
export LDFLAGS='-Wl,--no-undefined'
ou
export LDFLAGS='-Wl,--undefined', une erreur se produit.
Le système de compilation contient des drapeaux supplémentaires qui font échouer la compilation.

Oh, je vois que tu as réussi à résoudre le problème.
Merci.

Édité par deniums Le 15/11/2025 à 15h30

deniums :

ChatGPT a dit que la raison était --no-undefined.
Le système de compilation contient des drapeaux supplémentaires qui font échouer la compilation.

Oh, je vois que tu as réussi à résoudre le problème.
Merci.

Exact. J'ai utilisé un moyen de contournement qui désactive ce flag.
Wally n'est pas satisfait, il aurait trouvé une correction, mais là, c'est au-delà de mes compétences. Je n'ai pas encore vu comment il compte faire.

J'ai testé. yt-dlp du dépôt Cauldron ne contient pas le composant ejs (alors que les versions officielles de yt-dlp le contiennent). C'est pourquoi j'obtiens l'erreur suivante :

Citation :

WARNING: [youtube] [jsc] Remote component challenge solver script (quickjs) was skipped. It may be required to solve JS challenges. You can enable the download with --remote-components ejs:github (recommended). For more information and alternatives, refer to https://github.com/yt-dlp/yt-dlp/wiki/EJS
WARNING: [youtube]: n challenge solving failed: Some formats may be missing. Ensure you have a supported JavaScript runtime and challenge solver script distribution installed. Review any warnings presented before this message. For more details, refer to https://github.com/yt-dlp/yt-dlp/wiki/EJS
ERROR: [youtube]: Requested format is not available. Use --list-formats for a list of available formats

Il faut donc ajouter une deuxième option :


Voici donc les commandes :


Lorsque EJS sera ajouté à yt-dlp dans Mageia, la deuxième option ne sera plus nécessaire.