On 7 Aug 2018, at 05:46, Gyan Doshi <gyando...@gmail.com> wrote: > > On 06-08-2018 02:38 AM, Nick Ludlam wrote: > >> Is there a likely culprit for this? Something where the audio is >> fractionally longer than the video, somehow? > > This is likely it. > > Try with -vsync vfr i.e. > > ffmpeg -loglevel verbose \ > -i > /Users/nickludlam/Work/data-ingest/Resolve_prores_422/s1-4-1_004_04_25mm_5.mov > \ > -i > /Users/nickludlam/Work/data-ingest/Resolve_prores_422/s1-4-1_004_04_25mm_5.mov > \ > -i > /Users/nickludlam/Work/data-ingest/Resolve_prores_422/s1-4-1_004_04_25mm_5.mov > \ -t 1 -f lavfi -i anullsrc=r=48000:cl=stereo -vsync vfr -pix_fmt yuv420p > -filter_complex "[0:v] [0:a] [1:v] [1:a] [2:v] [2:a] > concat=n=3:v=1:a=1[v][a]" -map "[v]" -map "[a]" -preset fast -c:v libx264 > -b:v 2000k -c:a aac -b:a 96k /tmp/output.mp4
Hi Gyan, I tried with -vsync vfr, and while it suppresses the "*** 1 dup!” output while encoding, I still end up with more frames in the output stream than in the sum of the inputs. In this reduced case it does fix the output, but when I run my full ~ 90 file concat filter it doesn’t. I need to work on another reduced case. From the docs, -vsync vfr will cause the input frame timestamps to be dropped, but I don’t understand why during a straight forward concatenation I’d end up with two frames with the same timestamp. Surely a straight concatenation would see timestamps steadily increasing then snapping back to zero again at the join point? Thanks, Nick _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".