Hey there, let's break down your questions one by one—this is a super common gotcha with FFmpeg video trimming, so I'll walk you through the fixes and the "why" behind it.

You mentioned you already targeted a keyframe timestamp but still aren't getting an exact start—this is usually down to a missing flag or timestamp handling quirk in FFmpeg. Here's the fixed command and why it works:

• Add -exact_seek to enforce strict keyframe locking: When placing -ss before -i (for fast seeking), FFmpeg might still adjust to a nearby keyframe even if you specify an exact timestamp. -exact_seek forces it to respect your target keyframe time, as long as it's a valid keyframe.
• Verify your keyframe timestamp is 100% accurate: Double-check that your <start time> matches a true I-frame (keyframe) in the source. Use this ffprobe command to list all keyframe timestamps:

  ffprobe -select_streams v -show_frames -show_entries frame=pict_type,pkt_pts_time -of csv=print_section=0 <SrcFile> | grep -i "I,"
  

  You'll get output like I,12.345—make sure your target time matches one of these values exactly (down to the millisecond).

Here's the corrected fast trimming command:

ffmpeg -exact_seek -copyts -ss <exact_keyframe_time> -t <duration> -i <SrcFile> -c copy <DstFile>

Note: I removed -start_at_zero here because it can interfere with timestamp preservation when using -copyts. If you need the output to start at timestamp 0, add it back after testing—but start without it to rule out playback confusion caused by reset timestamps.

FFmpeg's behavior depends entirely on where you place the -ss flag relative to -i, and whether you're using stream copy (-c copy) or re-encoding:

• When -ss is before -i (input-side seeking):
  This is fast because FFmpeg skips decoding the entire video up to your start time. It scans the video's index to jump directly to the nearest valid keyframe (since non-keyframes like P/B frames rely on prior keyframes to render correctly). Without -exact_seek, it might land on the closest keyframe before your target time if your timestamp is slightly off.
• When -ss is after -i (output-side seeking):
  This is slower but more precise for non-keyframe trimming. FFmpeg decodes every frame from the start of the video up to your target time, then starts outputting. However, you can't use -c copy here unless your start time is a keyframe—otherwise, the initial frames will be corrupted (they lack dependency data from prior keyframes).

Additionally, -copyts preserves the source video's original timestamps, while -start_at_zero resets the output's start timestamp to 0. These flags affect how media players interpret playback start times, which can sometimes make it seem like the trim is off even if the frame data is correct.

If you need to trim at a non-keyframe and match the source's exact audio/video parameters, you'll have to re-encode the video (stream copy only works from keyframes). Here's how to do it properly:

Step 1: Extract the source's exact parameters #

Use ffprobe to get all critical video settings you need to match:

ffprobe -v quiet -print_format json -show_streams <SrcFile>

Look for the video stream entry and note:

• codec_name (e.g., h264)
• width/height (resolution)
• r_frame_rate (frame rate)
• bit_rate (or crf if using constant rate factor)
• profile (e.g., High)
• level (e.g., 4.1)

Step 2: Build the re-encoding command #

Use the extracted parameters to mirror the source exactly. For example, if your source is H.264 with High profile, 1080p, 30fps, and CRF 23:

ffmpeg -ss <any_start_time> -t <duration> -i <SrcFile> -c:v libx264 -profile:v high -level:v 4.1 -r 30 -crf 23 -c:a copy <DstFile>

• -c:a copy is safe here because audio frames are independent (no keyframe dependency), so you can stream copy audio without re-encoding.
• If the source uses a constant bitrate instead of CRF, replace -crf 23 with -b:v <bitrate> (e.g., -b:v 5000k).
• For other codecs (like HEVC/h265), adjust the encoder (e.g., -c:v libx265) and corresponding parameters.

Note: Re-encoding takes longer than stream copy (it has to decode and re-encode every frame), but it's the only way to get precise non-keyframe trimming while matching the original video's quality and settings.

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