Cockpit Standalone MP4 plays, but cannot fast-forward on Windows

Blue Robotics Software Cockpit
1

Hi Blue Robotics team,

We are using BlueRobotics Cockpit V1.17 to record our video stream during a dive. After the dive, Cockpit processes the raw chunks into a single MP4 file, which we can download successfully.

The issue is that on Windows, the resulting MP4 will play, but we cannot fast-forward or seek properly through the video. This happens in all stock windows media players.

From what I’ve read, this can sometimes happen if the MP4 container metadata/index is not written correctly, for example if the file is missing or has an issue with the seek/index information rather than the video stream itself.

A few questions:

  1. Is this a known issue with Cockpit-generated recordings?

  2. Does Cockpit create a standard MP4, or could it be writing a fragmented MP4 / unusual container structure that Windows players do not handle well?

  3. Is there a recommended post-processing step to make the exported MP4 fully seekable on Windows?

  4. Would it help to re-mux the file with FFmpeg, for example using -c copy -movflags +faststart?

  5. If needed, is it better to re-process the raw chunk files instead of using the already exported MP4?

Has anyone else run into this, and is there a recommended fix or workflow?

Thanks!

2

Yes, Cockpit Standalone intentionally generates fragmented MP4 files (fMP4), not standard (flat) MP4 files. This is a deliberate design choice for crash-safety during recording, as if the computer goes out of battery, the camera disconnects, the app crashes, or anything like that happens unexpectedly, everything written up to that point is still playable.

The trade-off is that indeed some less capable media players cannot properly build a seek index from fragmented MP4 structure, so seeking/fast-forwarding doesn’t work. More capable players like VLC handle fragmented MP4 seeking fine.

Answering the specific questions:

  1. Is this a known issue? — Yes, it’s a known trade-off. The fragmented format is intentional for crash-safety.

  2. Does Cockpit create a standard MP4? — No, it creates a fragmented MP4 (frag_keyframe+empty_moov+default_base_moof).

  3. Recommended post-processing step? — I would say no, and that we recommend using a more modern media player, like VLC or MPV, as those not only work with a lot more formats, but they are also capable of playing our video telemetry overlays (.ass files).

  4. Would FFmpeg -c copy -movflags +faststart help? — Yes, this will turn the fMP4 into a regular MP4. More specifically you can use:

    ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4

    This will:

    • Demux the fragmented MP4
    • Remux it into a flat/standard MP4 with a centralized moov atom (complete seek index)
    • Place the moov atom at the beginning of the file (faststart) for optimal seeking
    • This is a lossless operation — no re-encoding, so it’s very fast and there’s zero quality loss.

  5. Re-process raw chunks vs. re-mux the MP4? — Re-muxing the already-exported MP4 with the command above is sufficient and much simpler. The video/audio streams inside the fragmented MP4 are perfectly fine — only the container structure needs to change. No need to go back to raw chunks.

2 Likes