In summary, YouTube is A/B testing a change where specific clients receive only DRM-locked video streams. This is notable because yt-dlp impersonates those clients during normal operation. Since yt-dlp won't support decrypting DRM-locked videos, this change breaks yt-dlp's ability to download any videos.
To respond to your specific questions:
- innertube is the name for private YouTube APIs. (Here's a library that talks to innertube https://github.com/tombulled/innertube/, although yt-dlp has its own separate client code.) These APIs are intended for consumption by the various types of YouTube client software.
- TVHTML5 is the specific client (as opposed to e.g. TVLITE or TVANDROID)... presumably different TVs run different specific TV clients, with consumption of different specific TV APIs.
- When yt-dlp downloads a video, it roughly performs this sequence of steps: pretend to be one of the types of clients supported by innertube; download the top-level video object; parse out the list of possible formats. These formats are like "MP4, 1080p, with AAC audio" or "Ogg, audio only". (The original issue report shows a better example in the verbose output dump.) By default, yt-dlp just grabs the best quality audio and best quality video stream, downloads them, and muxes them together into a single file, but you can configure this behavior. DRM formats are formats that are protected by (presumably) Widevine: https://en.wikipedia.org/wiki/Widevine, the decryption of which yt-dlp has stated will not be supported.
- Available means they're an option for our yt-dlp client to download. Videos don't necessarily have all formats for all clients; for instance, a video might not have a 4K option, because it was never uploaded in 4K. Or it might have a 4K upload, but YouTube won't show 4K options to a client that doesn't support 4K decoding.
- In this case, it means this specific internal client type can't download the video, because when yt-dlp reaches out, it gets ONLY formats that are DRM-locked. This is of note, I think, because the TV client is a way to get high-quality video from the YouTube API without having to pass it a valid YouTube login token (further down the issue, the reporter says providing a token allows the "web" innertube client to work).
Not a login token, but rather an attestation token. Presumably TV clients don't really have a good mechanism for attestation that isn't tied to DRM (web technically doesn't either, but the web code can be updated daily...)
This is very helpful, thank you. Also cleared up a misinterpretation I had along the way (my initial reading that maybe only DRM format information is supplied but no content, indicating a minor breakage e.g. due to API changes - a very different nature of issue).
>This is of note, I think, because the TV client is a way to get high-quality video from the YouTube API without having to pass it a valid YouTube login token
Are you talking about the "1080p premium" quality tier that you normally have to pay to get?
Low trust as in intended to be used by 3rd parties without Javascript or any form of attestation. Like the Wii U client or I think the iframe embeds at one point.
(maybe they've all been killed by now, I haven't been paying too much attention...)
Then what's the "high quality" video? Anyone can use the web interface of youtube and watch it without any DRM (for now). Why are they so jellously guarding one specific API when the others are wide open?
To respond to your specific questions:
- innertube is the name for private YouTube APIs. (Here's a library that talks to innertube https://github.com/tombulled/innertube/, although yt-dlp has its own separate client code.) These APIs are intended for consumption by the various types of YouTube client software.
- The "tv" client is one of the types of client (see other examples here: https://github.com/tombulled/innertube/blob/main/innertube/c...)
- TVHTML5 is the specific client (as opposed to e.g. TVLITE or TVANDROID)... presumably different TVs run different specific TV clients, with consumption of different specific TV APIs.
- When yt-dlp downloads a video, it roughly performs this sequence of steps: pretend to be one of the types of clients supported by innertube; download the top-level video object; parse out the list of possible formats. These formats are like "MP4, 1080p, with AAC audio" or "Ogg, audio only". (The original issue report shows a better example in the verbose output dump.) By default, yt-dlp just grabs the best quality audio and best quality video stream, downloads them, and muxes them together into a single file, but you can configure this behavior. DRM formats are formats that are protected by (presumably) Widevine: https://en.wikipedia.org/wiki/Widevine, the decryption of which yt-dlp has stated will not be supported.
- Available means they're an option for our yt-dlp client to download. Videos don't necessarily have all formats for all clients; for instance, a video might not have a 4K option, because it was never uploaded in 4K. Or it might have a 4K upload, but YouTube won't show 4K options to a client that doesn't support 4K decoding.
- In this case, it means this specific internal client type can't download the video, because when yt-dlp reaches out, it gets ONLY formats that are DRM-locked. This is of note, I think, because the TV client is a way to get high-quality video from the YouTube API without having to pass it a valid YouTube login token (further down the issue, the reporter says providing a token allows the "web" innertube client to work).