[FFmpeg-devel] eval lavfi filter

[Michael Niedermayer]

On Wed, Feb 25, 2009 at 01:04:15PM +0100, V?ctor Paesa wrote:
> Hi,
> Michael Niedermayer said:
> > On Wed, Feb 25, 2009 at 09:07:57AM +0100, V?ctor Paesa wrote:
> >> Hi,
> >>
> >> Michael Niedermayer said:
> >> > On Tue, Feb 24, 2009 at 11:56:54PM +0100, Stefano Sabatini wrote:
> >> >> On date Tuesday 2009-02-24 23:26:23 +0100, Michael Niedermayer
> >> encoded:
> >> >> > On Tue, Feb 24, 2009 at 10:39:22PM +0100, Stefano Sabatini wrote:
> >> >> > > Hi.
> >> >> > >
> >> >> > > On date Tuesday 2009-01-20 09:37:21 +0100, V?ctor Paesa
> >> encoded:
> >> >> > > > There is also a problem for filters that remove frames, as
> >> >> ffmpeg uses/expects the fps of the input video (instead of the
> >> filtered one) and generates duplicated frames to reach that.
> >> >> >
> >> >> > ffmpeg should not duplicate frames anymore if the container can
> >> >> handle it
> >> >>
> >> >> Could someone give some more hints about this?
> >> >
> >> > just try the example that caused frame duplication and check the
> >> resulting file, avi/mov/mp4/nut should have no duplicate frames
> >> anymore. feedback and bugreports welcome ...
> >> >
> >> >
> >> >>
> >> >> Also I suppose this is not necessarily a lavfi-related issue,
> >> right?
> >> >
> >> > no
> >>
> >> Right, I was able to trace it (but not able to fix) to ffmpeg.c, it
> >> seems that do_video() is duplicating frames. Maybe adding a new
> >> "-vsync 3" that would not perfom any frame rate duplication?
> >
> > just tried
> > ffmpeg -v 9 -i matrixbench_mpeg2.mpg -r 90 test.avi
> >
> > no duplicated frames are generated and considering you provide not a
> > single word of a hint of what you did or what did not work i cant help
> 
> I'm sorry, I answered without reading your commit 17555, please discard
> my comments.
> 
> Some tests on r17555:
> 
> in.avi = http://samples.mplayerhq.hu/avi/fpstest/gwl-bounce-sample-25fps.avi
> that is 60 seconds long and has 1500 frames.
> 
> $ ffmpeg  -i in.avi -vfilters fps=1 -y -an out_fps1.avi
> FFmpeg version SVN-r17555, Copyright (c) 2000-2009 Fabrice Bellard, et al.
>   configuration: --enable-shared --disable-static --cpu=prescott
> --extra-cflags=-DX_DISPLAY_MISSING -I/usr/local/include -include
> llrint.h --extra-ldflags=-L/usr/local/lib --extra-libs=-l llrint
> --enable-gpl --enable-nonfree --enable-libamr-nb --enable-libamr-wb
> --enable-swscale --enable-avfilter --enable-avfilter-lavf
> --enable-pthreads --enable-avisynth --enable-bzlib --enable-libfaac
> --enable-libgsm --enable-libmp3lame --enable-libtheora --enable-libx264
> --enable-zlib --build-suffix=-SVN
>   libavutil     49.15. 0 / 49.15. 0
>   libavcodec    52.18. 0 / 52.18. 0
>   libavformat   52.29. 2 / 52.29. 2
>   libavdevice   52. 1. 0 / 52. 1. 0
>   libavfilter    0. 4. 0 /  0. 4. 0
>   libswscale     0. 7. 1 /  0. 7. 1
>   built on Feb 25 2009 11:41:58, gcc: 4.2.4
> 
> Seems stream 0 codec frame rate differs from container frame rate:
> 30000.00 (30000/1) -> 25.00 (25/1)
> Input #0, avi, from 'in.avi':
>   Duration: 00:01:00.03, start: 0.000000, bitrate: 822 kb/s
>     Stream #0.0: Video: mpeg4, yuv420p, 640x352 [PAR 1:1 DAR 20:11], 25
> tbr, 25 tbn, 30k tbc
>     Stream #0.1: Audio: mp3, 22050 Hz, stereo, s16, 56 kb/s
> Output #0, avi, to 'out_fps1.avi':
>     Stream #0.0: Video: mpeg4, yuv420p, 640x352 [PAR 1:1 DAR 20:11],
> q=2-31, 200 kb/s, 90k tbn, 25 tbc
> Stream mapping:
>   Stream #0.0 -> #0.0
> Press [q] to stop encoding
> frame=   60 fps= 35 q=6.9 Lsize=     292kB time=59.04 bitrate=  40.5kbits/s
> video:252kB audio:0kB global headers:0kB muxing overhead 16.000823%
> 
> 
> The out_fps1.avi has 60 frames, as expected, but VirtualDub believes has
> 1476 frames due to the 25 tbc probably. GSpot reports 60 frames.
> ffmpeg is also confused and ffmpeg -i out_fps1.avi out%04d.png produces
> 1475 PNGs.
> 
> 
> ffmpeg  -i in.avi -vfilters fps=1 -r 1  -y -an out_fps1_r1.avi
> 
> The out_fps1_r1.avi has 60 frames, works fine in VirtualDub, GSpot, ffmpeg.

all mostly as expected, did you expect anything else?
btw none of this is really related to lavfi, and just to make it clear is
in no way a reason to hold up lavi integration

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090225/e9ccacfb/attachment.pgp>