YouTube đang thêm DRM vào mọi video dùng client TV (TVHTML5)
(github.com/yt-dlp)- Đã quan sát thấy một thử nghiệm hoặc A/B test trên một số tài khoản YouTube: khi đăng nhập bằng YouTube on TV, ngay cả video thông thường cũng chỉ nhận được các định dạng DRM từ client TVHTML5 Innertube
- Hiện tượng này không chỉ giới hạn ở yt-dlp; khi dùng cùng tài khoản để thử các client YouTube TV chính thức như PS3, trình duyệt web, Apple TV, các định dạng video cũng chỉ được cung cấp dưới dạng DRM
- Hiện tại, yt-dlp khi yêu cầu dữ liệu video YouTube có hoạt động giống YouTube on TV, nên với các tài khoản nằm trong diện thử nghiệm này, ngay cả video thông thường cũng bị xử lý với lỗi
This video is DRM protected - Nhật ký tái hiện cho thấy khi truy vấn video
aqz-KE-bpKQbằng cookie Firefox và thiết lậpyoutube:player-client=tv, sẽ phát sinh lỗi bảo vệ DRM; nếu dùng tùy chọn dành cho nhà phát triển để hiển thị các định dạng không thể phát, sẽ thấy nhãn DRM gắn trên hầu hết các định dạng âm thanh và video - Vấn đề này hiện đã được đóng; trang có liên kết tới các PR liên quan là #14122 và #13539, nhưng phần nội dung không nêu cách sửa cụ thể hay thay đổi hành vi cuối cùng
Một số tài khoản chỉ nhận được định dạng DRM từ client TV
- Đã có báo cáo rằng trên một số tài khoản YouTube, các video thông thường chỉ có định dạng DRM khi dùng client Innertube
tvhoặc TVHTML5 - Có vẻ vấn đề này là thử nghiệm hoặc A/B test mà YouTube đang áp dụng cho một số tài khoản, không thể khẳng định là áp dụng cho mọi người dùng
- Trong phần giải thích làm rõ, một số tài khoản đăng nhập vào YouTube on TV cho thấy mọi video YouTube đều như thể được bảo vệ bằng DRM
- YouTube on TV là giao diện hoặc ứng dụng dành cho màn hình lớn dùng trên TV, máy chơi game console, v.v.; có thể truy cập tại
https://www.youtube.com/tvbằng user agent của TV hoặc máy chơi game console
Ảnh hưởng tới yt-dlp
- Hiện tại, yt-dlp có cách yêu cầu dữ liệu video YouTube theo kiểu YouTube on TV, nên bị ảnh hưởng bởi thử nghiệm này
- Với tổ hợp tài khoản đó và client
tv, yt-dlp sẽ coi cả video thông thường là video được bảo vệ DRM - Lệnh tái hiện sử dụng cookie của trình duyệt Firefox và ép dùng client TV bằng
--extractor-arg youtube:player-client=tv- URL mục tiêu là
https://www.youtube.com/watch?v=aqz-KE-bpKQ - Phiên bản yt-dlp trong nhật ký là
nightly@2025.03.07.232704 - Kết quả thực thi là
ERROR: [youtube] aqz-KE-bpKQ: This video is DRM protected
- URL mục tiêu là
Kết quả tương tự ngay cả trên các client YouTube TV chính thức
- Khi thử nhiều client YouTube TV chính thức bằng cùng một tài khoản, kết quả vẫn chỉ có các định dạng DRM
- PS3
- Trình duyệt web
- Apple TV
- Vì vậy, hiện tượng quan sát được không chỉ là vấn đề triển khai riêng của yt-dlp
Danh sách định dạng được xác nhận bằng tùy chọn nhà phát triển
- Sau khi làm cho các định dạng DRM hiển thị theo cách cần sửa mã, dùng tùy chọn
--allow-unsẽ in ra danh sách các định dạng không thể phát - Trong danh sách được in ra, hầu hết các mục âm thanh và video đều có nhãn DRM
- Định dạng chỉ âm thanh
m4a:148,149,148-drc,149-drc - Định dạng chỉ video
mp4vàwebm: bao gồm từ 144p tới 2160p60 - Ví dụ, định dạng
558được hiển thị là3840x2160 60fps,vp9, khoảng1.27GiB,DRM, 2160p60, TV, webm_dash
- Định dạng chỉ âm thanh
--allow-unlà tùy chọn dành cho gỡ lỗi của nhà phát triển; nhật ký đầu ra có kèm cảnh báo rằng đã yêu cầu liệt kê hoặc tải xuống các định dạng không thể phát
1 bình luận
Các ý kiến trên Hacker News
Cần có lời giải thích rằng vấn đề này thực sự có nghĩa là gì
Điểm tranh luận cốt lõi trải rộng qua những khái niệm mà ngay cả độc giả phổ thông có hiểu biết kỹ thuật cũng khó nắm bắt, nên cuối cùng mọi người có khả năng chỉ bám vào vài từ khóa và cuộc thảo luận sẽ đi theo hướng kém hiệu quả
Cụ thể, tôi thắc mắc về innertube client, innertube client
tv, TVHTML5, “định dạng DRM”, việc định dạng đó “khả dụng” nghĩa là gì, và tại sao điều đó lại quan trọng khi nó chỉ được cung cấp cho tv innertube clientLý do điều này quan trọng là vì yt-dlp, trong quá trình hoạt động bình thường, giả lập các client đó; mà yt-dlp dự kiến sẽ không hỗ trợ giải mã video bị khóa DRM, nên thay đổi này có thể làm hỏng việc tải xuống mọi video
innertube là tên của API YouTube không công khai, được tạo ra để nhiều loại phần mềm client YouTube sử dụng. Một thư viện ví dụ là https://github.com/tombulled/innertube/, còn yt-dlp có mã client riêng
Client “tv” là một trong các loại client; có thể xem ví dụ tại https://github.com/tombulled/innertube/blob/main/innertube/c...
TVHTML5 là một client cụ thể, khác với những thứ như TVLITE hay TVANDROID, và có vẻ mỗi TV dùng một client TV cụ thể cùng một API TV cụ thể
Khi yt-dlp tải video, đại khái nó giả vờ là một trong các client mà innertube hỗ trợ, nhận đối tượng video cấp cao nhất, rồi phân tích danh sách các định dạng khả dụng. Định dạng ở đây là những thứ như “MP4, 1080p, kèm âm thanh AAC” hoặc “Ogg, chỉ âm thanh”. Theo mặc định, yt-dlp tải luồng âm thanh chất lượng cao nhất và luồng video chất lượng cao nhất rồi ghép thành một tệp, nhưng có thể thay đổi bằng cấu hình
Định dạng DRM có lẽ là định dạng được bảo vệ bằng Widevine https://en.wikipedia.org/wiki/Widevine, và yt-dlp đã nói rằng họ sẽ không hỗ trợ giải mã nó
“Khả dụng” nghĩa là client yt-dlp nhìn thấy nó như một lựa chọn để tải xuống. Không phải mọi video đều cung cấp mọi định dạng cho mọi client; nếu video không được upload ở 4K hoặc client không hỗ trợ giải mã 4K, tùy chọn 4K có thể không xuất hiện
Trong trường hợp này, điều đó có nghĩa là loại client nội bộ cụ thể này không thể nhận video. Vì khi yt-dlp gửi yêu cầu, nó chỉ nhận được các định dạng bị khóa DRM. Điều này đáng chú ý vì TV client là cách để lấy video chất lượng cao từ YouTube API mà không cần token đăng nhập YouTube hợp lệ. Ở phần dưới của issue, người báo cáo nói rằng nếu cung cấp token thì innertube client “web” hoạt động
Tình hình hiện tại rốt cuộc là do mọi người hài lòng với trạng thái này
Nhiều người thấy ổn với việc không sở hữu phim, album, sách, và không hiểu ý nghĩa của điều đó. Những người hiểu thì chỉ là thiểu số
Tôi không phản đối bản thân streaming, nhưng mọi nhà cung cấp nên đưa ra tùy chọn sở hữu một bản sao kỹ thuật số hợp pháp với giá hợp lý. Ở đây, sở hữu nghĩa là có một tệp media đơn giản không DRM và có thể phát ở nơi mình muốn
Trả tiền để sở hữu thứ gì đó thì hoàn toàn không có vấn đề gì, nhưng cho đến khi điều đó xảy ra, tôi sẽ không trả cho các công ty kiểu này một xu nào
Nếu giả sử 2 tỷ người streaming, thì 2.000.000.000 × 1095 = 2.190.000.000.000g, tức 2,19 triệu tấn CO2 không cần thiết
Cũng có thể nhìn theo kiểu vi phạm bản quyền chỉ cần một lần là xong nên thân thiện với môi trường hơn, và có thể cứu Trái Đất
Tôi đã viết một script dùng yt-dlp để tải các kênh đã đăng ký, chuyển sang mp3, rồi cung cấp podcast feed trong mạng nội bộ, nhờ đó đã giảm đáng kể thời gian dùng ứng dụng YouTube
Nếu một ngày nào đó nó hỏng, có lẽ tôi sẽ phải ra ngoài trong thời gian rảnh, nhưng hiện giờ nó vẫn chạy nên mong là trụ được đến mùa xuân
Tò mò không biết bạn dùng công cụ nào ngoài yt-dlp. Ví dụ muốn biết bạn dùng gì để tạo và host RSS feed
Đây đúng là tin khủng khiếp
Việc chuyện này sẽ đến là khá rõ ràng, và có vẻ cũng khá rõ rằng đây là một phần trong chiến lược cấp rất cao của Google. Google đã đầu tư rất mạnh vào tất cả những phần này trong nhiều năm, ở cả phía client lẫn server
Với tôi thì nó có mùi enshittification, nhưng rộng hơn thế, có vẻ như chúng ta sắp bước vào một kỷ nguyên của công nghệ bị khóa chặt và đóng kín. Nhìn vào toàn cảnh, YouTube không có DRM thậm chí còn có cảm giác như một thứ lỗi thời
Phần lớn mọi người sẵn sàng mua các thiết bị hạn chế nghiêm trọng những gì họ có thể làm, nên tôi cũng không kỳ vọng sẽ có phản ứng thực chất nào từ người tiêu dùng. Những người thật sự bận tâm đến chuyện này có lẽ sẽ phải đối mặt với lựa chọn: tự tách mình khỏi thế giới số và chấp nhận thiếu thốn vì nguyên tắc, hoặc bị ép vào cùng một chiếc hộp với nhóm người dùng mẫu số chung thấp nhất
Nếu giả định ban lãnh đạo Google không có ác ý, tôi cũng tự hỏi liệu AI có phải là phát súng kích hoạt cuối cùng hay không. Để tạo hào phòng thủ cho Gemini, họ phải ngăn những bên thu thập dữ liệu truy cập video YouTube, và cách “thật sự” duy nhất để bảo đảm điều đó là gắn DRM. X/Twitter, Reddit, Stack Overflow, v.v. cũng đã có các động thái tương tự vì lý do tương tự. Dù sao thì đây có lẽ cũng là việc họ vốn muốn làm, nên AI có thể là cái cớ hơn là lý do, nhưng chắc chắn không phải là một yếu tố vô nghĩa
Chúng ta đang như những con ếch tự đổ thêm nhiên liệu vào cái nồi của chính mình
Trước đây, DRM từng được xem là xung đột với trình duyệt vì nó không đại diện cho người dùng. Nếu DRM thật sự cần thiết, phía nền tảng phải tự nhồi nhét nó vào bằng một plugin bên ngoài như Silverlight
Khi Firefox đưa phần mở rộng EME vào, tôi đã xem đó là khởi đầu của hồi kết. Nếu biến DRM thành một công tắc có thể bật lên, nó sẽ trở thành tiêu chuẩn chứ không còn là ngoại lệ. Từ nhiều năm trước đã có cả những đề xuất lố bịch như DRM cho phông chữ. Nếu một công ty khăng khăng đòi DRM, thì công ty đó phải gánh lấy chi phí phát sinh từ việc bắt trình duyệt làm điều mà về nguyên tắc nó không nên hỗ trợ
Cơn ác mộng mà chúng ta đang lao tới là một thế giới nơi mỗi lần chỉ có thể cache được một lượng video rất nhỏ, và phần cứng chứng thực TPM phải đưa token vào mọi yêu cầu HTTP. Trình duyệt khi đó chỉ còn là một hộp truyền hình cáp bằng phần mềm
Họ cũng không thích URL, và nếu bạn muốn chia sẻ thứ gì đó, họ sẽ muốn buộc bạn làm theo điều kiện của họ, chẳng hạn tạo URL từ trong ứng dụng kèm hash hết hạn và giới hạn lượt xem. Tất nhiên các influencer có thể vẫn còn đặc quyền chia sẻ không giới hạn
Trong 10 năm qua, hạ tầng kiểu này đã được âm thầm đặt xuống, và chúng không phải là những bất tiện riêng lẻ mà là những chiếc đinh đóng vào quan tài
Cũng có những client YouTube bên thứ ba khá tốt như GrayJay https://grayjay.app/
Các ứng dụng kiểu này cho phép theo dõi nhà sáng tạo từ nhiều nền tảng video trong một ứng dụng, điều này bất lợi cho sự phụ thuộc vào YouTube mà Google mong muốn
Trong một thời gian, itag 18 và 22, vốn là video MP4 có kèm track âm thanh, đã biến mất, và có vẻ các định dạng chỉ có video như itag 136 và 137 được ưu tiên hơn
Trong trường hợp này phải dùng ffmpeg để ghép track âm thanh với video. Gần đây có vẻ itag 18 đã quay trở lại
Ví dụ:
yt-dlp -f 137+140 '[https://www.youtube.com/watch?v=dQw4w9WgXcQ](<https://www.youtube.com/watch?v=dQw4w9WgXcQ>;)'Có vẻ YouTube đang chống lại việc tải video xuống
Khi dùng Tor, mỗi ngày tôi đều nhận được thông báo “hãy đăng nhập để chứng minh bạn không phải bot”, còn không có Tor thì tôi không thể truy cập YouTube. Xem quảng cáo hoặc giải captcha thì cũng được, nhưng YouTube đã chọn cách tệ nhất
Không cần xác thực hẳn, nhưng phải chọn hồ sơ
Chuyện này bắt đầu từ vài tháng trước và tôi không nghĩ nhiều, nhưng giờ nhìn lại thì hành vi này có thể là dấu hiệu báo trước cho đợt thúc đẩy DRM mới
YouTube mỗi ngày lại cho thêm nhiều lý do để phải tránh hoàn toàn
Vừa đúng lúc, ở đây YouTube cũng chào tôi bằng câu “hãy đăng nhập để xác nhận bạn không phải bot nhằm bảo vệ cộng đồng”
Có nhiều cách để siết dây xích
Đáng tiếc là sẽ có những người tuyệt đối không tạo tài khoản, và có những người tuyệt đối không dùng bất kỳ hệ thống DRM nào. Chúng ta cần tìm cách truy cập gián tiếp kho tư liệu phong phú đó
Tôi muốn được gợi ý các lựa chọn thay thế YouTube để khám phá nhạc lofi hoặc synthwave
Nếu mua album, bạn có thể nhận bản tải xuống không DRM
https://bandcamp.com/discover/electronic+synthwave
https://www.di.fm/search?q=lofi
Tôi thắc mắc người dùng Firefox sẽ ra sao
DRM mà Firefox hỗ trợ khá dễ bị bẻ khóa, vậy YouTube có ngừng hỗ trợ Firefox không?
Trong https://github.com/yuliskov/SmartTube/issues/4444 cũng thấy trên video “chỉ dành cho hội viên”, nhưng cũng không phải mọi video
Có lẽ họ đang nói đến khác biệt giữa DRM phần mềm và DRM phần cứng, như Widevine L3 và L1, PlayReady SL2000 và SL3000, nhưng đây không hẳn là cục diện Firefox đối đầu Chrome. Được biết Firefox cũng đã từng làm việc về khả năng dùng DRM phần cứng trên Windows, có lẽ thông qua Media Foundation API
Kịch bản xấu nhất, như thấy ở các dịch vụ như Netflix, là chỉ cung cấp chất lượng thấp cho các trình duyệt chỉ dùng được DRM phần mềm như Firefox, còn chất lượng cao hơn thì mã hóa bằng khóa chỉ có thể lấy được qua DRM phần cứng. Tuy nhiên, không rõ YouTube hiện có đi xa đến mức đó không. Netflix hay Amazon có hợp đồng với chủ sở hữu quyền yêu cầu các biện pháp bảo vệ như vậy, nhưng may là YouTube dường như không có cùng kiểu quan hệ và hợp đồng đó với các “YouTuber”
Có vẻ điều YouTube muốn hiện nay là giảm mạnh số người xem nội dung mà không thông qua website hoặc ứng dụng, tức là những người không xem quảng cáo. Khả năng cao họ nhắm đến nhóm đông hơn rất nhiều dựa vào các trang YouTube-to-mp3 hoặc những công cụ dễ dùng tương tự, hơn là người dùng yt-dlp
Chỉ riêng việc bắt buộc DRM phần mềm cũng có thể làm hỏng các công cụ đó, ít nhất là tạm thời, và kéo người dùng quay lại nền tảng. Và nếu cơ chế “vượt qua mã hóa” được đưa vào công cụ, có lẽ họ cũng có thể kiện nhà phát triển, nhưng tôi không phải chuyên gia pháp lý
Khi đó, rất có khả năng yt-dlp sẽ không còn được host trên GitHub, cũng như không thể được phân phối qua kho apt, pip, Homebrew, v.v.
Liên quan đến việc này, TubeArchivist vừa phát hành v0.5, và về chính thức thì chưa ở trạng thái đóng băng tính năng