12 คะแนน โดย GN⁺ 2025-11-13 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • yt-dlp เป็น เครื่องมือดาวน์โหลดแบบบรรทัดคำสั่ง ที่สามารถดาวน์โหลดไฟล์เสียงและวิดีโอจากเว็บไซต์นับพันแห่ง และเป็นเวอร์ชันฟอร์กของ youtube-dl
  • จำเป็นต้องมี JavaScript runtime ภายนอก (เช่น Deno, Node.js, Bun, QuickJS) ร่วมกับโมดูล yt-dlp-ejs ที่เพิ่มเข้ามาใหม่ เพื่อใช้สำหรับ ถอดรหัส n/sig ของ YouTube
  • ตั้งค่า Deno เป็น runtime เริ่มต้น และผู้ใช้สามารถระบุ runtime อื่นได้ผ่านตัวเลือก --js-runtimes
  • การเปลี่ยนแปลงนี้ทำให้การใช้งานฟีเจอร์ที่เกี่ยวข้องกับ YouTube ได้อย่างครบถ้วนจำเป็นต้อง ติดตั้ง yt-dlp-ejs และ JS runtime
  • การเพิ่มการพึ่งพา runtime ภายนอกเป็น มาตรการจำเป็นเพื่อรับมือกับการเปลี่ยนแปลงโครงสร้างการเข้ารหัสของ YouTube และจะเป็นองค์ประกอบสำคัญของการบำรุงรักษาในอนาคต

ภาพรวมของ yt-dlp

  • yt-dlp เป็นฟอร์กของ youtube-dl และเป็นโปรเจกต์ที่พัฒนาต่อยอดจาก youtube-dlc ซึ่งไม่ได้รับการดูแลแล้ว
  • สามารถดาวน์โหลดเสียงและวิดีโอจากเว็บไซต์นับพันแห่ง และรองรับฟีเจอร์หลากหลาย เช่น การเลือกฟอร์แมต การประมวลผลภายหลัง ซับไตเติล และปลั๊กอิน

การเปลี่ยนแปลงที่เกี่ยวข้องกับการรองรับ YouTube

  • ต้องใช้แพ็กเกจ yt-dlp-ejs เพื่อ ถอดรหัสค่า n/sig ของ YouTube
    • แพ็กเกจนี้เผยแพร่ภายใต้ Unlicense และมีส่วนประกอบที่ใช้ไลเซนส์ MIT และ ISC
  • การรัน yt-dlp-ejs จำเป็นต้องมี JavaScript runtime
    • runtime ที่รองรับ: deno (แนะนำ), node.js, bun, QuickJS
    • สามารถกำหนดค่าที่เกี่ยวข้องได้ผ่านตัวเลือก --js-runtimes
  • สามารถใช้ตัวเลือก --no-js-runtimes เพื่อรีเซ็ตการตั้งค่า runtime เริ่มต้นได้

การติดตั้งและการพึ่งพา

  • yt-dlp รองรับ Python 3.10+ (CPython) และ 3.11+ (PyPy)
  • การพึ่งพาที่แนะนำอย่างยิ่ง:
    • ffmpeg / ffprobe: สำหรับรวมไฟล์เสียงและวิดีโอ รวมถึงการประมวลผลภายหลัง
    • yt-dlp-ejs: สำหรับถอดรหัสการเข้ารหัสของ YouTube
    • JavaScript runtime: สำหรับรัน yt-dlp-ejs
  • การพึ่งพาด้านเครือข่ายแบบทางเลือกมี certifi, brotli, requests, curl_cffi เป็นต้น

ตัวเลือกคำสั่งหลัก

  • --js-runtimes RUNTIME[:PATH]: ระบุ JS runtime ที่จะใช้
  • --no-js-runtimes: ปิดใช้งาน JS runtime ทั้งหมด
  • --remote-components COMPONENT: ตัวเลือกที่อนุญาตให้ใช้คอมโพเนนต์ JS ภายนอก
  • --no-remote-components: บล็อกการโหลดคอมโพเนนต์จากระยะไกล

ความสำคัญ

  • การเปลี่ยนแปลงครั้งนี้ทำให้ yt-dlp จำเป็นต้องใช้ JS runtime ภายนอกเพื่อรองรับโครงสร้างการเข้ารหัสล่าสุดของ YouTube ได้อย่างสมบูรณ์
  • นี่เป็นการเปลี่ยนผ่านเชิงโครงสร้างเพื่อรับมือกับการอัปเดตด้านความปลอดภัยและการเข้ารหัสอย่างต่อเนื่องของ YouTube และเป็น การเปลี่ยนแปลงสำคัญต่อการบำรุงรักษาและการขยายฟีเจอร์ในอนาคต

2 ความคิดเห็น

 
kimjoin2 2025-11-14

ว้าว... ทั้งการปิดกั้นก็น่าทึ่ง และการฝ่ามันไปได้ก็น่าทึ่งเหมือนกันนะ คงวิเคราะห์และเจาะผ่านมันได้ยังไงกันนะ

 
GN⁺ 2025-11-13
ความคิดเห็นจาก Hacker News
  • มีรวมอยู่ใน repo ของ Arch แล้ว จึงใช้งานได้ทันที
    แค่เพิ่มแฟลกในคำสั่ง yt-dlp --cookies-from-browser firefox --remote-components ejs:github ...
    ตอนรันจะดาวน์โหลด solver ตอน runtime ซึ่งใช้เวลาแค่ราว 0.5 วินาทีเท่านั้น รู้สึกว่าความเร็วในการเริ่มดาวน์โหลดเร็วขึ้นมาก
    แต่ถ้าต้องรันในสภาพแวดล้อมที่มีข้อจำกัด ก็น่าจะดีถ้าสามารถดาวน์โหลด solver แยกไว้ล่วงหน้าด้วยคำสั่งเฉพาะได้ ตอนนี้ก็น่าพอใจอยู่แล้ว แต่ถ้ามี การทำแพ็กเกจอัตโนมัติ ก็จะสะดวกขึ้นอีก

    • ดีใจที่มันเร็วขึ้น เดี๋ยวนี้แม้แต่ในเบราว์เซอร์ YouTube ก็ยังทำงานได้ไม่ค่อยดี ทีมที่ยังคงทำให้เข้าถึงผ่านสคริปต์ Python ได้ถือว่าสุดยอดมาก
    • สงสัยว่าเป็นสภาพแวดล้อมแบบไหนที่ Python ใช้ได้แต่ JS ใช้ไม่ได้
      ถ้ากังวลเรื่องความปลอดภัย ตราบใดที่ใช้ Deno ก็มี sandbox ที่ทำไว้ค่อนข้างดี
      ถ้าเป็น OS ที่ไม่รองรับ Deno หรือ Node ก็อาจพิจารณา QuickJS ที่เขียนด้วย C ได้ ถึงจะช้าแต่ใช้ได้แทบทุกสภาพแวดล้อม
      แต่ในกรณีนั้นจะไม่มี sandbox แล้ว ถึงอย่างนั้นถ้าเป็นโค้ดที่มาจากโดเมน YouTube อย่างเป็นทางการ ก็คิดว่าน่าเชื่อถือได้
    • ถ้าอยากดาวน์โหลด solver ล่วงหน้า ก็แค่โหลดวิดีโออะไรก็ได้สักครั้ง แล้วคัดลอกไฟล์ ejs จากไดเรกทอรีแคชของ yt-dlp (เช่น /home/username/.cache)
      หรือจะลอง ทำแพ็กเกจอัตโนมัติ ด้วย make yt-dlp-extra ก็ได้
    • แพ็กเกจ yt-dlp-ejs บน AUR ดูเหมือนจะตรงกับจุดประสงค์นั้นพอดี
    • ฉันติดตั้ง Deno เองผ่าน Chocolately และติดตั้ง yt-dlp ผ่าน choco เช่นกัน เวอร์ชันคือ v2025.10.22
  • ช่วงหลัง YouTube เริ่ม บังคับ referrer header กับวิดีโอ embed
    ถ้าเข้าผ่าน youtube.com/embed/<videoid> โดยตรงจะขึ้น error และใน FAQ ก็ระบุชัดว่าเป็นนโยบายที่ตั้งใจไว้
    ตามเอกสารทางการ ผู้ฝังวิดีโอต้องส่ง HTTP Referer มิฉะนั้นจะเห็นหน้าจอ “error 153”

    • บริการ embed ส่วนใหญ่กำลังเปลี่ยนไปในทางนี้เรื่อย ๆ จุดประสงค์คือ เพิ่มการติดตาม บางกรณีก็ถึงขั้นบังคับให้ล็อกอิน
    • จริง ๆ แล้วหลบได้ด้วย JS redirect ง่าย ๆ แค่บรรทัดเดียว ต้นทุนในการทำคือหลายแสนดอลลาร์ แต่ต้นทุนในการหลบคือศูนย์ สุดท้ายมันเหมือนเป็นการส่งสัญญาณว่า “ถ้าเราอยากบล็อกจริง ๆ ก็ทำได้เสมอ”
  • ตอนที่ QuickTime ออกมาในปี 1991 ฉันคิดว่าการคัดลอก วาง และบันทึกวิดีโอเป็นเรื่องธรรมดาอยู่แล้ว
    ตอนนี้แม้แต่วิดีโอที่ไม่มี DRM เอง ประสบการณ์ผู้ใช้ ก็ยังแย่ลงมากจนไม่น่าเชื่อ

    • ตอนนี้ดีกว่าเมื่อก่อนมาก ในอดีตต้องติดตั้ง RealPlayer, Flash, codec pack ต่าง ๆ แล้วระบบก็พังเพราะ adware กันเป็นเรื่องปกติ
      ตอนนี้มีแค่ตัวเล่นพื้นฐานของ OS หรือ VLC ก็เอาอยู่เกือบหมด
    • ช่วงต้นยุค 90 เป็นช่วงที่ PC น่าตื่นเต้นที่สุด ตอนนี้สมาร์ตโฟนกลายเป็นกระแสหลักแล้ว สำหรับผู้ใช้ทั่วไปแนวคิดเรื่อง คัดลอก/บันทึก ก็เหลือแค่การแคปหน้าจอหรืออัดหน้าจอเท่านั้น
    • วิดีโอมีความหนาแน่นของข้อมูลสูง ค่าโฮสต์จึงแพง เลยเหลือแต่แพลตฟอร์มใหญ่ ๆ อย่าง YouTube ส่วนทางเลือกอย่าง Nebula, PeerTube, Odysee ก็ยังมีข้อจำกัดด้านคุณภาพหรือค่าใช้จ่าย
    • เมื่อก่อนเป้าหมายคือการปรับให้เหมาะกับผู้ใช้ แต่ตอนนี้เป็นยุคที่บริษัทขับเคลื่อนด้วย ผลประโยชน์ของตัวเองก่อน
    • มาตรฐานออกอากาศ ATSC 3 ก็มีปัญหาที่ไปเพิ่ม DRM ทีหลัง ทำให้อุปกรณ์รับสัญญาณเดิมใช้งานร่วมกันไม่ได้
  • ฉันใช้ yt-dlp (รวมถึงสมัยที่ยังเป็น youtube-dl) มาตั้งแต่ปี 2010 เพื่อ เก็บถาวร วิดีโอที่กดชอบไว้ทั้งหมด
    ตอนนี้เก็บไว้หลายหมื่นวิดีโอแล้ว และในนั้นจำนวนไม่น้อยก็หายไปจากเว็บแล้ว
    แม้แต่วิดีโอที่เปิดให้ดูแค่เดือนเดียวอย่างไฮไลต์ซูโม่ของ NHK ก็เก็บไว้

    • จะเรียกว่าเป็นพวก นักสะสมดิจิทัล ก็ได้ ถ้าทำฟังก์ชันแบบ Google Memories ที่คอยเตือนวิดีโอเก่า ๆ เป็นระยะก็น่าสนุกดี
    • หลายช่องมักลบหรือซ่อนวิดีโอของตัวเอง เลยเริ่มเก็บไว้ก่อนที่คอนเทนต์ดี ๆ จะหายไป
    • ทุกอย่างบนอินเทอร์เน็ตหายไปได้ทุกเมื่อ ถ้าสำคัญก็ต้องเก็บไว้เองถึงจะกลับมาดูได้อีก
    • ไม่คิดว่าจะได้เจอคนเก็บวิดีโอซูโม่ที่นี่ เห็นทีจะมีคนแบบพวกเราอยู่ไม่น้อย
    • ในยุคที่คอนเทนต์ล้นขนาดนี้ ก็อดคิดไม่ได้ว่าจำเป็นไหมที่จะต้องเก็บทุกอย่าง เมื่อก่อนฉันก็เก็บทั้ง MP3 และหนัง แต่ตอนนี้ เก็บแค่รูปไว้บนคลาวด์
  • ท่ามกลาง สงครามไม่รู้จบ ระหว่างการบล็อกโฆษณากับการยัดโฆษณา ก็ชวนให้คิดว่าสุดท้ายอาจมี AGI/ASI โผล่มาก็ได้
    ทั้งสองฝั่งคงใช้ LLM กันหมด แล้วมนุษย์ก็จะกลายเป็นสิ่งมีชีวิตที่ถูกแย่งทั้งเงินในกระเป๋าและความสนใจไปตรงกลาง

  • อีก 10 ปีข้างหน้า YouTube อาจเข้าผ่านเบราว์เซอร์ไม่ได้เลยก็ได้
    ถ้าคนรุ่นที่คุ้นกับแอปแท็บเล็ตกลายเป็นกระแสหลัก Google ก็น่าจะมีความมั่นใจพอที่จะทิ้งเว็บ

    • ถ้าจะบังคับ DRM แบบจริงจัง ก็ต้องมี ฮาร์ดแวร์เฉพาะทาง ต้องทำให้สตรีมที่เข้ารหัสเล่นได้เฉพาะบนอุปกรณ์ที่ผ่านการรับรอง L2 เท่านั้น
    • เว็บแอปบนมือถือมีบั๊กเยอะเกินจนแทบใช้ไม่ได้ แม้แต่คอมเมนต์ก็หายบ่อย
    • ถึงอย่างนั้น Google ก็ยึด กลยุทธ์ที่เน้นเว็บเป็นศูนย์กลาง มาตลอด
    • คนที่ดู YouTube ผ่านเบราว์เซอร์ก็ยังมีเยอะ และก็ยังมีทางเลือกอย่าง bilibili ของจีนอยู่ด้วย
    • แต่เพราะคนที่มีกำลังซื้อยังเป็นกลุ่มผู้ใช้เบราว์เซอร์ Google ก็คงไม่ทิ้งตลาดนั้นไปทั้งหมด
  • ใน yt-dlp issue #14404 มีข้อเสนอให้ใช้ Selenium หรือเบราว์เซอร์แบบ headless
    แต่ทีมดูแลตอบว่า “นั่นคือ การยอมแพ้ และขัดกับจิตวิญญาณของโปรเจกต์”

  • การสแครปเป็นงานที่หนักจริง ๆ API พังบ่อย และยังต้องคอยดูแลระบบในสภาพที่ผู้ให้บริการไม่ชอบเราอีก ถือว่าน่าทึ่งมาก

    • คำว่า “ผู้ให้บริการไม่ชอบเรา” นี่แหละกลับเป็นเสน่ห์ของโปรเจกต์นี้
    • ถ้าเป็นฉันคงไม่มีทางดูแล yt-dlp ได้แน่ มันเป็น งานที่บั่นทอนพลัง มากเกินไป
  • รู้สึกได้ว่า YouTube กำลังมี ท่าทีเป็นปฏิปักษ์กับผู้ใช้ มากขึ้นเรื่อย ๆ
    ทั้งการต่อต้าน ad blocker การเก็บคอนเทนต์ไปฝึก AI และการจำกัด API เหมือนกำลังอาศัยข้อเท็จจริงที่ว่าไม่มีคู่แข่ง

    • จริง ๆ แล้วลูกค้าตัวจริงของ Google คือ ผู้ลงโฆษณา พวกเราเป็นแค่สินค้าเท่านั้น
      บริษัทอ่อนไหวกับความพึงพอใจของผู้ลงโฆษณา แต่ปฏิบัติต่อผู้ใช้และครีเอเตอร์เหมือน ของใช้สิ้นเปลือง
      การเริ่มจากของฟรี กำจัดคู่แข่ง แล้วสร้างโครงสร้างผูกขาด เป็นกลยุทธ์แบบล่อเหยื่อชนิดหนึ่ง
      ตอนนี้ต้องการทางเลือกใหม่แล้ว ถ้าเป็นบริการเสียเงินแต่โปร่งใสก็น่าจะดี
    • ช่วงนี้โดยเฉพาะในวิดีโอสำหรับเด็ก โฆษณาข้ามไม่ได้ เพิ่มขึ้นมาก
    • ค่าใช้จ่ายในการให้บริการของ YouTube สูงมาก เลยคิดว่าการบล็อกโฆษณาอาจกระทบต่อการคงอยู่ของบริการได้
    • สุดท้ายแล้ว UX ที่เละเทะในแบบ enshittification ตอนนี้ก็กลายเป็นส่วนหนึ่งของโมเดลธุรกิจไปแล้ว
  • ตาม yt-dlp EJS wiki เหตุผลที่แนะนำ Deno คือ
    มันรันโค้ดได้ด้วยสิทธิ์ที่จำกัด และสามารถดึง dependency ของ EJS จาก npm แบบ remote ได้

    • แต่ก็ไม่ควร เชื่อมั่นใน sandbox ของ Deno มากเกินไป ว่าเป็นมาตรการความปลอดภัยที่เพียงพอ เพราะการแยกระดับ runtime ยังอ่อนอยู่
      การใช้ การแยกระดับ OS/VM อย่าง Firecracker จะปลอดภัยกว่า
    • เมื่อก่อน yt-dlp ตีความ JS ได้ด้วย Python ล้วน ๆ แต่เมื่อ runtime มีความซับซ้อนขึ้นเรื่อย ๆ ตัว interpreter ที่ทำเองก็เริ่มถึงขีดจำกัด