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".

Reply via email to