FFmpeg编码报错EOF timestamp not reliable及DASH适配问题咨询

I’ve run into that exact [Parsed_movie_0 @ 0x...] EOF timestamp not reliable warning when processing long-form video for DASH, so let’s break down what’s happening and how to fix it, plus validate your command for DASH compliance.

Why the Warning Happens #

This is technically a non-fatal warning (not a hard error) that pops up when FFmpeg can’t reliably determine the end-of-file timestamp early in processing. It’s common with long, downloaded movie files that might have incomplete metadata or a corrupted index—short videos don’t trigger it because their entire timeline is parsed quickly, but long files take longer to scan, exposing gaps in the input’s metadata.

Issues in Your Current Command #

First, let’s spot a critical oversight that’s likely compounding the problem:

• You’re using two separate -vf flags: The first scale filter gets completely overwritten by the second watermark filter. FFmpeg only applies the last -vf you specify, so your scaling isn’t actually happening at all.
• Your output MP4 isn’t optimized for DASH: Standard MP4 files have a central metadata header (moov atom) at the end of the file, which makes it hard for DASH packagers like MP4Box to process long files efficiently.

Step-by-Step Fixes #

1. Repair the Input File’s Metadata #

First, fix the source video’s index/metadata to eliminate the EOF warning entirely. Run this to re-wrap the input with proper timestamps:

ffmpeg -y -i inputfile.mp4 -c copy -fflags +genpts fixed_input.mp4

Use fixed_input.mp4 as your new input for the encoding command—this ensures FFmpeg can reliably read timestamps throughout the long video.

2. Combine Your Video Filters #

Merge the scale and watermark filters into a single -vf chain to ensure both are applied:

-vf "scale=-1:$size, overlay=main_w-overlay_w-10:10:overlay_file=logo.png"

This is a cleaner alternative to the movie filter syntax and avoids filter overwrites.

3. Optimize Output for DASH #

Add DASH-specific MP4 flags to make the output file fragmented (chunked), which MP4Box handles far better for packaging:

-movflags frag_keyframe+empty_moov+default_base_moof

These flags:

• frag_keyframe: Creates MP4 fragments at every keyframe (aligns perfectly with your keyint=60 setting)
• empty_moov: Puts the metadata header at the start of the file instead of the end
• default_base_moof: Ensures each fragment has its own metadata, which is required for DASH

4. Adjust Duration (If Needed) #

Your -t 3600 flag limits output to 1 hour. If your input video is shorter than 1 hour, this can trigger EOF warnings as FFmpeg tries to read past the actual end of the file. Only keep this flag if you intentionally want to truncate the video.

Updated, DASH-Compliant Command #

Putting it all together, here’s your revised command:

ffmpeg -y -i fixed_input.mp4 \
  -c:a aac -b:a 384k -ar 48000 -ac 2 -async 1 \
  -c:v libx264 -x264opts keyint=60:min-keyint=60:no-scenecut -r 30 -b:v 2400k -maxrate 2400k -bufsize 1200k \
  -t 3600 \
  -vf "scale=-1:$size, overlay=main_w-overlay_w-10:10:overlay_file=logo.png" \
  -movflags frag_keyframe+empty_moov+default_base_moof \
  format.mp4

Will This Affect MP4Box DASH Packaging? #

The original warning might not cause a total failure, but it could lead to incorrect segment timestamps or incomplete packaging with long files. Fixing the input and optimizing the output MP4 will eliminate this risk.

As for your command’s suitability for DASH:

• Your video settings (keyint=60 at 30fps = 2-second keyframes) are perfect for DASH, as aligning segments with keyframes is required.
• The audio settings meet DASH’s standard requirements (AAC, 48kHz sample rate).
• With the added movflags, your output will be fully compatible with MP4Box’s DASH packaging workflow.

内容的提问来源于stack exchange，提问作者Massimo Vantaggio