[Ffmpeg-devel] frame accept question

Bram Biesbrouck b
Fri Oct 7 18:46:53 CEST 2005


Op vrijdag 7 oktober 2005 16:50, schreef Martin Boehme:
> 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
> >>>>>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)
>
> 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?

The output format isn't fixed. I'm in the middle of writing an open source 
alternative for Macromedias Captivate or Qarbons Viewletbuilder. The main 
output format will probably be SWF, using a lot of code from the vnc2swf 
project.
I'm mainly still in the design-phase of the project, so I'm exploring and 
experimenting with a lot of alternatives. A largely extendended vncviewer is 
the design I'm currently thinking of, hence the number of questions on this 
topic. Using this approach, I can use the same software to capture a number 
of (remote) desktop-interactions, because the vnc protocol is so low-level, 
it runs an any platform.
To sum up; I'm looking for a good way to translate the FramebufferUpdate 
messages of the vncserver to an generic format, from where I can use 
different encoders to produce different output movies.
I use the vncrec project as a starting point to study the vnc protocol (along 
with a number of whitepapers). When I fully understand it, I plan to  produce 
a "general" vnccapture-library that I can use in an advanced GUI for 
postprocessing (adding comments, sound, directives, etc).

All remarks and pointers are welcome.

Bram





More information about the ffmpeg-devel mailing list