Improved
Deliver every job output to your bucket
Receive multi-file outputs as folders, structured data as JSON and files of any size in your own bucket, named after the file you started from.
API Dashboard
A connected bucket now receives the whole output of any job. Until today a destination took a single file only. An ffmpeg command that wrote several files, an HLS ladder, a set of frames or an ffprobe result was marked not_deliverable after the job had already run.
For the output path exports/clip.mp4, this is what lands in your bucket:
| The job returns | Written to your bucket |
|---|---|
| One file | exports/clip.mp4 |
| Several files, such as an HLS ladder or image frames | The folder exports/clip/, each file under its own name |
Structured data only, such as ffprobe | exports/clip.json |
A file and structured data, such as captions.animate with captionData | exports/clip.mp4 and exports/clip.json |
What else changed
- No size limit of our own. Large files and long file sets are written in parts over as many attempts as they need. Your bucket’s own limits are the only ones that apply.
{source_name}is the file you started from. An ffmpeg job used to get its job id here, and an uploaded file gotcontent. An ffmpeg job now uses the name of its first input, and an upload uses its original filename.- Keep both covers everything a delivery writes. The output name and the
.jsonbeside it are checked together, and on a clash both move to the suffixed name. A name with a dot in it, such asclip_v1.2, stays whole. - Folders in the dashboard. A folder delivery offers Browse, which opens it in the storage browser, and Copy path. In the API its
pathends in/and it has nourl.
Each destination still gets one delivery per job, and job.delivery_succeeded fires once, after the last file lands. The storage docs list what gets delivered in full, and delivering job outputs to your own bucket covers the feature this extends.