On Tue, Oct 04, 2016 at 10:13:41PM +0100, Derek Buitenhuis wrote: > On 10/4/2016 9:58 PM, Michael Niedermayer wrote: > > breaks fate > > and the change to fate looks wrong, the last frame is lost > > make fate-filter-fps > > TEST filter-fps > > --- ./tests/ref/fate/filter-fps 2016-10-04 14:46:19.642736770 +0200 > > +++ tests/data/fate/filter-fps 2016-10-04 22:54:01.859353244 +0200 > > @@ -84,4 +84,3 @@ > > 0, 78, 78, 1, 30576, 0xa2fcd06f > > 0, 79, 79, 1, 30576, 0xa2fcd06f > > 0, 80, 80, 1, 30576, 0xa2fcd06f > > -0, 81, 81, 1, 30576, 0xd4150aad > > Test filter-fps failed. Look at tests/data/fate/filter-fps.err for details. > > This "break" may actually be more correct output, but I am not familiar enough > with lavfi or vf_fps to say. Removing the last frame in case where it should > have > been removed was the entire point of this patch.
the change to fate is wrong the input has a timebase of 1/3000, all timestamps are multiplies of 100 its thus basically 30 fps (with skiped frames) and the used -vf fps=30 should restore skip frames to make it cfr, loosing the last frame entirely is wrong in this case codec copy: #tb 0: 1/3000 ... 0, 0, 0, 600, 4287, 0xa259fe7b 0, 600, 600, 700, 3951, 0x1bfc9daf, F=0x0 0, 1300, 1300, 6000, 4232, 0x75aeff18, F=0x0 0, 7300, 7300, 800, 4124, 0xc244436a, F=0x0 0, 8100, 8100, 695, 4104, 0x24aa4d34, F=0x0 without fps=30 0, 0, 0, 1, 30576, 0xcdc29b3d 0, 6, 6, 1, 30576, 0x5c83656c 0, 13, 13, 1, 30576, 0x26b67f83 0, 73, 73, 1, 30576, 0xa2fcd06f 0, 81, 81, 1, 30576, 0xd4150aad [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
