On 23/03/18 13:15, Carl Eugen Hoyos wrote: > 2018-03-23 14:12 GMT+01:00, Mark Thompson <s...@jkqxz.net>: >> On 23/03/18 01:28, Kai Hendry wrote: >>> Thank you Moritz! Damn, I feel like a fool. ;) >>> >>> Unfortunately Mark's suggestion doesn't seem to have an impact. >>> >>> As you hopefully can see here: >>> https://s.natalian.org/2018-03-23/1521768226.mp4 >>> >>> The mouse still doesn't move smoothy across the screen. Hence I feel >>> it's dropping frames! >>> >>> https://s.natalian.org/2018-03-23/1521768226.mp4.log >>> ... >>> *** 38 dup! >>> ... >>> *** 33 dup! >>> ... >>> *** 40 dup! >>> ... >>> *** 39 dup! >>> ... >>> *** 40 dup! >>> ... >>> *** 38 dup! >>> ... >>> *** 40 dup! >>> ... >>> *** 39 dup! >>> ... >>> *** 39 dup! >>> ... >>> *** 39 dup! >>> frame= 439 fps= 30 q=-0.0 Lsize= 1870kB time=00:00:14.58 >>> bitrate=1050.4kbits/s dup=381 drop=34 speed=0.985x >> >> This is still duplicating a very large number of frames for video sync. As >> suggested previously, please try with video sync disabled ("-vsync 0") or >> without audio. > > To the best of my knowledge, this would produce an invalid output file: > The input is not cfr, FFmpeg's mov output does not support vfr.
Indeed, hence "try". It may produce an output with bad properties, but if it contains all of the desired frames then it's clear that the problem lies somewhere in timestamps and video sync, and therefore that efforts should be focussed there to get a correct and complete output. - Mark _______________________________________________ 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".
