2

I'm writing this app right now and one of its components is using the LiveChatMessages resource's list method to retrieve all the live chats in a stream. My issue is not with the functionality itself, the youtube documentation was quite clear regarding this (hats off to the youtube engineers if you're reading this).

My question instead is regarding the quota system. In my journey to figuring this out, I went to the holy grail of youtube data API quotas first aka the documentation. It led me to this page:

https://developers.google.com/youtube/v3/determine_quota_cost

Now, this has the information for all the quota for various Youtube Data API resources except for the LiveChatMessages resource. Ironically, the text at the top says:

YouTube Live Streaming API methods are, technically, part of the YouTube Data API, and calls to those methods also incur quota costs. As such, API methods for live streaming are also listed in the table.

And yet the table does not even mention anything regarding the LiveStreaming API. Now, I kind of just glossed past this and from the context of all the other methods and assumed that it only incurred one quota.

I ran my app on a mid-scale stream of around 500 viewers at the time and the quota ran out in way less time than I expected. Now, I'm not sure whether I understood the quota cost correctly or the LiveChatMessages.list method had a completely different quota system.

But my app queried the LiveChatMessages.list method every 5 seconds. Which meant that it would incur 12 quota costs every minute, 720 quotas cost every hour. And since I had a quota limit of 10,000. I assumed it would be able to handle over 13 hours of live streaming without the quota capping out. But instead, it would only be about a few hours before the quota capped over.

Anyways hopefully a youtube engineer sees this and can tell me what the quota mechanics are like for the LiveChatMessages.list method because the documentation does not really mention it.

Improve this question
1
  • Indeed this is a known documentation issue of the API. I'd suggest to file a bug report directly to Google, through its own issue tracker site. Commented Apr 23, 2021 at 16:45

1 Answer 1

Reset to default
4

Short answer

By my calculation, the number of quota points consumed by a LiveChatMessages.list request is 5 points.

Explanation

The 5 point request cost is based on a back-calculation of the total query cost over one day of API access. A sample YouTube application looks for the latest live broadcast and retrieves all live messages from chat on a regular interval. After a day of running, visit the google cloud platform quotas section and identify the Queries per day quota of the YouTube Data API v3 service. This screenshot shows that the current usage of the daily quota is 8,180:

2

Now, visiting the YouTube API metrics, we can obtain a breakdown of the API calls by type:

num calls service call type
45 youtube.api.v3.V3DataLiveBroadcastService.List
1,627 youtube.api.v3.V3DataLiveChatMessageService.List

How do 45 + 1,627 = 8,180? 5 point factor for chat message list requests:

8,180 quota points = 5x(1627 message list requests) + 1x(45 broadcast requests)

Practical limits of the Youtube API 10,000 point quota

As I pointed out in the issue tracker, this limit seems lovw. For an application that interacts with live chat by making a request each 1s:

(10,000 points) / (5 pts/request) / (1 request/s) / (60 min/hr) = 33 minutes

Consider the extreme boundary case: if a live stream runs for 24 hrs/day, how many live chat requests can the quota support?

(5 pts/request) / (10,000 points/day) * (24 hr/day) * (3600 s/hr) = 43.2 s/request

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

@stvar Thanks for mentioning the bug tracker, looks like there's an issue at issuetracker.google.com/186302489. The bug is currently marked 'Status:​Assigned, Won't Fix (Infeasible)'. Does this mean we shouldn't wait up for a change of the API? Is scraping the chat a better option for live interactivity?
in my experience, @deliciousavocado, Status:​Assigned, Won't Fix (Infeasible) is unfortunately undecided, since time and again bugs in the API proper or in the docs are marked as such, while there's no fix provided at the time of closing the ticket (quite often accompanied with the mantra we don't have an ETA for the fix). They may or may not fix that issue. For example, this issue is still not fixed one year after it being reported.
The scraping option: technically it may well be better, @deliciousavocado; I cannot tell precisely since not tried it. But if you were to observe the specifications of DTOS (you're compelled to do so in case you need your app to be successfully audited by Google), then you'll find that scraping is forbidden activity (section III.E.6 of that doc).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.