yt-dlp: पूरे YouTube सपोर्ट के लिए अब बाहरी JavaScript runtime अनिवार्य

• yt-dlp एक command-line आधारित डाउनलोड टूल है, जो हजारों साइटों से audio और video डाउनलोड कर सकता है, और यह youtube-dl का fork version है
• YouTube के n/sig decryption के लिए नए जोड़े गए yt-dlp-ejs मॉड्यूल के साथ बाहरी JavaScript runtime (जैसे Deno, Node.js, Bun, QuickJS) की आवश्यकता है
• Deno को default runtime के रूप में सेट किया गया है, और उपयोगकर्ता --js-runtimes विकल्प से कोई दूसरा runtime चुन सकते हैं
• इस बदलाव के बाद YouTube से जुड़े फीचर्स का पूरा उपयोग करने के लिए yt-dlp-ejs और JS runtime की installation अनिवार्य है
• बाहरी runtime dependency जोड़ना YouTube की encryption structure में बदलावों के जवाब में उठाया गया आवश्यक कदम है, और आगे maintenance का एक अहम हिस्सा होगा

---

yt-dlp अवलोकन

• yt-dlp, youtube-dl का एक fork है, और यह अब maintain न किए जाने वाले youtube-dlc पर आधारित project है
• यह हजारों वेबसाइटों से audio और video डाउनलोड कर सकता है, और कई तरह के format selection, post-processing, subtitles, plugin फीचर्स को सपोर्ट करता है

YouTube सपोर्ट से जुड़े बदलाव

• YouTube के n/sig values decryption के लिए yt-dlp-ejs package की आवश्यकता है
  • यह package Unlicense के तहत वितरित किया जाता है, और इसमें MIT तथा ISC license components शामिल हैं
• yt-dlp-ejs चलाने के लिए JavaScript runtime अनिवार्य है
  • समर्थित runtime: deno (अनुशंसित), node.js, bun, QuickJS
  • संबंधित सेटिंग --js-runtimes विकल्प से दी जा सकती है
• --no-js-runtimes विकल्प का उपयोग करने पर default runtime configuration को reset किया जा सकता है

installation और dependencies

• yt-dlp, Python 3.10+ (CPython) और 3.11+ (PyPy) versions को सपोर्ट करता है
• सख्ती से अनुशंसित dependencies:
  • ffmpeg / ffprobe: audio और video merge तथा post-processing के लिए
  • yt-dlp-ejs: YouTube encryption हटाने के लिए
  • JavaScript runtime: yt-dlp-ejs चलाने के लिए
• वैकल्पिक network dependencies में certifi, brotli, requests, curl_cffi आदि शामिल हैं

मुख्य command options

• --js-runtimes RUNTIME[:PATH]: उपयोग किया जाने वाला JS runtime निर्दिष्ट करता है
• --no-js-runtimes: सभी JS runtimes निष्क्रिय करता है
• --remote-components COMPONENT: बाहरी JS components की अनुमति देने वाला विकल्प
• --no-remote-components: remote components लोड होने से रोकता है

महत्व

• इस बदलाव के साथ yt-dlp को YouTube की नवीनतम encryption structure का पूरा सपोर्ट देने के लिए बाहरी JS runtime को अनिवार्य रूप से चाहिए
• यह YouTube के लगातार सुरक्षा और encryption updates के अनुरूप ढलने के लिए एक संरचनात्मक बदलाव है, और आने वाले maintenance तथा feature expansion के लिए एक महत्वपूर्ण परिवर्तन है

[kimjoin2]

वाह... रोकना भी कमाल है और उसे तोड़कर निकल जाना भी कमाल लगता है। पता नहीं इसे कैसे analyze करके bypass करते होंगे।

[GN⁺]

Hacker News टिप्पणियाँ

• यह पहले से ही Arch रिपॉज़िटरी में शामिल है, इसलिए तुरंत काम करता है
  yt-dlp --cookies-from-browser firefox --remote-components ejs:github ... कमांड में बस फ्लैग जोड़ना होता है
  रन करते समय solver को runtime पर डाउनलोड करता है, और इसमें लगभग 0.5 सेकंड ही लगते हैं। डाउनलोड शुरू होने की स्पीड काफ़ी तेज़ लगी
  लेकिन सीमित environment में चलाते समय अच्छा होता अगर solver को पहले से किसी अलग कमांड से डाउनलोड किया जा सकता। अभी भी संतोषजनक है, लेकिन packaging automation हो जाए तो और सुविधाजनक होगा

  • स्पीड बढ़ी है, यह सुनकर अच्छा लगा। आजकल ब्राउज़र में भी YouTube ठीक से नहीं चलता, ऐसे में Python script के ज़रिए इसे accessible बनाए रखने वाली टीम कमाल की है
  • यह जानने की जिज्ञासा है कि कौन-से environment में Python चलता है लेकिन JS नहीं
    अगर security की चिंता है, तो Deno इस्तेमाल करने पर sandboxing काफ़ी अच्छी है
    अगर Deno या Node किसी OS पर supported नहीं हैं, तो C में लिखा QuickJS भी एक विकल्प हो सकता है। यह धीमा है, लेकिन लगभग हर environment में चलता है
    हालाँकि इस स्थिति में sandboxing नहीं रहती। फिर भी अगर कोड आधिकारिक YouTube domain से दिया जा रहा है, तो मुझे वह भरोसेमंद लगता है
  • अगर आप solver पहले से डाउनलोड करना चाहते हैं, तो कोई भी वीडियो एक बार डाउनलोड करने के बाद yt-dlp की cache directory (जैसे /home/username/.cache) से ejs फ़ाइल कॉपी कर सकते हैं
    या make yt-dlp-extra के साथ packaging automation आज़मा सकते हैं
  • AUR का yt-dlp-ejs package शायद ठीक इसी काम के लिए है
  • मैंने Deno को Chocolately से manually install किया था, और yt-dlp भी choco से install किया, इसलिए version v2025.10.22 है

• हाल में YouTube ने embedded videos के लिए referrer header अनिवार्य करना शुरू कर दिया है
  अगर सीधे youtube.com/embed/<videoid> पर जाएँ, तो error आता है, और FAQ में भी इसे intended policy बताया गया है
  आधिकारिक दस्तावेज़ के अनुसार, embed करने वाले को HTTP Referer देना होगा, नहीं तो “error 153” स्क्रीन दिखाई जाती है

  • ज़्यादातर embed services धीरे-धीरे इसी दिशा में जा रही हैं। इसका मकसद tracking बढ़ाना है। कुछ मामलों में तो login भी माँगा जाता है
  • सच कहें तो इसे एक साधारण JS redirector की एक लाइन से bypass किया जा सकता है। implementation cost लाखों डॉलर, और bypass cost शून्य। आख़िरकार यह “अगर हम चाहें तो कभी भी रोक सकते हैं” जैसा संदेश लगता है

• 1991 में जब QuickTime आया था, तब मुझे लगता था कि वीडियो भी बस कॉपी, पेस्ट और सेव करने की चीज़ है
  अब तो DRM न होने वाले वीडियो का भी user experience इतना ख़राब हो गया है कि यक़ीन नहीं होता

  • अभी का समय पहले से बहुत बेहतर है। पहले RealPlayer, Flash, codec packs वगैरह install करते-करते adware से सिस्टम खराब हो जाना आम बात थी।
    अब तो OS का default player या सिर्फ़ VLC से ज़्यादातर काम हो जाता है
  • 90 के शुरुआती दशक PC के लिए सबसे रोमांचक समय थे। अब smartphone मुख्यधारा बन चुके हैं, इसलिए आम users के लिए copy/save का concept बस screenshot या screen recording तक सीमित रह गया है
  • वीडियो में data density बहुत ज़्यादा होती है, इसलिए hosting cost भी बड़ी होती है। इसी वजह से YouTube जैसे बड़े platforms बचे हैं, और Nebula, PeerTube, Odysee जैसे alternatives quality या cost के मामले में सीमित हैं
  • पहले लक्ष्य user-केंद्रित optimization था, लेकिन अब दौर ऐसा है जहाँ कंपनियाँ अपने हित को प्राथमिकता देती हैं
  • ATSC 3 broadcast standard में भी DRM बाद में जोड़ा गया, जिससे पुराने receivers के incompatible हो जाने की समस्या आई

• मैं 2010 से yt-dlp (youtube-dl वाले दौर से) इस्तेमाल कर रहा हूँ और अपने सभी पसंदीदा वीडियो archive कर रहा हूँ
  अब मेरे पास दसियों हज़ार वीडियो संग्रहीत हैं, और उनमें से काफ़ी अब साइट से गायब हो चुके हैं
  NHK sumo highlights जैसे सिर्फ़ एक महीने के लिए उपलब्ध रहने वाले वीडियो भी मैं सेव करके रखता हूँ

  • इसे डिजिटल collector mentality कह सकते हैं। अगर Google Memories जैसी कोई सुविधा हो जो पुराने वीडियो समय-समय पर याद दिलाए, तो मज़ेदार होगा
  • कई बार channels खुद अपने वीडियो private या delete कर देते हैं, इसलिए अच्छा content गायब होने से पहले सेव करना शुरू किया
  • इंटरनेट पर हर चीज़ कभी भी गायब हो सकती है। अगर वह महत्वपूर्ण है, तो दोबारा देखने के लिए उसे खुद सेव करना होगा
  • यहाँ किसी और को sumo वीडियो सेव करते देखूँगा, यह सोचा नहीं था। हमारे जैसे लोग काफ़ी हैं
  • content की भरमार वाले दौर में क्या सच में सब कुछ सेव करने की ज़रूरत है? पहले मैं MP3 और फ़िल्में भी जमा करता था, लेकिन अब सिर्फ़ फ़ोटो cloud में रखता हूँ

• ad blocking और ad insertion की अनंत लड़ाई के बीच शायद आख़िरकार AGI/ASI आ ही जाए।
  दोनों पक्ष LLM इस्तेमाल करेंगे, और इंसान बीच में अपनी जेब और ध्यान दोनों खोता रहेगा

• 10 साल बाद शायद YouTube ब्राउज़र से पूरी तरह inaccessible हो जाए
  अगर tablet apps की आदी पीढ़ी मुख्यधारा बन गई, तो Google को web छोड़ने का आत्मविश्वास आ सकता है

  • सचमुच DRM लागू करना है, तो dedicated hardware चाहिए। encrypted stream सिर्फ़ L2-certified devices पर चलनी चाहिए
  • mobile web apps में bugs इतने ज़्यादा हैं कि वे लगभग इस्तेमाल लायक नहीं। comments भी अक्सर गायब हो जाते हैं
  • फिर भी Google ने हमेशा web-centric strategy बनाए रखी है
  • ब्राउज़र में YouTube देखने वाली पीढ़ी अब भी बहुत है, और चीन के bilibili जैसे alternatives भी मौजूद हैं
  • लेकिन खरीद क्षमता वाली पीढ़ी ब्राउज़र users की है, इसलिए Google शायद उस बाज़ार को पूरी तरह नहीं छोड़ेगा

• yt-dlp issue #14404 में Selenium या headless browser इस्तेमाल करने का सुझाव दिया गया था,
  लेकिन maintenance टीम ने जवाब दिया कि “वह हार मानने जैसा होगा और project की spirit के ख़िलाफ़ है”

• scraping सच में बहुत कठिन काम है। API बार-बार टूटती है, और provider हमें पसंद भी नहीं करता; फिर भी इसे बनाए रखना काबिल-ए-तारीफ़ है

  • “provider हमें पसंद नहीं करता” — शायद यही इस project की असली दिलचस्पी है
  • मैं तो कभी yt-dlp maintain नहीं कर पाता। यह बहुत थका देने वाला काम है

• साफ़ महसूस होता है कि YouTube का रुख़ users के प्रति ज़्यादा टकराव वाला होता जा रहा है
  ad blocker पर रोक, AI training के लिए content संग्रह, API restrictions — जैसे वह प्रतिस्पर्धा न होने का फ़ायदा उठा रहा हो

  • असल में Google का असली ग्राहक advertiser है। हम तो सिर्फ़ उनका product हैं
    advertiser की संतुष्टि को लेकर वे संवेदनशील हैं, लेकिन users और creators को consumable resource की तरह देखते हैं
    मुफ़्त सेवा से शुरू करके rivals को हटाना और फिर monopoly जैसी संरचना बनाना एक तरह की bait strategy थी।
    अब नए alternatives की ज़रूरत है। paid हो तो भी चलेगा, बस service transparent होनी चाहिए
  • आजकल ख़ासकर बच्चों के वीडियो में non-skippable ads बढ़ गए हैं
  • YouTube की operating cost इतनी बड़ी है कि ad blocking से service चलाए रखना प्रभावित हो सकता है
  • आख़िरकार आज का बदहाल UX (enshittification) खुद business model का हिस्सा बन गया है

• yt-dlp EJS wiki के अनुसार Deno को recommend करने की वजह यह है
  कि वह restricted permissions के साथ code execution की अनुमति देता है, और npm से EJS dependencies को remotely ला सकता है

  • लेकिन Deno की sandboxing को security mechanism मानकर ज़्यादा भरोसा नहीं करना चाहिए। runtime-level isolation कमज़ोर होती है,
    इसलिए Firecracker जैसी OS/VM-level isolation इस्तेमाल करना ज़्यादा सुरक्षित है
  • पहले yt-dlp केवल Python से JS interpret करता था, लेकिन runtime की माँगें जटिल होने के साथ उसके अपने interpreter की सीमाएँ साफ़ हो गईं