Identify the resource's job
A fragmented MP4 presentation can separate initialisation information from media fragments. Opening one resource as if it were a complete standalone movie may therefore ask the wrong question. Start by identifying the resource's role in the packaging workflow.
The W3C ISO BMFF byte-stream Group Note describes this separation for Media Source Extensions. It is a work-in-progress note with a defined MSE scope, not a universal assertion about every MP4 consumer. Use it to understand the roles while checking the actual destination contract.
Keep configuration and fragments together
An initialisation resource describes information needed to interpret the corresponding tracks. The media fragments must agree with it. Treat them as a versioned package: a new encode or changed track arrangement may require a new matching initialisation resource.
In a hypothetical upload, an old initialisation file remains cached while new fragments are published under familiar names. A decoding failure at that point deserves a package-revision investigation. It does not automatically prove that the underlying video codec is unsupported on every viewer's device.
Review the publication boundary
Build the new package completely before making its entry point available. Check that all referenced resources belong to the intended revision and remain accessible for the relevant viewers. Do not replace one file mid-publication while assuming the others will arrive before any client asks for them.
Use distinct resource identifiers where the publishing design requires them, and align cache policy with whether bytes can change. A manifest, initialisation resource and media fragment need not have identical lifetimes. The essential condition is that a client receives a coherent set.
Accept the real playback path
Review a clean start, a later entry point and any intended rendition transition in the target workflow. Record the package identifier and exact resource role if an error appears. Testing a fragment in isolation is not equivalent to testing the assembled presentation.
Retain the source and packaging record so a mismatched package can be regenerated. A successful HTTP response establishes delivery of bytes; it does not prove those bytes match the initialisation data or satisfy the decoder. Keep those outcomes separate in the acceptance report.
Questions answered
Is an initialisation file an empty or broken movie?
Its role may be configuration for later fragments. Judge it within the intended package.
Can I replace fragments while retaining any old initialisation file?
Only if the configuration remains deliberately compatible. Verify the complete revision relationship.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.