FFmpeg Outputted Videos Not Seekable in Chrome & Edge: A Solution

FFmpeg outputted videos often fail to seek in Chrome and Edge because the default muxer writes metadata at the end of the file. Browsers require this index, known as the "moov atom," to be at the beginning for instant playback and seeking. You can fix this by using the -movflags +faststart flag during encoding or conversion. This command reorganizes the file structure so the browser can parse it immediately without downloading the entire video first.

Understanding the Seekability Issue

When you encode a video with FFmpeg, the resulting file is typically an MP4 container. Inside this container, there are two main components: the media data (the actual video and audio frames) and the metadata (index information that tells the player where each frame is located). By default, FFmpeg places the metadata at the very end of the file. This is efficient for servers writing large files sequentially, but it creates a problem for web browsers. Chrome and Edge use HTML5 video players that attempt to seek to specific timestamps before the entire file has downloaded. If the index is at the end, the browser cannot find the requested frame until it downloads everything. Consequently, the seek bar may appear broken, or clicking on it will cause the video to buffer extensively or not jump at all. This behavior is particularly noticeable on slower connections or when dealing with large video files. The issue is not with your codec or resolution settings, but strictly with the container's internal structure.

The Solution: Faststart Flag

The standard solution provided by FFmpeg is the -movflags +faststart option. This flag instructs the muxer to move the moov atom to the beginning of the file. While this might slightly increase the initial processing time because the muxer needs to scan the file twice, it ensures that the metadata is available immediately upon download start. This makes the video fully seekable from byte zero, which is exactly what modern web standards expect. To apply this, you simply add the flag to your existing FFmpeg command line. For example, if you are converting a file, your command should look like this:

ffmpeg -i input.mp4 -c:v libx264 -c:a aac -movflags +faststart output.mp4

This command encodes the video using H.264 and audio using AAC, while simultaneously optimizing the container for web playback. If you are remuxing (copying streams without re-encoding), you can use the same flag with -c copy. This is much faster than re-encoding and still solves the seekability issue.

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

It is important to note that this flag only works with MP4 containers. If you are outputting to MKV or other formats, different tools or flags are required. However, for web distribution via Chrome and Edge, MP4 is the most compatible format anyway.

Verifying the Fix

After running your command with the +faststart flag, you should verify that the file is correctly structured. You can use the ffprobe tool, which comes bundled with FFmpeg, to inspect the file. Run the following command:

ffprobe -v error -show_entries stream=index -of default=noprint_wrappers=1:nokey=1 output.mp4

If the output shows a list of indices starting from 0, the file is likely properly structured. A more direct check is to upload the file to a web server and test it in Chrome. Try seeking to the middle of the video while it is still buffering. If it jumps instantly, the fix was successful. You can also use online tools or browser developer tools to inspect the network requests and see if the browser is requesting the moov atom early. For users who process many videos, consider creating a wrapper script or alias that automatically includes this flag. This prevents accidental creation of non-seekable files. If you encounter issues where FFmpeg does not quit when it returns an error, ensure your command syntax is correct, as seen in our guide on FFMPEG: Program does not quit when it returns an error. Incorrect flags can sometimes cause silent failures or unexpected behavior.

Common Pitfalls

One common mistake is applying -movflags +faststart to a file that is already encoded but not optimized. While it works for remuxing, it requires a full pass over the file. Another pitfall is forgetting that this flag only affects MP4. If you are streaming via UDP, as discussed in How to Send Multi Video in UDP Protocol with Single IP/Port?, the concept of faststart does not apply because UDP is a streaming protocol, not a file-based one. Additionally, some older versions of FFmpeg might have bugs related to this flag. Always ensure you are using a recent version of FFmpeg to avoid compatibility issues. If you are working with specific camera formats like MTS, remember that transcoding might be necessary before applying these optimizations, as detailed in Using ffmpeg with MTS files created from Canon video camera. Finally, do not confuse -movflags +faststart with compression settings. It does not reduce file size; it only rearranges bytes. Your file size will remain roughly the same, but usability improves significantly. This small change can drastically improve user experience on your website or application.

Frequently Asked Questions

Why does my video seek fine in VLC but not in Chrome?

VLC is a desktop player that can handle out-of-order metadata and seeks by downloading the entire file first if necessary. Chrome relies on the HTML5 video element, which expects the moov atom at the start for efficient progressive loading. This difference in player architecture causes the discrepancy.

Can I use faststart with WebM files?

No, the -movflags +faststart option is specific to the MP4/MOV container format. For WebM files, you generally do not need this flag as the WebM specification handles metadata differently, though ensuring proper chunking can help with seekability.

Does faststart increase file size?

No, faststart does not change the content of the video or audio streams. It only moves existing metadata blocks around within the container. The file size will remain identical to the original unoptimized file.

What if I am using an older version of FFmpeg?

If your FFmpeg version is too old, the -movflags option might not be supported or could behave unexpectedly. Upgrade to the latest static build from the official FFmpeg website to ensure full compatibility with modern web standards.

Is faststart necessary for local video playback?

For purely local playback where the entire file loads instantly, faststart is not strictly necessary. However, it is good practice to always use it if the file might ever be transferred over a network or embedded in a webpage.