[Ffmpeg-devel] frame accept question

[Bram Biesbrouck]

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
> >>> dropping.
> >>>
> >>>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
> > evil..
>
> 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...
>
> Martin

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)

Bram