Why an uploaded video loses its last few seconds
Quick answer
A video that loses its final seconds after upload usually has a container duration mismatch. The file's own metadata declares a shorter video track than the audio it carries, often from an upstream trim that updated part of the header. Players that honour the declared duration truncate it. Players that ignore it keep going.
What causes a video upload to be cut short?
A customer sent us files that kept losing their last several seconds after upload. In their file browser the videos looked full length. In QuickTime they played full length. Uploaded, they came back short. Every instinct says corruption, and corruption is the one thing it was not.
The container was declaring a seven second video track against a twenty seven second audio track. An upstream trim had written the new duration into one part of the header and left the rest alone. The file was internally inconsistent and perfectly readable, which is the combination that makes this so confusing to diagnose.
From there the behaviour depends entirely on which player you open it in, and players disagree.
Why do different players show different lengths for the same file?
Because honouring the declared duration is a judgement call, and each player made it separately.
| Behaviour | What the player does | What you see |
|---|---|---|
| Strict | Trusts the declared duration | Video stops at the declared length |
| Lenient | Plays until the media runs out | Video appears full length |
| Mixed | Strict on ingest, lenient on preview | Preview looks fine, the export does not |
Neither of the first two is a bug. A strict player is doing what the file asked. A lenient player is being generous about a file it suspects is wrong. The third row is where teams lose an afternoon, because the tool that showed them the video and the tool that processed it disagreed, and both were internally consistent.
What does this mean for a creative team shipping finished work?
It means an eyeball check in one application is not evidence that a file is correct. The person who trimmed the clip watched it in the app that made it, where it was fine. The person who received it watched it in a different app, where it was also fine. The truncation only appeared at the end of the chain, in the system that took the header at its word.
Two habits fix most of this.
- Check duration where the file will be used, not where it was made. The destination runtime decides what the file is.
- Treat a mismatch between audio and video length as a red flag on export, not on import. It is far cheaper to catch at the trim than three handoffs later.
This belongs in the same family as the rest of the pre publish checks we run through ina practical video QC checklist. When it is caught late, the cost is not the seconds, it is the rework, which we sized up inwhat it really costs to edit a finished video.
Should a platform be strict or lenient about this?
We are sitting with this question live, and there is no clean answer.
Being strict is defensible. The container carries those values deliberately, and a platform that ignores them will happily play past the end of legitimate files too. The cost of leniency is a steady trickle of exports carrying a trailing second of black, shipped by default, on any file with a mismatch.
Being lenient is also defensible, because in this specific case nobody wanted the truncation. The customer was not asking for a seven second video and the extra twenty seconds were real content she had shot.
What we are fairly sure of is that the answer should not be silent in either direction. A file that is about to lose twenty seconds should say so before it does, and a file about to gain a second of black should say that too. The decision to be strict or generous matters less than making it visible at the moment it gets made.
FAQ
Why does my video get cut short after uploading?Most often the file's container declares a shorter video duration than the media it holds, usually after an upstream trim. Players that honour the declared duration truncate playback.
Is a truncated upload a sign of a corrupt file?No. The file is readable and internally consistent enough to play. Its header is simply inconsistent with its media length.
Why does the same file look full length in one app and short in another?Applications differ on whether to trust the declared duration. Strict players stop at it, lenient players play until the media ends.
How do you catch this before publishing?Verify duration in the system that will actually process or host the file, and flag any mismatch between audio and video length at export rather than at import.