TurboGrab
Under maintenancePricing
Pay per usage
TurboGrab
Under maintenancePricing
Pay per usage
Rating
0.0
(0)
Developer
Andrew Babo
Maintained by CommunityActor stats
0
Bookmarked
416
Total users
152
Monthly active users
a day ago
Last modified
Categories
Share
High-speed, high-quality video acquisition for the Super Clipping pipeline.
TurboGrab resolves a page URL once, picks the best h264 video-only format plus the best
audio-only format, then pulls both in parallel with many &range= chunk requests over the
same sticky exit IP, and stream-copy muxes a faststart mp4.
Measured on a 57-minute source (2026-09-04): 1 connection 17.9 MB/s, 16 parallel chunks 246.7 MB/s. Whole 1080p h264 video (283 MB) + audio (55 MB) + mux = 8.3 s, versus 230 s for the previous hosted 1080p route.
Operations
| op | what it does |
|---|---|
resolve | report the selected video/audio formats and their direct URLs, no download |
full | parallel-range download + stream-copy mux into one faststart mp4 |
full_multi | download only a byte range (options.part={start,end}) of the video — fan out N actors, each on its own exit, then concat client-side |
window | same acquisition, then stream-copy cut every options.segments[] window |
capabilities | ops/features/vcpus, needs no source |
full_multi — multi-actor fan-out
Each call downloads only options.part = { start, end } bytes of the selected video format.
Set options.audio = true on one call to also fetch the full audio (55 MB, small enough for
one exit). The client opens N actors in parallel, each resolving its own signed URL (bound to
its own exit IP), downloads its byte range, and concatenates the parts with ffmpeg concat.
Input
{"op": "full","source": "https://www.youtube.com/watch?v=VIDEO_ID","options": {"min_height": 720,"max_height": 1080,"prefer_codec": "h264","lanes": 16,"chunk_mb": 8,"proxy_ladder": ["direct", "DATACENTER", "RESIDENTIAL"],"allow_ytdlp_fallback": true}}
For op=window add options.segments: [{ "start_sec": 120, "end_sec": 165, "name": "clip_01" }].
Output
One dataset row and a RESULT key-value record:
{"ok": true,"op": "full","artifacts": [{ "name": "source", "kv_key": "source.mp4", "url": "https://...", "bytes": 339300000 }],"meta": { "method": "ranged", "lane": "direct", "selected": { "video": { "height": 1080 } }, "probe": { "height": 1080 } },"timings": { "downloadMs": 6500, "muxMs": 1670, "totalMs": 8250 }}
Failures never report success: reason is one of QUALITY_TOO_LOW, UPSTREAM_BLOCKED,
TIMEOUT, OOM_LIMIT, BAD_INPUT, INTERNAL.
Notes
- The byte window goes in the URL (
&range=), never as an HTTPRange:header — the header form hits Google's per-connection throttle. - Resolve and every chunk share one proxy lane, because the signed media URL is IP-bound.
prefer_codec: "h264"is the default on purpose: downstream render lanes stream-copy h264, so a vp9/av1 pick would trade seconds of download for minutes of transcode.- If the ranged path fails, the actor falls back to a plain
yt-dlpdownload and says so inmeta.method; the real height is always verified with ffprobe before success.