TurboGrab avatar

TurboGrab

Under maintenance

Pricing

Pay per usage

Go to Apify Store
TurboGrab

TurboGrab

Under maintenance

Pricing

Pay per usage

Rating

0.0

(0)

Developer

Andrew Babo

Andrew Babo

Maintained by Community

Actor 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

opwhat it does
resolvereport the selected video/audio formats and their direct URLs, no download
fullparallel-range download + stream-copy mux into one faststart mp4
full_multidownload only a byte range (options.part={start,end}) of the video — fan out N actors, each on its own exit, then concat client-side
windowsame acquisition, then stream-copy cut every options.segments[] window
capabilitiesops/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 HTTP Range: 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-dlp download and says so in meta.method; the real height is always verified with ffprobe before success.