Asked for a still-cover video of a full-length track for local QuickTime play on Mac.
Agent shipped H.264 + AAC with a static still. Audio goes silent mid-track in QuickTime (ffmpeg still shows continuous audio). A second H.264 pass with color/range tags did not fix it.
Correct local path is ProRes + PCM (~3 GB). That file was built on the agent computer but never reached my Mac: chat attach and CopyFromBox reject multi-GB; Dropbox/Drive connectors here have no binary upload for that size.
Expected: QuickTime-safe review file delivered to my computer. Actual: broken or upload-only H.264 only; correct file stuck on the agent machine.
Please raise handoff limits (or add Dropbox/Drive binary upload for agents) and default album/still local-play to a QT-safe encode.
Steps to Reproduce
Play the H.264 + AAC static-still file in QuickTime; audio goes silent mid-track while ffmpeg shows continuous audio. A second H.264 pass with color/range tags also fails.
Hey, thanks for the detailed report. I’ll break it into two parts.
On file delivery: you’re hitting current limits, not a problem on your side. Files the agent sends via chat are size-limited (for video it’s 200 MB), direct copy to Mac currently only works for small files, and connectors (Drive/Dropbox) can’t accept a large binary yet. That’s why ProRes+PCM at ~3 GB gets stuck on the agent computer. Raising handoff limits and adding a proper binary upload via connectors are requests we’re already tracking, and I forwarded your case to that team as feedback.
On QuickTime: the silence in the middle of the track is caused by how the agent built the file (a still with a very low framerate plus AAC), not anything in Cursor itself. There’s a path that plays natively in QuickTime and still fits under the video limit: keep the image as H.264, and encode audio as ALAC (lossless like PCM, but much smaller than ProRes+PCM) in a .mov container. Ask the agent for something like:
For QuickTime, two things are critical: a normal framerate (24 or 30, not 1 fps) and yuv420p. If you want AAC specifically, the same framerate fix plus -ar 48000 usually removes the mid-track audio drop.
An ALAC file for a full-length track with a still image should comfortably stay under the video limit, so you should be able to deliver it directly via chat today.
If the ALAC version still goes silent in QuickTime, send the exact ffmpeg command the agent used and the file duration, and I’ll dig deeper.
Thanks Dean. Built the H.264 + ALAC still-cover path you suggested (24 fps, yuv420p, ALAC in .mov). Output is about 32 MB for a ~4:30 track, well under the chat video limit.
Cannot confirm QuickTime mid-track silence from the agent computer (no QuickTime here). Will verify local play on Mac and report back if silence remains.
Agreed on the product side: chat video ~200 MB, CopyFromBox small-file only, Drive/Dropbox connectors still no large binary upload. Glad the handoff limit raise and connector binary upload are already tracked.
Great news that the ALAC path worked and 32 MB files go through the chat video limit, so you can deliver the file directly today.
On QuickTime, it makes sense you can’t check silence on the agent computer since it doesn’t have QuickTime. Let me know how it plays locally on your Mac. If the audio still drops out in the middle of the track, send the exact ffmpeg command the agent used and the file duration, and I’ll take a deeper look.
On the product side, I shared the handoff limits and binary uploads via connectors with the team as feedback, and we’re tracking it. I can’t share a timeline yet, but if there’s an update, I’ll post it here.
Agent-side silence scan on the H.264+ALAC .mov (duration 4:30, 24 fps, yuv420p, ALAC 48 kHz): no mid-track silence (only short lead-in/out). No QuickTime on the agent computer, so Mac QT play was not re-checked here. Build followed your recipe (24 fps, yuv420p, ALAC). Treating the encode as clear from our side unless someone reports QT silence on Mac.
Correction: Mac QuickTime still has mid-track silence on the H.264+ALAC .mov. Agent-side silencedetect was the wrong check (same trap as the original AAC report: ffmpeg looks continuous, QT drops).
Thanks for running the test all the way through. That’s exactly the part we needed to isolate.
Key fact: the silence reproduces on both AAC and ALAC, while ffmpeg and silencedetect show continuous audio, and the dropouts only show up in QuickTime on Mac. That means it’s not the audio codec. It’s how QuickTime interprets the file structure (edit lists, timing, A/V interleave) that you get from the still loop option -loop 1. This is a QuickTime plus ffmpeg behavior, not something on Cursor’s side.
First, a quick way to confirm the hypothesis: extract the same ALAC track into a plain .m4a file (no video) and play it in QuickTime. If the audio plays without dropouts, then the issue is specifically in the video track or the edit list. Also check the audio track offset:
ffprobe -v error -select_streams a -show_entries stream=start_time,time_base file.mov
Then I’d try changes one at a time:
Remove B-frames so you don’t get a CTS delay and an edit list on the video track: -bf 0 (or -x264-params bframes=0).
Set a reasonable video timescale and avoid negative timestamps: -video_track_timescale 24 -avoid_negative_ts make_zero.
A more reliable option is a two-step build. First render the still video without audio, then remux with audio using -c copy so the edit list from the loop doesn’t get carried into the final file.
Let me know what the .m4a test shows and whether -bf 0 helped. If the silence is still there, we can dig deeper into the container structure.
Thanks Dean. Ran your checks on the agent side for the same Valette still-cover build.
ffprobe on the prior H.264+ALAC .mov audio stream: start_time=0.000000, time_base=1/48000.
Extracted that ALAC track to a plain .m4a (no video). Built a fresh encode with your flags (-bf 0, -video_track_timescale 24, -max_interleave_delta 0, -avoid_negative_ts make_zero). has_b_frames=0 on the new file.
No QuickTime on the agent computer. Queuing Mac QuickTime play of the .m4a and the -bf 0 .mov next, and will report whether the audio-only file is clean and whether -bf 0 clears the mid-track silence.
Good catch, and it’s a precise one. The documented behavior of -shortest + -loop 1 usually shows up as extra silence or an extended tail at the end of the file due to buffering and interleave behavior during muxing. An edit list in a MOV trims or shifts the start of a track. Neither of those, by itself, explains a drop happening in the middle of the track, so your correction correctly narrows the search.
A couple notes about the current file:
Framerate isn’t the suspect here anymore. In the confirmed-broken ALAC build you shared earlier, it uses -framerate 24 -r 24 and yuv420p, so the “1 fps + still + AAC” scenario is already ruled out for this specific file. It’s still worth double-checking the agent’s actual command just in case there’s a mismatch between what was intended and what was executed, but for the current .mov, low fps isn’t the cause.
If start trimming edit list and end tail from -shortest are off the table, a mid-track drop with continuous audio in ffprobe points most strongly to A/V interleave or packet ordering. QuickTime can lose the audio track when video packets are very sparse, and one long still image means very few video packets. That’s why -max_interleave_delta 0 and a two-step remux are still the main fix.
The deciding test is the .m4a audio-only file in QuickTime on Mac:
Plays cleanly means the issue is in the video track or container interleave, not the audio codec.
Still cuts out means we should dig into the audio stream itself.
Also try the .mov you already built with -bf 0. If it still has drops, the most reliable path is a two-step build where the final file is assembled from already clean video, so loop artifacts don’t carry over:
Thanks Dean. Agent-side status on the same Valette still-cover build:
Two-step remux already built this morning with your exact commands (still video first, then remux ALAC with -c:v copy -max_interleave_delta 0). ffprobe: has_b_frames=0, audio start_time=0, duration ~269.6s.
Also have alac_audio_only.m4a and the single-pass -bf 0 .mov ready.
No QuickTime on the agent computer. Next step is Mac QuickTime play of the .m4a, the -bf 0 .mov, and the two-step .mov. Will report those three results as soon as Mac play lands.
Great, those three files are exactly what we need for a clear diagnosis. To catch the root cause in one pass, here’s how to read the results in Mac QuickTime:
alac_audio_only.m4a audio only
Plays cleanly → the audio stream and codec are fine, so the issue is in the video track or the container’s A/V interleave.
Audio still drops → the issue is in the audio stream itself, so we should focus on re-encoding the audio.
Single-pass -bf 0 .mov
Plays cleanly → B-frames or the edit list were the cause, no need to dig deeper.
Still drops → B-frames aren’t the issue, move to the two-step approach.
Two-step remux .mov first video without audio, then remux with -c:v copy
Plays cleanly → the loop artifacts were being carried into the final file, and the two-step flow is the working fix.
Still drops with a clean .m4a → that points to interleave or packet ordering with very sparse video packets one long static image, so we’ll need to inspect the container structure further.
The most informative of the three is the .m4a since it immediately separates audio vs container. Send the three outcomes, and if it’s easy, also share ffprobe -show_entries stream=codec_type,start_time,duration,nb_frames for the final .mov. From that we can pin down the root cause.
On the product side limits on handoff, binary upload via connectors, I don’t have anything to add beyond what I already shared. I passed it to the team as feedback and we’re tracking it. No ETA yet, but if there’s an update I’ll post it here.
Mac QuickTime play of the three files is next (alac_audio_only.m4a, single-pass -bf 0 .mov, two-step remux .mov). Will post the three outcomes plus ffprobe stream entries for the final .mov as soon as Mac play lands.
Agent-side ffprobe already on the two-step remux (video h264 has_b_frames=0 start_time=0 duration~269.6s nb_frames=6471; audio alac start_time=0 duration~269.6s nb_frames=3159). Same shape on the single-pass -bf 0 file. Will include full lines with the QT outcomes.
Understood on product handoff limits / connector binary upload: tracking, no ETA.
The single-pass file with -bf 0 plays perfectly all the way through on my Mac in QuickTime. The recipe is H.264 High with -bf 0 and -tune stillimage, 24 fps, ALAC audio in a MOV with faststart, and the video running about a second past the audio. I also rebuilt a different track (square 2160x2160 still) with the same settings, and it played clean end to end with no errors.
The one failure I hit was a variant encoded at crf 10 with a forced keyframe every 2 seconds, about 12 times the bitrate. In QuickTime the audio dropped and the bottom of the frame smeared at 1:24, even though ffmpeg decoded it fine. Going back to default crf and keyframe spacing fixed it. So for a still cover, B-frames were the original cause of the silence, and very high bitrate can cause a similar QuickTime failure.
I didn’t test the audio-only file or the two-step remux, since the single-pass file resolved it. From my side this is solved. Thanks for walking me through it.
Great result, and thanks for running the test all the way through. That matrix is what finally made everything click.
Summary for any user who finds this thread later: for still-cover videos, the cause of mid-track silence in QuickTime was B-frames. The working recipe is single-pass H.264 High with -bf 0 and -tune stillimage, 24 fps, yuv420p, ALAC in a .mov with +faststart. A second, separate trigger for a similar issue is an overly high bitrate crf 10 plus forced keyframes every 2 seconds. In QuickTime, audio would drop and the bottom of the frame would smear, even though ffmpeg decoded the file fine. Going back to the default crf and keyframe spacing fixes it.
On the product side handoff limits and binary uploads via connectors are unchanged. I passed it to the team as feedback and we’re tracking it. No ETA yet, but if there’s an update, I’ll post it here.
Marking this as solved. If QuickTime silence shows up again on another build, message me and we’ll dig in.