Most editors think of video work as a timeline problem: cuts, transitions, color, and sound. But once you produce more than a handful of clips a week, the real bottleneck shifts somewhere else. It becomes naming, tagging, versioning, and the tedious job of remembering which clip came from which generation pass, which prompt, and which settings.
This tutorial is about the unglamorous layer underneath all of that: editing video file properties and container metadata from the command line. Windows Command Prompt and PowerShell, plus their bash and zsh equivalents on macOS and Linux, give you a level of control that no editing panel exposes. Learn them and your AI-generated footage stops being an unruly pile of files and starts behaving like a managed library.
Why file properties matter more than they used to
When video production meant shooting on set, metadata arrived mostly by accident — camera timestamps, reel names, maybe a slate photo. Today, a single project might involve a dozen generation passes, three upscaling tools, two voice models, and a music bed pulled from a stock library. Every one of those steps produces files that look identical in a folder listing and completely different in provenance.
That gap creates three predictable problems.
Version confusion. clip_final.mp4, clip_final_v2.mp4, and clip_final_v2_real.mp4 are a symptom. Without embedded or filesystem-level descriptors, sorting by eye is the only tool you have.
Delivery friction. Clients and platforms increasingly ask for descriptive context: creation date, source, aspect ratio notes, rights information. If you cannot export that from the files themselves, you are rebuilding it manually every time.
Search failure. The moment a library crosses a few thousand clips, you need to find things programmatically — by date, by duration, by tag, by codec. Filesystem search alone will not do it.
Command-line tools solve all three because they operate on files in bulk, deterministically, and reproducibly. A script that took twenty minutes to write can retag an entire archive in seconds, and you can run it again next month on the next batch.
Choosing your command-line environment
The tool you pick depends on what you need to change. There are three distinct layers of "file properties," and they are not interchangeable.
Windows: Command Prompt versus PowerShell
Command Prompt (cmd.exe) is the older shell. It handles directory navigation, file copying, renaming, and basic attributes competently. Its classic attribute tool is attrib, which toggles read-only, hidden, system, and archive flags. ren and move handle names.
PowerShell is the modern shell and the better default for anything scripted. It exposes filesystem objects as rich .NET objects, which means you can read and write creation times, modification times, and access times directly, and pipe results into structured output. If you are doing anything beyond a one-off rename, PowerShell will save you time.
A quick comparison: attrib +r clip.mp4 in CMD marks a file read-only. In PowerShell, (Get-Item clip.mp4).IsReadOnly = $true does the same thing, but you can wrap it in a loop over Get-ChildItem -Recurse and apply it to ten thousand files in one line.
macOS and Linux: same idea, different plumbing
On Unix-like systems, extension is a convention, not a property. There is no hidden/archive bit. Instead you have permissions (chmod), ownership (chown), extended attributes (xattr), and timestamps (touch, stat). If you are working cross-platform, expect to maintain two thin scripts rather than one universal one.
The practical approach most studios settle on: write your logic once in a language-agnostic way, then call the platform-specific command. Or simply standardize on a cross-platform binary like FFmpeg or ExifTool, which papers over most differences.
Layer one: names, timestamps, and attributes
Start with the layer that requires no special tools. It is also the layer that prevents the most chaos.
Bulk renaming that survives a thousand clips
A naming convention should encode, at minimum: project code, sequence or shot, generation pass, and a sequential index. Something like PRJ01_sc04_pass03_0007.mp4. That string alone tells you where a clip belongs without opening it.
In PowerShell, a bulk rename looks like this:
$i = 1
Get-ChildItem -Filter *.mp4 | Sort-Object LastWriteTime | ForEach-Object {
$new = 'PRJ01_sc04_pass03_{0:D4}.mp4' -f $i
Rename-Item $_.FullName -NewName $new
$i++
}
On macOS or Linux, the equivalent uses a shell loop with printf and mv. The important detail in both cases is sorting before renaming. If you rename in filesystem order, the numbering will be arbitrary and you will lose the chronological relationship between clips.
Timestamps as a versioning tool
Creation and modification times are editable, and that makes them useful. If you export a batch from a generation tool that stamps everything with the export time, you can rewrite the timestamps to reflect the actual generation order instead.
On Windows: (Get-Item file.mp4).CreationTime = '2025-01-15 09:00:00'. On Unix: touch -t 202501150900 file.mp4.
This matters more than it sounds. Many media asset managers sort by creation time, and many backup tools use modification time to decide what to sync. Getting timestamps right at ingest is far cheaper than fixing them later.
Attributes and read-only flags
Use attributes as a lightweight lock. Once a clip has been approved and delivered, mark it read-only. It will not stop a determined person, but it stops the far more common failure: you, six weeks later, accidentally overwriting a master with a test render.
Layer two: container metadata with FFmpeg
FFmpeg is usually thought of as an encoder. Treat it instead as a metadata editor that happens to also transcode, and a lot of workflow problems become trivial.
Reading what is in a file
The inspection command is ffprobe. ffprobe -v quiet -print_format json -show_format -show_streams clip.mp4 dumps everything the container knows: duration, bitrate, codec, frame rate, plus any global or per-stream tags.
Run this once on files from each of your generation tools. You will quickly learn which ones write useful metadata and which write nothing at all.
Rewriting tags without re-encoding
The critical flag is -c copy. It tells FFmpeg to copy the streams bit-for-bit and change only the container. That means a retag takes a fraction of a second rather than re-rendering a four-minute clip.
ffmpeg -i clip.mp4 -c copy \
-metadata title="Shot 04 pass 03" \
-metadata comment="generated with seed 88123" \
-metadata artist="Studio Name" \
out.mp4
A few practical notes:
- MP4 and MOV support a reasonable set of standard tags plus arbitrary key-value pairs, though not every player will surface custom keys.
- MKV is the most permissive container and will hold nearly anything you throw at it.
- WebM is stricter and may silently drop fields it does not recognize.
- Always write to a new file the first time you test a metadata command. Container rewrites can fail partway, and a failed rewrite can leave a file with a valid header and broken moov atom.
Stripping unwanted fields
Generation tools sometimes embed API keys, session identifiers, or internal prompts into output files. Before anything leaves your machine, strip the container:
ffmpeg -i in.mp4 -c copy -map_metadata -1 -metadata title="Deliverable" out.mp4
-map_metadata -1 drops existing global metadata so you start from a clean slate. This is the single most useful command in a delivery pipeline, and it is worth making part of your export preset.
Layer three: deep metadata with ExifTool
FFmpeg handles containers. ExifTool handles everything: QuickTime atoms, ID3 in audio, sidecar files, and formats FFmpeg will not touch. If you only learn one external tool, learn this one.
Inspection first
exiftool clip.mp4 prints every tag it can find, grouped by location. exiftool -s -G clip.mp4 shows short names with group prefixes, which is what you want when scripting, because group prefixes tell you exactly which tag namespace a value lives in.
Writing tags
A basic write is exiftool -Title="Shot 04" -Comment="pass 03" clip.mp4. For bulk work, the important flags are:
-overwrite_originalwrites in place without creating backup copies. Fast, and slightly dangerous.-rrecurses into subdirectories.-ext mp4 -ext movlimits the operation to specific extensions.-csv=out.csvon read, and-csv=in.csvon write, let you drive an entire metadata pass from a spreadsheet.
The CSV round-trip
This is the workflow worth internalizing. First, export the current state:
exiftool -csv -r -ext mp4 -ext mov ./footage > current.csv
Now you have a spreadsheet with one row per file. Fill in the descriptive columns — project, shot, pass, rights, notes — and write it back:
exiftool -csv=current.csv -r ./footage
Anyone on the team can contribute to a CSV. Almost nobody can safely write a shell loop on a deadline. The round-trip turns metadata work into a task you can delegate without risking the media itself.
Building a batch pipeline that scales
Individual commands are useful. A pipeline is what keeps a library clean. A workable structure has four stages.
Stage one: ingest and normalize
Copy new files into a dated inbox directory, rename them to convention, and rewrite timestamps to reflect generation order. Do not edit content yet.
Stage two: probe and log
Run a probe pass that writes duration, resolution, codec, and frame rate into a CSV. This becomes your catalogue. From here you can answer questions like "how many clips are under five seconds" without opening a single file.
Stage three: tag and classify
Apply descriptive metadata, either from the CSV or from filename parsing. Include technical facts you will want later: the tool that generated the clip, the seed if available, and the target aspect ratio.
Stage four: deliver and lock
Strip internal metadata, add delivery-facing tags, move to the final directory, and set read-only. Anything that fails a validation check goes to a quarantine folder for review.
Each stage is a script. Each script is idempotent — running it twice produces the same result as running it once. That property is what makes the pipeline trustworthy.
A worked example: an AI batch from generation to archive
Imagine you generated 240 clips overnight for a product spot. They arrive as output_001.mp4 through output_240.mp4 with no metadata and identical timestamps.
- Triage. Run a probe pass to a CSV and confirm all 240 files are readable and the expected length.
- Rename. Apply the convention
SPOT02_sh{nn}_pass01_{0000}.mp4, sorted by original filename so the sequence maps to the generation order. - Timestamp. Rewrite creation times to spread across the generation window, one minute apart, so asset managers sort them correctly.
- Tag. Use ExifTool with a CSV to attach shot numbers, target duration, and a note about which prompts produced each clip.
- Strip and deliver. Transcode any clip that needs a different container, run
-map_metadata -1, add the delivery title, then set read-only.
The whole sequence is maybe forty lines of scripting. Doing it by hand in a file browser would take hours and produce inconsistent results within the first twenty files.
Safety rails: dry runs, backups, and reversibility
Command-line metadata work is fast, which means mistakes are also fast. Four habits keep you out of trouble.
Always dry-run first. ExifTool supports -if conditions and a test mode that reports what would change without touching files. Use it. Renaming scripts should print the planned mapping before executing.
Work on a copy for new operations. Write to a new filename rather than in place until the command has proven itself across a sample of at least a dozen files.
Never combine metadata writes with destructive renames in one step. If something goes wrong, you want to know which operation caused it.
Keep a manifest. A text file listing original names alongside new names, written before any operation runs. If a batch goes sideways, the manifest is your restore path.
Troubleshooting the failures you will actually hit
A player shows no metadata after a successful write. Some players read only specific tag groups. Check with ffprobe or exiftool rather than trusting the player. If the data is in the file, the player is the problem, not your command.
FFmpeg refuses to copy the stream. This usually means the output container cannot hold the input codec. Either change the container or re-encode that stream. -c copy is a container operation, not a magic wand.
ExifTool reports permission denied on Windows. Files marked read-only or held open by another application will fail. Clear the read-only attribute first with attrib -r or PowerShell, and close any editor that has the file loaded.
Timestamps revert after copying to another drive. This is normal on filesystems that do not preserve creation time. Bake the date into the filename if the timestamp is important, and treat the two as complementary rather than redundant.
Bulk operations slow to a crawl over a network share. Run metadata passes against a local copy, then sync. Every tag write on a network share is a round trip, and thousands of them add up.
Font-intensive metadata in filenames causes problems. Accented characters and non-Latin scripts are fine inside metadata but can break in filenames across platforms. Keep filenames ASCII, keep descriptions rich.
FAQ
Do I need to re-encode to change video metadata?
No. With FFmpeg's -c copy flag or ExifTool, metadata changes are container-level operations that take milliseconds regardless of clip length. Re-encoding is only necessary when you need a different codec or container than the source allows.
What is the difference between file attributes and video metadata?
Attributes belong to the filesystem: read-only, hidden, timestamps, permissions. Metadata lives inside the file: title, duration, codec, custom tags. Attributes travel with the file only as long as it stays on the same filesystem. Metadata travels with the file everywhere.
Can I automate this for a team?
Yes, and that is the strongest argument for the command-line approach. Scripts are reviewable, versionable, and shareable. A metadata script checked into your project repository becomes institutional knowledge, whereas an editor's personal workflow habits leave when they do.
How do I handle thousands of files at once?
The CSV round-trip is the answer. Export current state, edit in a spreadsheet, write back. It scales to tens of thousands of rows and keeps humans out of the loop for anything mechanical.
Is it safe to strip all metadata?
For delivery copies, usually yes — it removes internal identifiers and keeps files small. For master archives, no. Keep one tagged master with full provenance and strip only the copies that leave your control.
Where to take this next
Start small. Pick your current project's folder, run a probe pass, and write the results to a CSV. You will immediately see which files are missing information and which conventions are being violated. Then fix naming, then timestamps, then tags.
The tools do not change: a shell, FFmpeg, and ExifTool cover the overwhelming majority of real-world video file management. What changes is your workflow. Once metadata handling becomes a scripted, repeatable stage rather than an afterthought, the creative part of editing gets more room — and the library you build stops being a liability the next time someone asks for a specific clip.
