Video asset management: a practical workflow

Video asset management should make it clear which file to reuse, what it contains and why it is worth keeping. Preserve authoritative sources, identify meaningful edits and record the context people need to find them. Keep video encoding and viewer playback as separate responsibilities, even when the systems connect.

Why video libraries get messy quickly

One project can leave behind camera footage, an editing project, a finished master, social cuts, language versions and playback encodes. Copying these into the same library without explaining their purpose makes the next reuse decision harder.

campaign-master.mov
campaign-master-final.mov
campaign-master-final-v2.mov
campaign-1080.mp4
campaign-social-9x16.mp4
campaign-social-9x16-captions.mp4
campaign-fr-final.mp4

These names suggest differences but leave important questions unanswered. Which master is authoritative? Does the French file have translated audio, subtitles or both? Is the 1080 export a delivery copy or the only retained final cut?

Video duplication can also be costly in storage and transfer effort. The useful response is to record each file's role and relationship before deciding what to upload, retain or remove.

Asset management, processing and streaming are different jobs

A media library can store and describe a video without generating its playback variants. A transcoder can create encodes without knowing which campaign owns the edit. A streaming platform can serve an encoded cut without preserving the materials needed to revise it.

Choose the systems around those responsibilities. Uploading a video file to a DAM does not, by itself, create an adaptive streaming service.

Separate masters, editorial derivatives and delivery representations

Master or source

Identify the authoritative file worth preserving. Specify whether master means camera-original footage, a high-quality finished export or another source used for future work. A project can need both original footage and a finished master; the label should explain which purpose each serves.

For future editing, record where the project file and required source media live. A finished movie file may not be enough to reproduce a different cut. Keep the dependencies needed for the kind of reuse you expect.

Editorial derivative

An editorial derivative contains a meaningful change: a shorter social cut, a deliberately reframed vertical edit, a translated version, a captioned export or a product-specific sequence. It can deserve its own asset record because someone may need that exact variant again.

Record the source it was based on and what changed. A vertical cut with different timing and composition has a different business purpose from an automated resize of the same edit.

Delivery representation

A delivery representation is generated primarily for playback or distribution, such as another bitrate or resolution of an existing edit. It may be reproducible from the retained source and encoding configuration.

Classify by purpose, not extension. An MP4 can be the authoritative finished asset or a disposable encode. Ask whether the file contains meaningful editorial work, and whether recreating it is actually possible at an acceptable cost.

Decide which files deserve long-term storage

Preserve sources where future editing or reuse is expected, important editorial variants and versions that are difficult to recreate. Also retain files required by the organization's contractual, legal or operational policies.

Temporary proxies, redundant exports and purely technical encodes are candidates for regeneration instead of permanent retention. That choice depends on render time, source availability, production tools and the cost of rebuilding the output. An expensive encode may still be worth retaining.

Before deleting a supposedly reproducible file, confirm that the source, project dependencies and export settings remain available. Test regeneration for an important output. A filename containing temp or old is insufficient evidence that a file is disposable.

Assign someone to retention decisions and record the reason for keeping an exception. License expiry should trigger an appropriate review of use and retention, not an assumed automatic deletion rule. The digital asset rights guide explains why source control and downstream copies require separate decisions.

Track technical and business metadata separately

Technical metadata describes the media: duration, frame dimensions, frame rate, container, video and audio codecs, bitrate, file size and available audio or subtitle tracks. Record the properties that affect editing, compatibility or delivery.

Container and codec are different concepts. MP4 and MOV are containers; H.264, HEVC and AV1 are video codecs. The audio stream has its own codec. A file extension alone does not establish playback compatibility. MDN's container reference explains how those components fit together.

Inspection tools such as ffprobe can report container and stream information. Whether those results enter the asset record automatically depends on the library and its integrations. Do not assume that storing a video extracts every technical property.

Business metadata describes the work: project, campaign, client, product, market, intended channel, language, cut type and version meaning. It must come from the production team or another reliable business record.

A small useful record could identify the project, source reference, cut type, audio language, caption language and reuse status. Start with the questions people actually ask. Add fields when they support a decision, rather than designing an exhaustive taxonomy before the library can be used.

Make version meaning, language and captions explicit

final-v7.mp4 tells someone little about the change. It might be a client revision, a color-corrected export, a vertical cut or a captioned copy. Record what changed and which file the team currently considers suitable for the intended use.

For an illustrative social cut, a description might read: AW27 campaign; vertical social edit; French audio; French captions burned into the picture; based on the finished campaign master; revision adds the closing product card. Those details explain the variant without requiring the reader to interpret a numbered filename.

Distinguish audio language from caption or subtitle language when they differ. Also distinguish a clean video, text burned into the picture, a selectable text track and a separate caption file. Keep any required caption file identifiable alongside the corresponding cut.

A short asset description is not a timed caption track. W3C's caption guidance describes synchronized text for speech and relevant non-speech audio. A metadata field called caption does not establish that a video contains accessible captions.

Record relationships in the asset system if it supports them, or in the production record alongside the files. A collection or shared project tag can group cuts, but it does not automatically establish version lineage or an approval decision.

Make cuts searchable beyond their filenames

A filename such as aw27-social-fr-9x16-v03.mp4 can help when the file is sent to a collaborator or leaves the library. Use the parts needed for that exchange. A naming convention does not need to encode the entire asset record.

Put important campaign, product and cut information into searchable titles, descriptions or tags where the system supports them. Use collections for a project or campaign when they help people group the work. An elaborate folder tree should not be the only way to discover the correct version.

Test practical requests: find the French social cut, find the clean master, or find the version with the revised product card. If the search relies on metadata, those facts need to be recorded. A descriptive search result is not evidence of transcript indexing, scene analysis or recognition of people in the video.

Plan for large source files

Check per-file upload limits, total storage capacity and any transfer timeouts before importing a video archive. Confirm whether the chosen transfer method supports resuming an interrupted upload. Test it with a representative source file and connection.

Vyso's upload documentation describes a multipart upload endpoint and a deployment-configurable size limit. Check the current limit for the intended workspace before designing a workflow around large video masters. The documented upload method should not be treated as a promise of chunked or resumable transfer.

Track which files have already been ingested. If a transfer's outcome is unclear, reconcile the destination record before uploading the same file again. Do not assume that an image-specific duplicate check also detects duplicate videos.

If the authoritative master remains in production storage or an archive, record its location and responsible owner. Identify any smaller library copy as a review or reference copy. It should not silently replace the source in the team's records.

Connect the library to video infrastructure

The library identifies the cut that should be used. A processing service can generate the required encodes, and a delivery system can expose the playback reference to the consuming application.

Adaptive streaming adds responsibilities beyond file storage. HLS and MPEG-DASH use playlists or manifests and media representations for playback. A video stack may need to generate multiple bitrate options, package the media, distribute it through a CDN and support the chosen player. Playback monitoring belongs to that stack or its integration.

Keep a reference between the library asset and the external video record. When a cut changes, decide whether the integration creates a new playback version or replaces an existing one, then update the consuming application as required. Updating a library record does not necessarily replace a copy already uploaded to a social platform or another host.

The guide to automated media distribution explains the wider distinction between preparing an asset, delivering it and publishing into another system.

Where Vyso fits today

Vyso supports uploading video files and managing them as library assets. Its asset API includes video-type filtering and MP4/MOV format filters, along with collection filters and filename, title and description search. Collections can group project assets.

User-managed fields include userTitle, userDescription and userTags, documented through the metadata API. These can hold the business context that distinguishes a master from a language or channel-specific cut. They are descriptive fields; the team still needs to define and maintain the meaning of each version.

Vyso's current public delivery documentation covers image transformations and image delivery. Keep video encoding and adaptive playback in a verified video-processing or streaming system. Image enrichment and image-delivery operations should not be treated as video scene analysis or video transcoding.

Audit one project before reorganizing the whole library

Choose a completed project and work through its files. Record the answers beside the assets or in the project's production record:

• Which files are authoritative sources, and where are the materials needed for future editing?
• Can someone distinguish editorial cuts, language versions and caption arrangements from technical encodes?
• Can the team find the intended variant using its campaign, product and cut terms without guessing a filename?
• Which files must be preserved, and which can actually be regenerated from retained sources and settings?
• Are duplicate exports consuming storage without a clear reuse purpose?
• Are upload limits suitable for the largest required sources, and are encoding and playback assigned to systems that support them?

Fix missing context and confirm retention decisions for that project before applying the same approach elsewhere. A useful audit produces identifiable masters, reusable cuts and specific cleanup decisions.