- Để tiếp tục sử dụng bình thường tính năng tải xuống YouTube trên yt-dlp, sắp tới sẽ bắt buộc phải cài Deno (hoặc một JavaScript runtime được hỗ trợ)
- Do những thay đổi gần đây từ phía YouTube, "trình thông dịch" JavaScript tích hợp không còn giải được JS challenge nữa
- Người dùng tệp thực thi PyInstaller chỉ cần chuẩn bị Deno, còn khi dùng gói PyPI thì cần cài thêm các thành phần JavaScript bổ sung
- Hỗ trợ các JavaScript runtime khác như Node, Bun... vẫn được để ngỏ, nhưng hiện tại chỉ Deno phù hợp về bảo mật và sandboxing
- Dự kiến sẽ có tùy chọn và hướng dẫn riêng về cách cài Deno cùng các dependency liên quan, cũng như cách chỉ định đường dẫn
Công bố thay đổi tải xuống YouTube trên yt-dlp và các yêu cầu mới
Bối cảnh áp dụng yêu cầu mới
- Trong thời gian tới, để sử dụng bình thường tính năng tải xuống YouTube, người dùng sẽ bắt buộc phải cài Deno hoặc một JavaScript runtime khác được hỗ trợ
- Từ trước đến nay, yt-dlp giải các JS challenge từ phía YouTube bằng trình thông dịch JavaScript tích hợp, nhưng do thay đổi trong logic nội bộ của YouTube gần đây, cách làm cũ không còn hoạt động được nữa
- Mức độ thay đổi là rất lớn, nên để hoạt động bình thường, yt-dlp sẽ buộc phải dùng thuật toán dựa trên JavaScript runtime đầy đủ thì mới có thể vượt qua các yêu cầu từ YouTube
Cách chuẩn bị và ứng phó theo từng nhóm người dùng
- Cài Deno (hoặc JS runtime được hỗ trợ)
- Danh sách runtime được hỗ trợ thêm sẽ được thông báo sau qua FAQ v.v.
- Có thể cần cài thêm một số thành phần JavaScript mà yt-dlp yêu cầu
- Việc có cần thao tác thêm hay không sẽ khác nhau tùy theo cách cài đặt và hình thức phân phối của yt-dlp
Checklist theo từng bản phân phối chính thức
- Tệp thực thi chính thức phát hành qua PyInstaller (
yt-dlp.exe, yt-dlp_macos, yt-dlp_linux v.v.)
- Chỉ cần cài Deno, các thành phần bổ sung đã được đóng gói sẵn trong tệp thực thi
- Gói PyPI (
pip, pipx v.v.)
- Cần cài yt-dlp với nhóm dependency tùy chọn
default và nâng cấp lên phiên bản mới nhất
- Ví dụ:
pip install -U "yt-dlp[default]"
- Binary zipimport chính thức (yt-dlp cho Unix)
- Cần thêm cờ để Deno tải các dependency npm
- Hoặc cài một gói JS solving riêng cho yt-dlp vào môi trường Python (tên gói và tùy chọn sẽ được thông báo sau)
- Gói bên thứ ba (
pacman, brew v.v.)
- Cách xử lý có thể khác tùy chính sách của từng bản phân phối, nhưng có thể áp dụng phương án dành cho người dùng binary zipimport
Trao đổi về runtime và bảo mật
- Vẫn có khả năng hỗ trợ các JS runtime thay thế như Node, Bun..., nhưng ở thời điểm hiện tại các runtime này chưa cung cấp tính năng bảo mật và sandboxing tương đương Deno
- Việc có hỗ trợ thêm các JS runtime khác trong tương lai hay không vẫn đang được thảo luận, và trước khi có quyết định cuối cùng, hướng dẫn sẽ lấy Deno làm chuẩn
Hướng dẫn bổ sung về cài đặt Deno
- Tương tự yt-dlp, Deno có thể được dùng chỉ bằng cách tải một tệp thực thi duy nhất từ GitHub và đặt nó vào đường dẫn phù hợp
- Sau này, yt-dlp dự kiến sẽ có tùy chọn
--js-runtimes để chỉ định đường dẫn đến tệp thực thi Deno (tên tùy chọn và cách dùng có thể thay đổi)
- Sau khi tải Deno bằng
curl hoặc cách tương tự, chỉ cần đặt nó vào cùng thư mục với tệp thực thi yt-dlp là có thể hoạt động bình thường
FAQ và hướng dẫn bổ sung
- Tùy theo OS hoặc trình quản lý gói đang dùng, có thể cần thêm cấu hình như bổ sung vào
PATH
- Trên một số môi trường như Linux, Deno có thể được tự động thêm vào
PATH
- Các câu hỏi thêm và vấn đề liên quan đến cài đặt sẽ được hỗ trợ qua FAQ hoặc cộng đồng
Phản ứng cộng đồng khác và các cập nhật sắp tới
- Một số người dùng đang hỏi về nhiều tác động dây chuyền khác nhau như việc ngừng hỗ trợ hệ thống 32bit, các tùy chọn phát hành, v.v.
- Đội ngũ phát triển yt-dlp đang chuẩn bị hướng dẫn và phương án hỗ trợ tốt hơn dựa trên issue, patch và phản hồi từ cộng đồng
Kết luận và tóm tắt
- Do thay đổi trong cấu trúc hệ thống của YouTube, cơ chế hoạt động và yêu cầu hệ thống của yt-dlp sẽ thay đổi đáng kể
- Thay đổi quan trọng nhất là: nếu muốn tiếp tục tải YouTube bình thường, người dùng sẽ bắt buộc phải chuẩn bị JS runtime như Deno
- Cần nhanh chóng ứng phó theo hướng dẫn tương ứng với từng hình thức phân phối chính thức
- Sẽ tiếp tục có thêm hướng dẫn, FAQ và tài liệu cài đặt trong thời gian tới
1 bình luận
Ý kiến trên Hacker News
Tôi là người đăng ký trả phí YouTube Premium. Cuối tuần trước tôi định tải video để xem trên tàu, nhưng cả iPad lẫn iPhone đều bị kẹt ở bước “Đang chờ tải xuống..”. Khởi động lại cũng không giúp được gì, tôi thử suốt 1 tiếng rồi bỏ cuộc. Cuối cùng tôi dùng yt-dlp để tải video, chép sang USB c flash drive và xem từ đó. Nếu sắp tới họ thật sự áp dụng chính sách “hạn chế chia sẻ Premium trong gia đình”, thì lúc đó tôi sẽ hủy thật. Cả nhà tôi đang dùng rất tốt môi trường không quảng cáo
Tôi cũng là thuê bao Premium nhưng gặp vấn đề tương tự trên ứng dụng iPad. Ngay cả khi muốn tải video cho em bé xem thì cũng không bao giờ hoạt động ổn ngay từ lần đầu. Bực quá nên tôi mua lại một chiếc Samsung Galaxy Tab A7 cũ, cài custom ROM LineageOS. Tôi bỏ toàn bộ media mình muốn vào thẻ sd 1TB rồi phát rất tốt bằng VLC. Ngoài ra, NewPipe lấy từ F-Droid store tải video YouTube ổn định hơn hẳn ứng dụng chính thức. Ban đầu tôi định dùng thứ như yt-dlp để nạp media, nhưng giờ thì không còn cần nữa
Tôi có trả tiền cho YouTube Premium, nhưng trên điện thoại thì phải dùng ReVanced vì cần tắt tính năng tự động áp dụng bản dịch. Tôi không hiểu nổi vì sao ứng dụng chính thức lại không cho người dùng tự đổi cài đặt này
Nếu bạn tải một video đã đăng lên YouTube từ Creator Dashboard xuống lại — ví dụ như khi bạn livestream mà không lưu bản sao cục bộ, hoặc khi máy tính đang quá tải — thì chỉ tải được bản 720p chất lượng thấp. Còn nếu dùng yt-dlp thì có thể lấy được chất lượng cao nhất
Tôi đã hủy đăng ký vì trải nghiệm không quảng cáo không hoạt động trên YouTube Kids (đang dùng ShieldTV). Có lẽ đó là bug, nhưng vì không có hỗ trợ khách hàng nên chẳng có cách nào xử lý. Trước đây tôi đăng ký trả phí Play Music, rồi bị ép chuyển sang YouTube, nên đây đúng là cú thất vọng cuối cùng
Nếu bạn đang chờ chính sách hạn chế chia sẻ gia đình được áp dụng, thì xin báo là đã có tin về chuyện đó rồi. Tôi cũng nhận được email từ YouTube liên quan việc này. Hiện tại tôi vẫn dùng không quảng cáo, nhưng chưa rõ khi nào họ sẽ thực sự triển khai. Có thể xem bài viết liên quan
Tôi rất khâm phục lượng công sức kỹ thuật đổ vào “trình thông dịch JavaScript” của yt-dlp yt-dlp jsinterp.py
Đây đúng là cách tiếp cận chuẩn cho vấn đề này. Thật sự ấn tượng khi họ làm được đến mức đó mà không tạo thêm nhiều overhead
Với tôi, đây mới là điểm mấu chốt bị ẩn đi nhiều nhất trong thông báo lần này. Tôi không biết cấu trúc bên trong đã phức tạp đến vậy, và thật sự thấy rất nể
Đây là cách chỉ thông dịch một phần của JavaScript. Có thể xem thảo luận HN liên quan tại đây
Nhìn lướt qua code một chút mà tôi biết thêm về ChainMap của Python
Tôi tò mò không biết nó thực sự thông dịch được bao nhiêu JavaScript, và liệu đoạn code chưa đến 1.000 dòng này có thể dùng trong một lớp nhập môn compiler hay không
Tôi là một “digital hoarder”, đã sưu tầm media số hơn 30 năm. Tôi không giữ VHS, DVD hay media vật lý nào, tất cả đều được lưu dưới dạng số. Cũng có một ít thứ hiếm hoặc có nguy cơ biến mất. Vợ tôi cũng bắt đầu hứng thú với hệ thống tôi vận hành “kiểu Netflix tại nhà”, và rất thích trải nghiệm không quảng cáo. Tôi chưa bao giờ nghĩ mình là người đặc biệt, cứ tưởng ai rồi cũng sẽ dùng streaming thôi. Nhiều năm nay tôi vẫn nói với người xung quanh rằng “nếu tôi có chương trình bạn thích trong kho media thì cứ nói”. Trong 2 năm gần đây, người thân và bạn bè bắt đầu muốn truy cập server Jellyfin của tôi, hoặc nhờ tôi dựng một server nhỏ đặt dưới TV cho họ. Gần đây tôi còn thêm tính năng lưu trữ archive các kênh YouTube vào Jellyfin, dùng thư mục riêng và lệnh yt-dlp cho từng kênh để tự động tải video. Tuy nhiên, video không tải được theo codec h264 mà tôi muốn nên tôi phải re-encode. Video YouTube được cung cấp bằng codec AV1, mà smart TV của tôi vẫn chưa hỗ trợ, nên tôi tự mã hóa lại
Trước đây tôi chạy script đơn giản, nhưng giờ thì dùng ytdltt GitHub của ytdltt qua bot Telegram để khi mẹ tôi muốn video YouTube như audiobook thì tôi có thể tải xuống, sắp xếp theo thư mục và cho truy cập qua Jellyfin. Bộ audiobook mẹ tôi tích lũy trong 3 năm giờ đã khoảng 1,2TB
Với mục đích tương tự, tubesync cũng đáng thử
Vì không tải được nội dung h264 nên tài liệu yt-dlp từng làm tôi thấy khá khó hiểu, nhưng cách hiện đang chạy tốt là như này
yt-dlp -f "bestvideo[width<800][vcodec~='^(avc|h264)']+bestaudio[acodec~='^((mp|aa))']"Gần đây tôi biết đến Pinchflat GitHub của Pinchflat, một lựa chọn web kiểu *arr dùng yt-dlp ở backend. Chỉ cần thêm video muốn tải vào playlist là nó tự tải về
Tôi tò mò không biết có cần né phát hiện bot bằng cách thêm cookie hay thứ gì đó không, và có cần dùng cả VPN không
Giờ đây thời đại chỉ đơn giản lấy dữ liệu từ web đã hết, và thay vào đó là thời đại phải chạy hàng nghìn dòng JavaScript bị làm rối. Trước kia có thể dễ dàng lấy một file json 1kb rồi cache lại, còn bây giờ phải chạy cả trình duyệt, trao đổi 10MB dữ liệu qua 100 request, làm hỏng cả môi trường phân tích lẫn hồ sơ bảo mật. Tất cả mọi người đều thiệt
Nếu nhìn theo hướng tích cực, chính sự bất tiện này lại mở ra cơ hội kinh doanh cho 10.000 công ty scraping: họ cào đống rác 10MB ấy rồi cung cấp lại dưới dạng API tử tế. Nhưng giờ chất lượng nội dung website cũng đang đi xuống, nên mấy vấn đề này dần bớt quan trọng hơn
Giờ web đã phức tạp đến mức việc chống scraping rồi lại tìm cách vượt chống scraping giống như một trò chơi lặp vô tận. Nhưng với AI/LLMs xuất hiện, dù tốn kém hơn, người ta giờ có thể trích xuất gần như mọi thông tin. Chẳng bao lâu nữa LLM cũng sẽ vượt được mọi captcha. Có thể chúng ta sắp bước vào thời kỳ mà “lỗ hổng analog” lúc nào cũng mở. Chỉ cần camera và micro chĩa vào màn hình, âm thanh là AI có thể hiểu tốt hơn cả con người
May là kiểu scraping quy mô nhỏ như yt-dlp lại dễ hơn bao giờ hết. Chỉ cần bỏ ra một hai tiếng với headless Firefox và mitmproxy là có thể dựng script khá dễ, và trừ khi bạn chạy hàng loạt VPS để cào cả website ở quy mô lớn, còn không thì việc archive nội dung mình muốn vẫn rất ổn. Cloudflare cũng không chặn người dùng lưu lượng thấp thông thường. Tự động hóa trình duyệt hiện đại đủ dễ để một cá nhân có thể cào site kể cả khi nó là SPA. Captcha ở quy mô nhỏ cũng có thể tự giải. Gần đây tôi còn cho hệ thống gửi thông báo Discord khi gặp captcha, rồi tôi mở laptop ra giải xong cho nó tiếp tục scraping. Ứng dụng “World Garden” cứ muốn kiểm soát webtoon tôi đã trả tiền mua, nên tôi nghĩ dữ liệu của mình phải do mình kiểm soát
Thực ra ngay cả file json 1kb trên web hiện đại cũng thường đòi tải về cả MB JavaScript để chạy rồi mới hiển thị dữ liệu. Cái tôi muốn chỉ là 10-20kb HTML, thêm chút CSS và vài file ảnh. Video thì tải trực tiếp file mp4 là xong. Đơn giản và hiệu quả, nhưng nếu mục tiêu là bán được thứ gì đó thì câu chuyện lại khác
Lý do của mọi sự phức tạp này rốt cuộc vẫn là để bán được nhiều quảng cáo hơn
Nsig/sig - là token đặc biệt bắt buộc phải có trong API call. Nó được tạo trong base.js (mã player), và các client bên thứ ba như yt-dlp phải tìm cách trích xuất để vượt qua. Trước đây chỉ cần rút ra vài đoạn code bằng regex hay tương tự để lấy token, nhưng giờ code đã bị phân tán đến mức phải chạy toàn bộ base.js mới lấy được token
PoToken - là token chứng minh nguồn gốc mà Google gần đây siết chặt hơn. Nếu không có sẽ bị lỗi 403. Trên Android thì dùng DroidGuard, trên iOS là mô-đun tích hợp cho app, còn trên web thì phải chạy mã JS (challenge). Trước đây cần công cụ ngoài để phát hành, nhưng với bản cập nhật dựa trên Deno của yt-dlp thì sắp tới có thể tích hợp sẵn
SABR - là công nghệ adaptive bitrate streaming phía máy chủ, dùng cùng giao thức UMP của Google, cho phép server nhận vị trí phát/buffer rồi tự điều khiển tối ưu việc buffering và cả chèn quảng cáo. Phía hỗ trợ client bên thứ ba vẫn đang được làm
Ví dụ trích xuất Nsig/sig:
Hướng dẫn PoToken:
SABR:
(đã cập nhật thêm ví dụ code và link hướng dẫn)
Giờ thì tôi hiểu vì sao Google và Cloudflare muốn giới hạn web chỉ còn vài trình duyệt có chữ ký và được xác minh tính toàn vẹn
Về PoToken trên web, tôi thắc mắc việc chạy một đoạn JS thì làm sao chứng minh được rằng đó không phải bot. Nếu chỉ là JS phía client, chẳng phải headless Chromium cũng chạy được sao?
Google vừa mới đưa cái này vào mà đã có cách vượt qua rồi. Đúng là dù công ty lớn đến đâu, nếu đã giao nội dung cho client thì cuối cùng cũng luôn có cách lách. Vì vậy họ đều muốn xây hệ sinh thái đóng, độc quyền — để bắt người dùng xem hết quảng cáo hoặc trả phí sử dụng
Cách đây không lâu trên HN cũng có người nói rằng YouTube thực ra muốn các công cụ tải xuống vẫn hoạt động bài liên quan 1 bài liên quan 2. YouTube đang vận hành một dịch vụ toàn cầu với 3 tỷ người dùng, nhưng cảm giác như họ không hề muốn chặn tải xuống hoàn toàn, mà chỉ chặn ở mức “vừa đủ”. Tôi nghĩ nếu toàn bộ người dùng trên thế giới đều dùng iPhone hoặc Android mới nhất thì có lẽ họ đã bật DRM ngay lập tức rồi
yt-dlp tận dụng API dành cho smart TV đời cũ. Các thiết bị này sẽ không còn nhận cập nhật phần mềm nữa, nên nếu loại traffic đó biến mất thì tính năng này cũng có thể chấm dứt
Tôi không thấy có logic gì trong thuyết âm mưu cho rằng nền tảng nội dung lại muốn hỗ trợ tải xuống đến mức phá hỏng mô hình kiếm tiền của chính mình
Trình phát và trang YouTube ngày càng nặng, đến mức trên PC cũ thì lại chậm hơn cả việc tải video về xem. Gần đây tôi đổi “watch?v=” thành “/embed/” để xem ở 480p, nhưng nếu tải cùng video đó về rồi phát thì CPU chỉ dùng khoảng 3%. Dù vậy, ngay cả cách này giờ cũng dần hoạt động kém đi. Trong khi đó, các site khác (ví dụ: site người lớn) lại chú trọng tối ưu trải nghiệm hơn và cũng không mấy quan tâm chuyện chặn công cụ tải xuống
Video (thường)
Video (embed)
GitHub cũng tương tự, tối ưu kém đến mức trên PC i5 thế hệ 8 gần như khó dùng nổi. Vì vậy tôi thường chụp snapshot lại để xem offline
Nguyên nhân khiến hiệu năng YouTube xuống dốc dạo này là vì họ ép mọi người dùng các codec nặng đời mới. Laptop của tôi phát video 4K h264 không vấn đề gì, nhưng chỉ cần xem video YouTube 720p là máy nóng lên và giật ngay. Có extension trình duyệt là h264ify để chặn một số codec nhất định, nhưng tôi vẫn thấy khó hiểu vì sao người dùng không thể tự điều chỉnh hành vi mặc định này. Tải video về xem lại còn tiện và ổn định hơn
Không phải chỉ mình tôi. Quý 1 năm 2025 tôi vẫn xem bằng embed player, nhưng sang quý 3 thì Google cố tình chặn cách đó. Hiện tại YouTube chỉ còn tiếp cận được bằng yt-dlp. Mong yt-dlp và các nhà phát triển của nó tồn tại mãi mãi
Tôi đang tính rời YouTube để chuyển sang PeerTube hoặc các nền tảng kiểu peer-based
Có báo cáo nói rằng QuickJS (trình thông dịch JS gọn nhẹ) chậm đến mức mỗi video phải chạy hơn 20 phút. Deno thì nhanh hơn rất nhiều, nên tôi khá tò mò vì sao chênh lệch lại lớn như vậy
(tham khảo issue #14404 / phản hồi)
QuickJS là trình thông dịch dựa trên bytecode (chậm kiểu Python), ưu tiên sự đơn giản và ổn định. Trong khi đó Deno dùng JIT compiler hiệu năng rất cao cấp độ Chrome, nên với một số kiểu mã cụ thể thì chênh lệch tốc độ chạy có thể lên tới hơn 20 lần. QuickJIT (một fork của QuickJS, thêm JIT bằng TCC) có thể vẫn chậm hơn Deno nhưng vẫn có tiềm năng cải thiện
Hiệu năng tụt thảm đến mức này làm tôi hơi rợn người, vì có cảm giác như Google cố tình khiến nó chạy chậm trên các trình thông dịch khác
Khá thú vị. Minecraft (Bedrock, cho mục đích modding) cũng dùng QuickJS, và dù chậm hơn V8 thật, tôi không nghĩ nó chênh tới mức này
Giờ đây đã có dấu hiệu rất rõ rằng thời kỳ ripping dễ dàng sắp kết thúc. Nếu có video YT nào bạn muốn lưu trữ lâu dài, tôi khuyên nên cài tubearchivist hoặc thứ tương tự ngay bây giờ để backup
Tôi cũng đề xuất pinchflat GitHub của Pinchflat như một lựa chọn thay thế. Nó kém hoàn thiện hơn tubearchivist, nhưng theo trải nghiệm của tôi thì ít lỗi hơn
Tôi nghĩ những tài sản văn hóa và giáo dục giá trị mà YT tích lũy được nhờ vị thế độc quyền thị trường có lẽ đang ở thời điểm cuối cùng để được lưu giữ. tubearchivist trông có vẻ hay, nhưng việc dựng và quản lý có vẻ khá phiền, nên tôi hơi ngại. Hơn nữa, nó thiên về tải toàn bộ từ các kênh đã đăng ký. Với tôi chỉ cần có một thư mục chứa file đã tải, rồi một local webserver siêu nhẹ có thể đọc tên video và tạo trang liên kết là đủ. Nếu có lựa chọn siêu nhẹ nào cài bằng vài cú nhấp chuột thì mong được gợi ý
Tôi cũng thắc mắc vì sao với mảng phim trên YouTube họ đã có giải pháp DRM rồi, nhưng vẫn chưa áp dụng công nghệ đó cho toàn bộ kênh
Tôi hơi bất ngờ khi họ chọn Deno, nhưng Deno dễ phân phối dưới dạng single executable nên sẽ giảm rắc rối cài đặt. Trình thông dịch viết bằng Python trước đây là một màn hack rất ấn tượng, nhưng vẫn có giới hạn, và chủ đề này từng được bàn từ thời dự án Youtube-dl thảo luận HN cũ
Node không có các tính năng bảo mật và cô lập như Deno. Có thể xem cả ý kiến của maintainer trong cùng thread đó
Tính năng sandbox của Deno cũng là một lý do quan trọng cho lựa chọn này. Không thể tin tưởng nó 100%, nhưng vẫn tốt hơn là không có gì
yt-dlp không chỉ hỗ trợ YouTube mà còn rất nhiều site streaming video khác, đôi khi còn khá nguy hiểm. Vì vậy mức sandbox tối thiểu kiểu trình duyệt là bắt buộc. Theo thiết kế, nó phải chạy code không đáng tin cậy, nên cần có sẵn mức bảo mật cơ bản