I notice the TV web client (TVHTML5) is currently undergoing an A/B test where the /player endpoint is not used, rather some "onesie" method is used using /initplayback google video URL to get the playback data. I don't really understand how this works, and it seems very obfuscated. As requested I am posting what I've seen here.
It sounds like this method is already used in the Android app for at least the past half year.
Steps to get a reproducible session
Since this is an A/B test, this will only happen sometimes.
set user agent to some TV client (in my user agent switcher I set it to PS4, any will probably do)
Look for a request to https://www.youtube.com/tv_config. In the response you should see onesieHotConfig key. If not, create a new session/clear cookies and retry from 2) again
When clicking on a video, you should see request(s) to /initplayback and not /player*
*except for home page, they still seem to use /player for the ad or whatever?
Request
There is a POST request to the baseUrl (see config below).
Query includes baseUrl params plus some others?
Payload is some sort of encoded, compressed or encrypted data. I'm not sure what, it doesn't seem to be protobuf.
Not sure how it decides what server/subdomain to use (it isn't included in baseUrl). There are requests to redirector.googlevideo.com at times, might be that.
The response also is encoded in some unknown format. The response Content-Type header says "application/vnd.yt-ump"
There does seem to be hints of plaintext data in it, I can see parts of the video playback url subdomain:
There is also periodic requests to the baseUrl with no data. It responds with 204 no content. Might be related to the generate_204 requests seen in the WEB client?
This may have some relation to the youtubei/v1/config Innertube endpoint, which seems to provide some sort of protobuf-encoded "hot" and "cold" config data. I can confirm this is used on the android embedded player, though I'm not entirely sure if it is related to the onesie playback method.
I notice the TV web client (TVHTML5) is currently undergoing an A/B test where the
/player
endpoint is not used, rather some "onesie" method is used using/initplayback
google video URL to get the playback data. I don't really understand how this works, and it seems very obfuscated. As requested I am posting what I've seen here.It sounds like this method is already used in the Android app for at least the past half year.
Steps to get a reproducible session
Since this is an A/B test, this will only happen sometimes.
onesieHotConfig
key. If not, create a new session/clear cookies and retry from 2) again/initplayback
and not/player
**except for home page, they still seem to use
/player
for the ad or whatever?Request
There is a POST request to the
baseUrl
(see config below).redirector.googlevideo.com
at times, might be that.The response also is encoded in some unknown format. The response Content-Type header says "application/vnd.yt-ump" There does seem to be hints of plaintext data in it, I can see parts of the video playback url subdomain:
There is also periodic requests to the baseUrl with no data. It responds with 204 no content. Might be related to the
generate_204
requests seen in the WEB client?Config
The onesieHotConfig contains the following data:
These values all have references throughout the player js (for both tv client and web client). There are references to hmac and IV too. Possibly this method uses some sort of encryption somewhere. https://www.youtube.com/s/player/a515f6d1/tv-player-ias.vflset/tv-player-ias.js
This may have some relation to the
youtubei/v1/config
Innertube endpoint, which seems to provide some sort of protobuf-encoded "hot" and "cold" config data. I can confirm this is used on the android embedded player, though I'm not entirely sure if it is related to the onesie playback method.I don't know how the android app gets the config data.
/player ep response mention of onesie
There are references to this onesie playback method in the /player call. In android client response, there is a "onesieStreamingUrl":
On WEB client, there is mention of an "HTML5 playback onesie":
Similar thing sometimes appears in the TVHTML5 player response (A/B testing again?)
Hopefully someone might be able to figure out what is going on :sweat_smile: