[YouTube] Cannot get streams of playlists with only shorts

[AudricV]

With the rollout of the sort by oldest feature on the new filtering system, YouTube also added filters to filter playlists, allowing users to filter videos and shorts inside playlists.

When shorts filter is enabled or when there are only shorts in a playlist, YouTube return shorts UI elements instead of standard video ones, the ones that are also used for shorts shelves in searches and suggestions and shorts in the corresponding channel tab.

Short UI elements (reelItemRenderers) don't include any information about shorts' upload date, shorts' uploader name and shorts' uploader URL; their duration needs to be parsed from accessibility data and their view count extracted is not exact.

The data structure has changed, switching from playlistVideoListRenderers and playlistVideoRenderers to richGridRenderers and richItemRenderers + reelItemRenderers respectively), so extraction of playlists in this case returns no streams. reelItemRenderers are also not supported by the extractor.

The shorts playlist UI doesn't give any continuation when there are more than 100 shorts in a playlist. This seems to be a bug on YouTube's side.

I think we have three possibilities to fix or mitigate the issues these changes raised:

• use a mobile client (MWEB, ANDROID and probably IOS), on which filters are available but video UI is returned by default when there are only shorts in a playlist; (edit: shorts UI returned and forced for some playlists)
• use the TVHTML5 client, where no filters and no precise view count are available (only human ones such as 1k views are returned);
• keep the desktop variant and support reelItemRenderers, even if we loose a lot of information.

[Theta-Dev]

Using the mobile client is a solution at the moment, but since this is a A/B test, I dont think that will work permanently. If YouTube wants their crippled shorts UI, they are going to implement it everywhere.

I guess we need to support reel item renderers for playlists, even though we'll lose a lot of metadata.

[AudricV]

I also found that currently, if we use a continuation to request the first page, regular video items and continuations are returned for these playlists! The new playlist header isn't returned in this case though.

Here is the protobuf schema for playlists continuations:

syntax = "proto3";

message PlaylistContinuation {
  PlaylistContinuationParameters parameters = 80226972;
}

message PlaylistContinuationParameters {
  string browseId = 2;
  string continuationProperties = 3; // A PlaylistContinuationProperties message encoded as a Base64 string
  string playlistId = 35;
}

message PlaylistContinuationProperties {
  int32 requestCount = 1;
  // The playlist response starts at 0 if this field is omitted
  string playlistIndexParameterProtoBase64 = 15; // An optional string "PT:" with a PlaylistIndexParameter message encoded in Base64 appended at the end
  ContentFiltersParameters contentFilters = 104;
}

message PlaylistIndexParameter {
  int32 index = 1; // The index cannot be 0 and should be a 100 multiplier (YouTube backends return that requests contain an invalid argument otherwise)
}

// Parameters hideUnavailableVideos and showOnlyVideos can be used at the same time, but no videos would be returned in this case
message ContentFiltersParameters {
  int32 hideUnavailableVideos = 1;
  int32 showOnlyVideos = 2;
  int32 showOnlyShorts = 3; // Parameter works but doesn't return a Shorts UI as of 08/12/23 (American English date format)
}

I suspect that this workaround will stop working if YouTube start to provide continuations to these playlists.