mov vs mp4
The Container Is the Contract: How .mov and .mp4 Differ for Android Video, and Why Editors Care
Learn how the .mov and .mp4 containers actually differ on Android, which sample entries and colour tags editors depend on, and how to choose a recording format you will not have to transcode later.
The Short Answer: Same Codec, Different Contract
The primary debate surrounding the Android smartphone video file container .mov vs .mp4 comes down to metadata signalling rather than pixel data. Because both containers are direct derivatives of the ISO Base Media File Format (ISO/IEC 14496-12), the video and audio streams inside can be byte-identical High Efficiency Video Coding (HEVC/H.265) or Advanced Video Coding (AVC/H.264) streams. The critical difference lies in the metadata wrapper: which sample entry atoms are written, which colour and High Dynamic Range (HDR) tags are defined, and how strictly non-linear editing systems (NLEs) interpret the container brands.
For cinematographers and editors shooting mobile footage, the practical decision rule is simple: choose the container your post-production finishing environment ingests cleanly without a mandatory transcode or proxy step, rather than picking whichever format appears to produce a marginally smaller file. When setting up a multi-camera pipeline or integrating mobile captures into a desktop timeline, the container you configure on set establishes an implicit contract with your editing software. Understanding how that container is packaged prevents workflow bottlenecks before ingest begins.
What Actually Lives Inside a .mov or .mp4 File
At their core, both QuickTime Movie (.mov) and MPEG-4 Part 14 (.mp4) files arrange data into a hierarchical structure of binary building blocks called atoms or boxes. An application parsing the file does not begin by decoding image pixels; it parses these structured headers to interpret stream timing, codec initialization requirements, and colour properties.
The typical structural hierarchy of an ISO-derived media file includes:
ftyp(File Type Box): Declares the file's brand compatibility, specifying how strict parsers should handle the contents.moov(Movie Box): Contains all the top-level metadata describing the presentation layout.trak(Track Box): Defines an individual stream, such as video, audio, timecode, or data.mdia(Media Box): Holds detailed media information for that specific track.minf(Media Information Box): Groups the functional handlers and sample tables.stbl(Sample Table Box): The index of sample descriptions, chunk offsets, synchronization samples, and decoding times that editing engines evaluate before loading media.
Within the ftyp box, major and compatible brands signal intent. A standard Android capture often sets a brand like mp42 or isom. By contrast, a QuickTime container declares a major brand of qt (with two trailing spaces). Strict desktop editing software queries this brand to determine which media framework handles playback.
Deep within the stbl atom resides the sample entry, which names the codec variant. For HEVC streams, this entry is typically declared as either hvc1 or hev1. The choice governs where codec parameter sets are stored. The hvc1 sample entry places the Video Parameter Set (VPS), Sequence Parameter Set (SPS), and Picture Parameter Set (PPS) directly in the sample description box out-of-band. The hev1 entry allows parameter sets to be carried in-band within the elementary stream itself.
Alongside sample entries, colour metadata boxes define how raw code values translate into visible light. An ISO file should contain a colr box carrying an nclx colour profile with three discrete indices: colour primaries, transfer characteristics, and matrix coefficients. For HDR deliverables, supplemental boxes such as mdcv (Mastering Display Colour Volume) and clli (Content Light Level Information) specify luminance boundaries. If an Android camera app writes a 10-bit Hybrid Log-Gamma (HLG) stream without these colour atoms, desktop software has no standardized method to identify the transfer curve, resulting in flat, desaturated images on import.
Android Smartphone Video File Container .mov vs .mp4: Where the Two Diverge in Practice
In default mobile environments, the majority of standard Android camera tools wrap video into an .mp4 wrapper using in-band parameter signalling. While this design is standard across mobile players and social platforms, professional post-production software expects standard media descriptors. A QuickTime container Android capture provides a robust framework for desktop tools, provided the underlying atoms adhere strictly to the QuickTime specification.
File extensions can be misleading. A file named .mov can legally house standard MPEG-4 structures, while an .mp4 container can encapsulate QuickTime-style user-data atoms. Changing the file extension manually does not alter the underlying binary structures. When an editor renames an .mp4 file to .mov, the internal ftyp brand and sample entries remain unaltered, and desktop media engines continue reading the original declarations.
Audio formatting and track handling also diverge between the two specifications. Standard .mp4 recordings on Android usually pair video streams with lossy Advanced Audio Coding (AAC). The QuickTime specification natively accommodates multi-channel uncompressed Linear PCM audio tracks, dedicated timecode tracks (tmcd), and reel-name metadata embedded directly inside track references. When evaluating the Android smartphone video file container .mov vs .mp4 in practical production workflows, the divergence centers on these operational parameters:
| Parameter | Standard Android .mp4 | QuickTime .mov on Android |
|---|---|---|
Major Brand (ftyp) |
isom, mp41, or mp42 |
qt |
| Typical HEVC Sample Entry | hev1 (in-band parameter sets) |
hvc1 (out-of-band parameter sets) |
| Colour Signalling | Often omitted or unparsed vendor tags | Standardized colr atom with nclx descriptors |
| Audio Format Support | Compressed AAC audio streams | AAC or multi-channel Linear PCM |
| Timecode Handling | Stored as variable track samples or omitted | Native dedicated tmcd tracks |
| Interchange Profile | Web, mobile streaming, social sharing | Desktop NLE ingest and timeline grading |
Platform implementations can introduce additional variation. As detailed in the Android Developers supported media formats guide, codec and container capabilities depend on specific device architectures and Android platform versions, meaning features must be verified on the target device rather than assumed from generic specifications.
Why Final Cut Pro Opens One and Asks Questions About the Other
Final Cut Pro relies heavily on Apple's AVFoundation media architecture, which parses QuickTime structures to determine project color management. When an editor brings in an HEVC clip wrapped in a standard Android .mp4 file, AVFoundation frequently encounters an hev1 sample entry without complete colr metadata. Because the parameters are locked in-band and the container lacks definitive display-referred metadata, the software cannot confirm whether the source is standard dynamic range Rec. 709 or wide-gamut Rec. 2020 HLG. This triggers import warnings, forces manual color overrides, or defaults to an incorrect rec. 709 interpretation.
The operational cost of this metadata failure is significant. If an editor must transcode mobile clips into intermediate editing media simply to correct clip properties, ingest times increase dramatically. Processing high-bitrate 4K 10-bit camera media through an intermediate transcode can significantly delay post-production depending on workstation hardware.
PrimeCam writes HEVC Main 10 in a .mov file with the hvc1 sample entry and a full Rec. 2020 HLG colour tag, which Final Cut Pro reads natively. This eliminates the need to conform container properties on desktop workstations. PrimeCam does not record ProRes. It writes HEVC Main 10, which Final Cut Pro opens natively without transcoding. To review file packaging behavior, examine the Android smartphone video file structure for editors.
To verify how your post-production software processes camera assets before committing to a production run, perform this basic three-step ingest test:
- Capture a calibration clip: Record a five-second scene containing bright highlights and deep shadows using your camera setup.
- Inspect sample entries and colour tags: Run an inspection utility on the file to ensure the video sample entry reads
hvc1and the color profile explicitly lists Rec. 2020 primaries with an HLG transfer curve. - Drop directly into a wide-gamut timeline: Import the unprocessed clip into a project set to Wide Gamut HDR (Rec. 2020 HLG). If the software identifies the clip correctly, highlights roll off naturally without requiring a manual color override or transcoding pass.
The hvc1 Sample Entry, Explained Without the Spec Language
The distinction between the hvc1 sample entry and hev1 is a frequent source of import errors in professional video workflows. In video compression, parameter sets act as a structural map. The Video Parameter Set (VPS), Sequence Parameter Set (SPS), and Picture Parameter Set (PPS) describe the frame dimensions, bit depth, chroma subsampling format, and profile level required by the hardware decoder.
Under an hev1 configuration, the container does not hold this map in its headers. Instead, these parameter sets are injected periodically into the elementary video stream alongside the slice data. While consumer playback software decodes this layout without issue, strict desktop video engines and system decoders expect the parameter sets to be available immediately within the sample entry wrapper before initializing decoding pipelines. When presented with hev1, desktop engines may drop decoding duties back to software or fail to load video frames entirely, producing black frames or audio-only playback.
Using the hvc1 sample entry stores these parameter sets directly inside the stsd (Sample Description) atom. The decoder reads all configuration parameters immediately during track evaluation. This makes hvc1 a more reliable structure for interchange when handling 10-bit HEVC Main 10 footage.
You can verify which sample entry your files use by running ffprobe in the macOS or Linux terminal:
ffprobe -v error -select_streams v:0 -show_entries stream=codec_tag_string -of default=noprint_wrappers=1 input_clip.mov
If the terminal returns codec_tag_string=hvc1, the stream carries its configuration in the sample entry. If it outputs hev1, parameter sets are stored in-band, which may account for unexpected decode failures in sensitive editors.
Colour Tags, HLG and the Cost of a Missing Box
High Dynamic Range video requires precise signaling. Hybrid Log-Gamma operates using a display-referred transfer characteristic standardized in the ITU-R BT.2100 recommendation to bridge SDR and HDR environments. For an editing workspace to assign correct scene luminance to timeline pixels, the container must register Rec. 2020 primaries alongside the HLG transfer function.
When this metadata is omitted, video software typically defaults to standard dynamic range (Rec. 709). Displaying HLG data within an unmanaged Rec. 709 space compresses the midtones and clips highlight rolloff, making footage appear flat and washed out. Editors unfamiliar with the underlying issue often attempt to fix the problem by applying corrective Look-Up Tables (LUTs). This stretches quantized values incorrectly, introducing banding and noise across smooth gradients.
PrimeCam records HLG, not LOG. HLG is a display-referred curve that carries its own grade; there is no LOG profile. The embedded colour tag performs the transform work that a technical conversion LUT would handle in a LOG workflow. Maintaining container-level colour tags avoids downstream grade adjustments and preserves dynamic range.
To confirm color attributes before a shoot, inspect the media track for the following nclx properties:
- Colour Primaries:
9(ITU-R BT.2020) - Transfer Characteristics:
18(HLG / ITU-R BT.2100-2) - Matrix Coefficients:
9(ITU-R BT.2020 non-constant luminance)
Choosing a Container for Your Own Pipeline
Selecting the appropriate container requires evaluating every link in your post-production workflow. Where your footage goes after recording dictates the parameters you should configure on capture devices:
- Final Cut Pro Finishing: Select
.movwrappers that writehvc1sample entries andnclxcolour profiles to enable immediate timeline playback without transcoding. - DaVinci Resolve / Premiere Pro Delivery: Both editors ingest standard
.movand.mp4containers cleanly, though.movfiles carrying structured colour tags minimize timeline color space override steps. - Direct Web / Client Distribution: When files bypass an editing environment and go straight to web platforms, standard
.mp4with AAC audio offers broad playback compatibility across consumer browsers and mobile systems. - Archive Strategy: Maintain camera-original captures untouched. Modern systems should generate optimized proxy files during post-production rather than destructively re-encoding source files during ingest.
Container selection does not meaningfully affect storage footprint. The wrapper structure accounts for a negligible fraction of the total byte count. Decisions regarding file size should focus on codec bit rates rather than the container format.
Pitfalls, Edge Cases and What the Container Cannot Fix
While wrapping video within an appropriate container avoids ingest issues, it cannot resolve underlying encoding errors. A common workaround involves remuxing footage via FFmpeg using the stream copy flag (-c copy):
ffmpeg -i source_clip.mp4 -c copy -tag:v hvc1 remuxed_clip.mov
This command rewrites container atoms without modifying compressed streams, updating the tag to hvc1. However, this process cannot restore missing colorimetry metadata if the original colr box was omitted during initial encoding. Remuxing can correct sample descriptions, but it will not correct sensor-level exposure errors or reconstruct clipped highlight detail.
Another challenge with mobile video is frame rate consistency. Consumer screen-recording tools and basic camera apps often output variable frame rates (VFR) to balance processor loads, leading to audio sync drift in editing timelines. PrimeCam targets 24 fps, and says so rather than assuming it. A take can come in marginally under nominal — auto exposure opening the shutter to the whole frame period leaves the sensor no time to read one out — so the app reports the rate it actually achieved in three places: the strip switches to the measured rate in warning colour while the take is rolling, the take card reads "23.92 fps measured, not 24.000", and the JSON sidecar carries measuredFps beside the requested fps. measuredFps is null when the take held its rate close to nominal and a number when it did not, so an editor conforming a timeline can tell the two cases apart.
Data durability also depends on how containers are closed on storage media. If an operating system terminates a recording session before the moov atom is written, standard containers become unreadable because the sample index is missing. A take is written as a spanned clip: numbered parts of a few seconds each, each one finished as it is written. If the app stops unexpectedly the last few seconds are lost rather than the whole take, and the parts carry the take's name and import as one clip. That is a floor on what a crash costs, not a promise that nothing is lost: PrimeCam 0.1.0 is an early build and nothing irreplaceable should be shot on it yet.
Hardware capabilities also vary significantly across phone models. As outlined in the Android Developers multimedia guide, individual device implementations govern lower-level media encoding pipelines. The developer reports testing on Pixel 11, Pixel 10 Pro and Pixel 10, plus a Samsung phone on 15 September 2026 whose model has not been recorded. Earlier documented field testing also covers Pixel 10 Pro XL and Pixel 6a. These reports do not establish support for all Samsung phones or every recording mode; capabilities vary by device. Developer testing on 15 September 2026 found that Pixel 9a does not support 10-bit recording in PrimeCam; it is not a supported device for the current 10-bit HLG recording mode. It requires Android 13 or later and a camera that can record 4K in 10-bit HLG. Camera features must be validated on your specific device hardware before filming.
For automated workflows, refer to the walkthrough on using JSON metadata sidecars with mobile footage. Subject tracking pipelines also benefit from local processing architectures. Subject detection runs on models bundled inside the app, not on a server, and names the rung it is holding — EYE, FACE, BODY, or NO SUBJECT. Data management is equally contained: PrimeCam does not request Android INTERNET permission. Recording and subject detection run locally, with no PrimeCam account, analytics SDK or cloud sync. Billing-enabled test builds communicate with Google Play for product details, purchases and restoration; Google Play uses its own network connection. No footage is sent through billing.
Conclusion: Pick the Container Your Editor Already Trusts
The container file serves as the technical contract between your camera and your editing suite. When working with an Android smartphone video file container .mov vs .mp4, selecting the appropriate format ensures that critical metadata reaches your post-production software intact.
Before your next shoot, record one short clip and run the three-check import test — ftyp brand, hvc1 sample entry, colour tags — in your editor.
Frequently Asked Questions
Is .mov better quality than .mp4 for Android video?
No. Neither container dictates visual compression quality on its own. Because both .mov and .mp4 use the ISO Base Media File Format, image fidelity is determined entirely by the underlying codec, encoding bit rate, quantization profiles, and sensor capture settings. The choice of container simply affects metadata signaling, track support, and editing software compatibility.
Can I just rename an .mp4 to .mov so Final Cut Pro will open it?
Changing the file extension does not modify the internal structure of the file. The binary header remains an .mp4 container with its original ftyp brand declarations and hev1 sample entries intact. If an editing application rejects the file due to missing metadata boxes or unsupported sample entries, changing the file extension will not resolve the issue; the file must be remuxed or transcoded.
What is the difference between hvc1 and hev1 in an HEVC file?
The difference lies in where the codec parameter sets (VPS, SPS, and PPS) are stored. The hvc1 sample entry places these parameter sets directly within the container's sample description box, making them accessible before decoding begins. The hev1 entry stores parameter sets in-band inside the video stream itself. Desktop video editing applications generally require hvc1 for reliable hardware-accelerated decoding.
Why does my Android HLG footage look washed out after import?
This typically occurs when the container lacks an explicit colr box carrying nclx parameters for Rec. 2020 primaries and the HLG transfer characteristic. Without these identifiers, editing software often defaults to interpreting the media as Rec. 709 Standard Dynamic Range, displaying compressed midtones and clipped highlights across your timeline.
Does PrimeCam record ProRes or LOG?
PrimeCam does not record ProRes. It writes HEVC Main 10, which Final Cut Pro opens natively without transcoding. PrimeCam records HLG, not LOG. HLG is a display-referred curve that carries its own grade; there is no LOG profile.