Batching videos

There is no separate batch endpoint. videos is a list on every submission, so batching means passing a longer one — nothing about the call changes between one video and two hundred.

It is worth doing. Each video is still extracted on its own, so one video without captions cannot fail the other ninety-nine, but sending them together lets us fetch caption tracks for the whole list in one upstream call. That is where most of the wall-clock time in a large run goes: measured on a 100-video run, batching the fetches took the average from 30–40 seconds a video down to about 15.7.

One id means one call to poll, not one per video. counts shows where the job has got to; when queued and processing reach zero the job has settled and results arrives with it.

A single call carries at most 200 videos. Over that it is refused outright with batch_too_large and the message 200 video limit per batch exceeded — nothing is queued and nothing is charged, so splitting the list and resubmitting is safe. Split on your side into calls of 200 and run them alongside each other.

A job hands over its rows once every video in it has settled, not one at a time. That is why polling costs nothing: while anything is still running, results is null and there is nothing to consume by accident.

The consequence for a long run is that the whole list is handed over in one response. If you want rows sooner than that, send smaller calls — fifty videos at a time settles five times sooner than two hundred, at the same price per video.