Video
Video processing and outputs
Track asynchronous stages, review generated output and distinguish accepted, terminal, successful and published states.
Follow the stage pipeline
| Stage | Output or role |
|---|---|
| metadata | Reads source timing, dimensions and other media metadata. |
| dts | Object and person analysis, tracking and similarity-backed suggestions. |
| sub | Transcript and subtitle analysis. |
| loc | Location candidates using available visual and subtitle evidence. |
| ocr | On-screen text extraction. |
| thu | Thumbnail generation. |
| compression | Prepares playback media and updates its media metadata. |
Stages run asynchronously and can finish at different times. Location analysis depends on subtitle evidence. Stage completion does not automatically publish the video.
Queue timing and media complexity affect progress. The application shows active stages without converting their weighted progress into a guaranteed ETA.
Keep each status vocabulary scoped
| Source | Vocabulary | Interpretation |
|---|---|---|
| Ingest admission receipt | pending | The backend accepted a revision request. |
| Backend revision facade | pending, processing, succeeded, failed, superseded | Facade-level revision states. Terminal does not mean successful. |
| Ingest revision record | done, partial_failed, failed, superseded plus in-progress states | The processing service’s revision outcomes. Partial failure requires inspection. |
| Owner video/module snapshot | uploaded, queued, processing, done, failed and initial module states | The application projection. Read each module as well as the overall video. |
The upload editor declares completion only when progress is at least 1 and the overall status plus all five module statuses are done.
Any failed module makes the editor show a failure. A finished thumbnail or a playable source cannot establish that all analysis succeeded.
Read an owner processing snapshot
GET /api/videos/<videoId>/processing is a same-origin RapidEye application route. It requires the authenticated application session and verifies video ownership.
async function readProcessing(videoId) {
const response = await fetch('/api/videos/' + encodeURIComponent(videoId) + '/processing', {
credentials: 'same-origin',
cache: 'no-store'
});
if (!response.ok) throw new Error('Processing status HTTP ' + response.status);
return response.json();
}Run this example on the authenticated application origin. A backend bearer token alone does not establish an application cookie session.
| Response field | Meaning |
|---|---|
| video.id | The requested owned video. |
| video.progress | Projected processing fraction. It is not elapsed-time fraction. |
| video.status | Overall video projection. |
| video.status_dts / status_location / status_ocr / status_subtitle / status_thumbnail | Individual module projections. |
| video.fps / width / height | Available media metadata. In-progress snapshots can still contain null values. |
| stages | Latest revision’s stage, status, progress and started_at values. |
| sampledAt | Server snapshot timestamp in milliseconds. |
Responses are private and no-store. The upload editor uses authenticated polling for video and stage snapshots. It does not rely on realtime subscriptions.
Polling uses a 5-second interval with failure backoff up to 30 seconds. Each request has a 10-second deadline.
The poller stops when the video projection reaches done or failed. Stale updates show reconnecting status without inventing a completion estimate.
Review generated and authored output
- Check the media dimensions and playback.
- Review tracked entities and suggested labels.
- Confirm the intended labels and images.
- Review subtitles, on-screen text and location candidates.
- Choose thumbnails and author the video details.
- Publish after the intended content is ready.
Similarity suggestions are candidates from the feature library. They do not prove a brand, person or location identity.
Accepted labels belong to the video’s detections. One manual label can serve several detections. Editing a suggestion’s name can create a manual label.
A label image can come from the tag choice, label default or legacy image. An image upload or label review request is not immediate catalogue publication.
Catalogue curation and vector administration are privileged internal workflows. The owner editor’s label controls do not provide access to those administration APIs.
Recover from admission and stage failures
| Failure point | Supported next step |
|---|---|
| Source transfer failed | Use upload cleanup and transfer controls. No ingest success has been established. |
| Transfer complete, ingest admission failed | Use the upload dialog’s processing-start retry. Keep the owned source and the request identity. |
| Job accepted, module failed | Inspect the module status. The current editor asks for a fresh upload; it does not expose a general stage-retry API. |
| Status read failed | Retry the read with backoff. Do not infer a failed job from one unavailable snapshot. |
| Superseded revision | Observe the latest intended revision. A superseded revision is not a publishable success receipt. |
Worker retry controls are internal. Do not call the processing service directly or create a second job solely because a progress read timed out.
Partial output can remain useful, but it does not establish successful completion. Review the failed modules and current publication requirements.