Files
tapir/docs/research/vimeo-captions-feasibility.md
mathiasandClaude Opus 4.8 92da25d01e
CI / Lint / Test / Vet (push) Successful in 6s
CI / Build & Import (push) Failing after 1s
CI / Mirror to GitHub (push) Has been skipped
docs(research): Vimeo + Whisper transcript feasibility findings
Vimeo texttracks API is owner-only (worse than YouTube, no public timedtext) → defer.
Whisper viable as a no-caption fallback; berget/whisper-large-v3 already on the gateway
(cloud), local options on iguana/koala carry setup+GPU-contention cost (ADR-007). Both
investigated inline (session sub-agents are network-sandboxed).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-02 23:14:03 +02:00

53 lines
3.3 KiB
Markdown

# Vimeo — captions/transcripts feasibility for tapir (research, 2026-06-02)
Researched by the Conductor (sub-agents were network-sandboxed). Mapped to tapir's
`VideoSource` port (`ListSubscriptions`, `NewVideos`, `FetchTranscript`).
## Verdict: SAME owner-only wall as YouTube, and WORSE fallback options.
### Q3 (the gating question) — text tracks for videos you DON'T own
- **Official API is owner-only.** Vimeo Help Center: *"You must use a personal token
generated as the account owner of the video in order to access your video's transcripts
via API."* So `GET /videos/{id}/texttracks` returns tracks only for videos the
authenticated account owns — identical to YouTube `captions.download`.
Source: https://help.vimeo.com/hc/en-us/articles/17480150130833
- The text-track `link` points to `captions.cloud.vimeo.com/....vtt?token=...` — a
**token-gated** URL, not a clean public file.
Source: https://developer.vimeo.com/api/reference/response/text-track
- The API is also widely reported flaky (vimeo/openapi#16 "Texttracks API doesn't work as
advertised"). Source: https://github.com/vimeo/openapi/issues/16
### Unofficial fallback — weaker than YouTube's timedtext
- Captions are loadable via the embed player, yielding `[n].vtt?token=...` requests, and
yt-dlp can pull Vimeo subs with cookies. But every documented method needs a
**registered/logged-in viewer** ("you need to be registered in Vimeo to retrieve
subtitles"). There is **no clean unauthenticated public timedtext equivalent** like
YouTube's `captionTracks[].baseUrl`.
Sources: https://gist.github.com/pjmartorell/384aa1d019f919af6b84894038bf29aa ,
https://github.com/vimeo/openapi/blob/master/api.yaml
- **Needs live verification:** whether `player.vimeo.com/video/{id}/config` returns a
`text_tracks[]` with usable token'd URLs for arbitrary PUBLIC videos without owner auth.
Likely partially works for public/embeddable videos but is undocumented and brittle.
### Subscriptions / new videos (the easy part)
- "Following" exists: `/me/following` (users), plus channels/groups feeds; per-user video
lists via `/users/{id}/videos` sortable by date. Maps to `ListSubscriptions`/`NewVideos`.
Source: https://developer.vimeo.com/api/reference
- Auth: OAuth2; many endpoints/scopes and higher rate limits require **app review**, and
some metadata is gated behind paid plans. (Tier/plan gating: needs-verification.)
## Feasibility for tapir
- A Vimeo adapter could do subscriptions + new-video detection fine.
- **Transcripts are the blocker, same as YouTube but harder**: official path owner-only,
unofficial path requires a logged-in viewer (cookie/token), no public timedtext.
- Realistic Stage-0 stance: **defer Vimeo.** YouTube via the timedtext path (ADR-010)
covers the maintainer's actual subscriptions; Vimeo adds a second brittle, auth-gated
caption path for a smaller share of content. If pursued: the cookie'd player-config
method or yt-dlp-with-cookies, behind the same "ToS-grey, opt-in" framing — a future ADR.
- This is consistent with the port design: Vimeo is just another adapter; nothing in the
engine changes when/if it's added.
**Biggest risk:** there is no public, unauthenticated caption path on Vimeo — any
third-party transcript fetch needs a logged-in session/cookie, which is more fragile and
more ToS-exposed than YouTube timedtext.