[Ffmpeg-devel] frame accept question

Martin Boehme boehme
Fri Oct 7 16:50:11 CEST 2005

Bram Biesbrouck wrote:
> Op vrijdag 7 oktober 2005 11:09, schreef Martin Boehme:
>>Rich Felker wrote:
>>>On Thu, Oct 06, 2005 at 06:09:11PM +0200, Martin Boehme wrote:
>>>>Bram Biesbrouck wrote:
>>>>>I used the output_example.c file as a framework for my program. In a
>>>>>loop of (say) 50 iterations, I feed the encoder 50 screenshots
>>>>>(encoder-framerate=25 fps, images are 1024x710 px, depth 24 and 32 bpp).
>>>>>I timed the generation of one image and it takes the generator about 10
>>>>>ms, so that leaves 30 ms for the encoder to encode the frame (right?)
>>>>>at a correct framerate.
>>>>>When I run the program, the loop (image-generation + encoding) takes
>>>>>about 2.5 sec and the video plays back too fast (because of frame
>>>>>dropping I suppose). I tried to look up the length of the video but I
>>>>>couldn't find out how (mplayer says it's 0:00). I guess it's around 2
>>>>>sec, but in theory it should be less, I think, because of the frame
>>>>>I don't really have a specific question, but can someone explain to me
>>>>>what's happening in this encoding-process?
>>>>It simply sounds as if encoding is taking too long... for the resolution
>>>>of video that you're encoding, that sounds plausible. That also explains
>>>>why the video is playing too fast... 2.5 seconds worth of video is being
>>>>played in 2 seconds.
>>>>The easiest solution to this is of course to just reduce the
>>>>framerate... to maybe 15 fps.
>>>Reducing the resolution is a much better option. Reducing framerate is
>>I would say that depends on the situation. This guy is trying to do
>>screen capture. He's probably more interested in preserving fine detail
>>than in whether the frame rate is 15 or 25 fps. Yes, I know about chroma
>>subsampling and that MPEG is not a particularly good format for doing
>>screen capture in general, but it's what he's trying to do.
>>I do see where you're going with the argument that, in general, dropping
>>frames can be a bad idea. However, in this case, we're talking about a
>>movie of a GUI. Most changes in GUIs are things (new windows, menus, new
>>characters in an editor window) popping up on an otherwise unchanged
>>background. If you drop the frame on which the change occurs, it's
>>simply going to happen one frame later...
> Actually, I experienced that MPEG is't the best codec for screen capturing, so 
> I started to read a little bit more and suddenly, I realised that if a 
> particular codec would support the VNC-way of updating screens/frames, the 
> encoding would be very simple and the resulting file probably very small.
> Does anyone know of such a codec? (Apart of the VNC protocol itself off 
> course)

Not sure if there's anything in FFmpeg that will work well, because most 
of the codecs are designed for "real-world" videos. I was assuming you 
didn't have the option of using something obscure... where does this 
have to play?


Martin B?hme
Inst. f. Neuro- and Bioinformatics
Ratzeburger Allee 160, D-23538 Luebeck
Phone: +49 451 500 5514
Fax:   +49 451 500 5502
boehme at inb.uni-luebeck.de

More information about the ffmpeg-devel mailing list