Yt-dlp: giờ đây bắt buộc phải có runtime JavaScript bên ngoài để hỗ trợ đầy đủ YouTube

• yt-dlp là công cụ tải xuống dòng lệnh có thể tải audio·video từ hàng nghìn website, là phiên bản fork của youtube-dl
• Để giải mã n/sig của YouTube, cần runtime JavaScript bên ngoài (ví dụ: Deno, Node.js, Bun, QuickJS) cùng với mô-đun yt-dlp-ejs mới được bổ sung
• Deno được đặt làm runtime mặc định, và người dùng có thể chỉ định runtime khác bằng tùy chọn --js-runtimes
• Với thay đổi này, để sử dụng đầy đủ các tính năng liên quan đến YouTube thì bắt buộc phải cài yt-dlp-ejs và runtime JS
• Việc bổ sung phụ thuộc vào runtime bên ngoài là biện pháp bắt buộc để ứng phó với những thay đổi trong cấu trúc mã hóa của YouTube, và sẽ đóng vai trò là yếu tố cốt lõi trong bảo trì về sau

---

Tổng quan về yt-dlp

• yt-dlp là một nhánh fork của youtube-dl, được phát triển dựa trên youtube-dlc hiện không còn được bảo trì
• Công cụ này có thể tải audio và video từ hàng nghìn website, đồng thời hỗ trợ nhiều tính năng như chọn định dạng·hậu xử lý·phụ đề·plugin

Thay đổi liên quan đến hỗ trợ YouTube

• Cần gói yt-dlp-ejs để giải mã giá trị n/sig của YouTube
  • Gói này được phát hành theo Unlicense, và bao gồm các thành phần giấy phép MIT và ISC
• Để chạy yt-dlp-ejs thì runtime JavaScript là bắt buộc
  • Các runtime được hỗ trợ: deno (khuyến nghị), node.js, bun, QuickJS
  • Có thể chỉ định cấu hình liên quan bằng tùy chọn --js-runtimes
• Có thể dùng tùy chọn --no-js-runtimes để khởi tạo lại cấu hình runtime mặc định

Cài đặt và phụ thuộc

• yt-dlp hỗ trợ Python 3.10+ (CPython) và 3.11+ (PyPy)
• Các phụ thuộc được khuyến nghị mạnh mẽ:
  • ffmpeg / ffprobe: dùng để ghép audio·video và hậu xử lý
  • yt-dlp-ejs: dùng để gỡ mã hóa YouTube
  • runtime JavaScript: dùng để chạy yt-dlp-ejs
• Các phụ thuộc mạng tùy chọn gồm certifi, brotli, requests, curl_cffi v.v.

Các tùy chọn lệnh chính

• --js-runtimes RUNTIME[:PATH]: chỉ định runtime JS sẽ sử dụng
• --no-js-runtimes: vô hiệu hóa mọi runtime JS
• --remote-components COMPONENT: tùy chọn cho phép các thành phần JS bên ngoài
• --no-remote-components: chặn tải các thành phần từ xa

Tầm quan trọng

• Với thay đổi này, yt-dlp nay bắt buộc phải yêu cầu runtime JS bên ngoài để hỗ trợ đầy đủ cấu trúc mã hóa mới nhất của YouTube
• Đây là một bước chuyển đổi mang tính cấu trúc để ứng phó với các bản cập nhật bảo mật·mã hóa liên tục của YouTube, đồng thời là thay đổi then chốt cho việc bảo trì và mở rộng tính năng trong tương lai

[kimjoin2]

Wow... chặn được như vậy cũng thật ghê, mà vượt qua được như thế cũng thật ghê. Không biết họ phân tích và vượt qua bằng cách nào nhỉ

[GN⁺]

Ý kiến trên Hacker News

• Đã có sẵn trong repo Arch nên chạy được ngay
  Chỉ cần thêm cờ vào lệnh yt-dlp --cookies-from-browser firefox --remote-components ejs:github ...
  Khi chạy, solver sẽ được tải về lúc runtime và chỉ mất khoảng 0,5 giây. Cảm giác tốc độ bắt đầu tải nhanh hơn hẳn
  Tuy vậy, nếu chạy trong môi trường bị hạn chế thì sẽ tốt hơn nếu có thể tải trước solver bằng một lệnh riêng. Hiện tại cũng đã ổn, nhưng nếu có tự động hóa đóng gói thì sẽ tiện hơn nữa

  • Nghe nói tốc độ nhanh hơn thì thật đáng mừng. Dạo này ngay cả YouTube trên trình duyệt cũng không chạy tử tế, nên đội ngũ vẫn giữ được khả năng truy cập bằng script Python thật đáng nể
  • Tôi tò mò môi trường nào mà Python chạy được nhưng JS thì không
    Nếu lo về bảo mật thì miễn là dùng Deno, sandbox vẫn được xử lý khá tốt
    Nếu là hệ điều hành không hỗ trợ Deno hay Node thì cũng có thể cân nhắc QuickJS viết bằng C. Nó chậm hơn nhưng chạy được gần như mọi nơi
    Chỉ là trong trường hợp đó sẽ mất sandboxing. Dù vậy, nếu là mã được cung cấp từ các domain YouTube chính thức thì tôi vẫn nghĩ là có thể tin tưởng được
  • Nếu muốn tải trước solver, chỉ cần tải thử bất kỳ video nào một lần rồi chép file ejs từ thư mục cache của yt-dlp (ví dụ: /home/username/.cache) là được
    Hoặc có thể thử tự động hóa đóng gói bằng make yt-dlp-extra
  • Gói yt-dlp-ejs trên AUR có vẻ đúng là để phục vụ mục đích đó
  • Tôi đã cài Deno thủ công bằng Chocolately, và yt-dlp cũng cài qua choco, nên phiên bản là v2025.10.22

• Gần đây YouTube bắt đầu ép header referrer cho video nhúng
  Nếu truy cập trực tiếp youtube.com/embed/<videoid> thì sẽ báo lỗi, và trong FAQ cũng ghi rõ đây là chính sách có chủ đích
  Theo tài liệu chính thức, bên nhúng phải cung cấp HTTP Referer, nếu không sẽ hiện màn hình “error 153”

  • Phần lớn các dịch vụ nhúng đang ngày càng chuyển theo kiểu này. Mục đích là tăng cường theo dõi. Thậm chí có chỗ còn bắt đăng nhập
  • Thực ra có thể lách bằng đúng một dòng JS redirect đơn giản. Chi phí triển khai là hàng trăm nghìn đô, còn chi phí vượt qua là 0. Rốt cuộc nó giống như một thông điệp “nếu muốn thì chúng tôi có thể chặn bất cứ lúc nào”

• Khi QuickTime ra mắt năm 1991, tôi từng nghĩ chuyện video có thể sao chép, dán và lưu lại là điều hiển nhiên
  Giờ thì ngay cả video không có DRM mà trải nghiệm người dùng cũng tệ đến mức khó tin

  • Bây giờ vẫn tốt hơn ngày xưa nhiều. Hồi trước chuyện cài RealPlayer, Flash, codec pack rồi làm hệ thống hỏng vì adware là rất thường gặp.
    Giờ chỉ cần trình phát mặc định của OS hoặc VLC là giải quyết được hầu hết
  • Đầu thập niên 90 là giai đoạn PC thú vị nhất. Giờ smartphone thành dòng chủ đạo, nên với người dùng phổ thông, khái niệm sao chép/lưu trữ gần như chỉ còn lại ở screenshot hay quay màn hình
  • Video có mật độ dữ liệu cao nên chi phí lưu trữ/phân phối lớn. Vì vậy chỉ còn những nền tảng lớn như YouTube trụ lại, còn các lựa chọn thay thế như Nebula, PeerTube, Odysee thì bị giới hạn về chất lượng hoặc chi phí
  • Trước đây mục tiêu là tối ưu vì người dùng, còn bây giờ là thời đại doanh nghiệp hành động với lợi ích của chính mình là trên hết
  • Chuẩn phát sóng ATSC 3 cũng gặp vấn đề khi thêm DRM quá muộn, khiến các thiết bị thu hiện có không còn tương thích

• Từ năm 2010 đến nay tôi đã dùng yt-dlp (kể cả thời còn là youtube-dl) để lưu trữ toàn bộ video tôi đã thích
  Giờ tôi đã lưu hàng chục nghìn video, và trong số đó có không ít cái đã biến mất khỏi trang
  Tôi cũng lưu cả những video chỉ được công khai trong thời gian ngắn như highlight sumo của NHK

  • Có thể gọi đây là kiểu sưu tầm số. Sẽ thú vị nếu làm một tính năng kiểu Google Memories để định kỳ nhắc lại các video cũ
  • Có rất nhiều trường hợp kênh tự ẩn hoặc xóa video, nên tôi bắt đầu lưu lại trước khi nội dung hay biến mất
  • Mọi thứ trên Internet đều có thể biến mất bất cứ lúc nào. Thứ quan trọng thì phải tự lưu mới có thể xem lại được
  • Không ngờ ở đây lại gặp người cũng lưu video sumo. Hóa ra cũng có khá nhiều người như vậy
  • Trong thời đại nội dung tràn ngập, tôi tự hỏi có thật sự cần lưu mọi thứ không. Trước đây tôi cũng gom MP3, phim ảnh đủ cả, nhưng giờ chỉ lưu ảnh trên đám mây

• Giữa cuộc đối đầu không hồi kết giữa chặn quảng cáo và chèn quảng cáo, tôi còn nghĩ có khi AGI/ASI cuối cùng sẽ xuất hiện từ đó.
  Cả hai phía rồi cũng sẽ dùng LLM, còn con người ở giữa thì bị móc túi và hút cạn sự chú ý

• 10 năm nữa có khi YouTube sẽ hoàn toàn không thể truy cập qua trình duyệt
  Khi thế hệ quen với app trên tablet trở thành chủ đạo, có lẽ Google sẽ đủ tự tin để bỏ web

  • Nếu muốn ép DRM thật sự thì sẽ cần phần cứng chuyên dụng. Phải làm sao để luồng mã hóa chỉ phát được trên thiết bị đạt chứng nhận L2
  • Web app trên di động quá nhiều lỗi nên gần như không dùng nổi. Cả phần bình luận cũng hay biến mất
  • Dù vậy, Google từ trước đến nay vẫn luôn duy trì chiến lược lấy web làm trung tâm
  • Thế hệ xem YouTube bằng trình duyệt vẫn còn rất đông, và cũng có các lựa chọn thay thế như bilibili của Trung Quốc
  • Nhưng vì thế hệ có sức mua vẫn là người dùng trình duyệt, nên có lẽ Google sẽ không bỏ hẳn thị trường đó

• Trong issue #14404 của yt-dlp từng có đề xuất dùng Selenium hoặc trình duyệt headless, nhưng
  đội ngũ bảo trì đã trả lời rằng “đó là tuyên bố đầu hàng và đi ngược lại tinh thần của dự án”

• Scraping thật sự là công việc cực nhọc. API thường xuyên hỏng, mà còn phải duy trì trong tình trạng bên cung cấp ghét mình, đúng là rất đáng nể

  • Chính việc “bên cung cấp ghét mình” lại có vẻ là cái thú của dự án này
  • Nếu là tôi thì chắc chắn không thể bảo trì yt-dlp nổi. Đó là công việc bào mòn sức lực quá mức

• Có thể cảm nhận được YouTube ngày càng tỏ ra mang tính đối đầu với người dùng
  Chặn trình chặn quảng cáo, thu thập nội dung để huấn luyện AI, giới hạn API... như thể đang tận dụng việc không có cạnh tranh

  • Thực ra khách hàng thật sự của Google là nhà quảng cáo. Chúng ta chỉ là sản phẩm của họ mà thôi
    Họ rất nhạy với sự hài lòng của nhà quảng cáo, nhưng lại xem người dùng hay nhà sáng tạo như đồ tiêu hao
    Việc khởi đầu miễn phí để triệt đối thủ rồi tạo ra cấu trúc độc quyền là một kiểu chiến lược nhử mồi.
    Giờ cần có lựa chọn thay thế mới. Nếu là dịch vụ trả phí nhưng minh bạch thì cũng tốt
  • Dạo này đặc biệt là ở video trẻ em, quảng cáo không thể bỏ qua ngày càng nhiều
  • Chi phí vận hành của YouTube lớn đến mức tôi nghĩ việc chặn quảng cáo có thể ảnh hưởng tới khả năng duy trì dịch vụ
  • Rốt cuộc chính UX tồi tệ hóa (enshittification) hiện nay cũng đã trở thành một phần của mô hình kinh doanh

• Theo wiki EJS của yt-dlp, lý do Deno được khuyến nghị là
  nó cho phép thực thi mã với quyền bị hạn chế và có thể nhận từ xa các dependency EJS từ npm

  • Nhưng không nên quá tin vào sandboxing của Deno như một biện pháp bảo mật. Cô lập ở mức runtime là khá yếu,
    nên an toàn hơn là dùng cô lập ở mức OS/VM như Firecracker
  • Trước đây yt-dlp từng phân tích JS chỉ bằng Python, nhưng khi yêu cầu runtime ngày càng phức tạp thì cách dùng trình thông dịch tự viết đã bộc lộ giới hạn