Le duodi 2 nivôse, an CCXXIII, Michael Niedermayer a écrit : > with these 2 patches and the zoompan example from the docs > ./ffmpeg -f lavfi -i testsrc -vf > "zoompan=z='min(zoom+0.0015,1.5)':d=700:x='if(gte(zoom,1.5),x,x+1/a)':y='if(gte(zoom,1.5),y,y+1)':s=640x360" > -qscale 1 test.avi > > i get > frame= 729 fps= 69 q=1.0 Lsize= 2735kB time=00:00:29.16 bitrate= > 768.5kbits/s dup=0 drop=19571 > that is a pretty huge number of dropped frames > > is this intended ?
It is expected, but not intended.
The current code, with the example (d=700), produces the following
timestamps:
input = 0 → output = 0 .. 699
input = 1 → output = 701 .. 1400
input = 2 → output = 1402 .. 2101
input = 3 → output = 2103 .. 2802
Notice the skipped values. This is monotonic, but nonsensical.
With the changed code, the timestamps are these:
input = 0 → output = 0 .. 699
input = 1 → output = 1 .. 700
input = 2 → output = 2 .. 701
input = 3 → output = 3 .. 702
Now, this is non-monotonic, but predictable and logical.
I suppose the "correct" way of getting consistent timestamps, with a
constant zoom duration, is to adjust the input timestamps. With output at
25 FPS, it needs input at 25/700 = 1/28 FPS. Therefore, with input:
testsrc=r=1/28,settb=1/25
The original code gives this:
input = 0 → output = 0 .. 699
input = 700 → output = 1400 .. 2099
input = 1400 → output = 2800 .. 3499
input = 2100 → output = 4200 .. 4899
The changed code gives this:
input = 0 → output = 0 .. 699
input = 700 → output = 700 .. 1399
input = 1400 → output = 1400 .. 2099
input = 2100 → output = 2100 .. 2799
The crux of the problem is that zoompan features make it very tricky with
regard with timestamps. The current code is clearly wrong, but in a subtle
way, almost impossible to detect.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
