[nyx]

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.

- 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).

[brigade]

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...)

[nyx]

Good spot, thanks... I'm reading up, more info here: https://github.com/yt-dlp/yt-dlp/wiki/PO-Token-Guide

[perching_aix]

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).

[gruez]

>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?

[brigade]

No, anything above 720p which is the best you can get for low-trust clients

[hoseja]

The "1080p premium" is such a joke. Unlike videos where it isn't present, the "normal 1080p" on such videos has noticeably decreased bitrate.

[russelg]

No, that is still very much locked behind a valid user token.