#5 maintain movie timing

encoding (5)

The current limitation on xvidcap is CPU power. At the limit, xvidcap will
silently drop frames. Possible solutions:

* Could the user be told?

For instance, the GUI could usefully display the current frame rate in
green, and that rate could turn red if it drops below what the user
requested. It's fine if this takes up a bit of space as the gui can be
detached from the grabbing frame.

* Could there be compromises along other dimensions?

Instead of dropping frames, could xvidcap decrease some other variable? I
don't know enough to even suggest what, but something like color depth or
pixel density?

The goal would be to avoid messing up the time -- even if the quality
suffers, the movie would still maintain true time. This is really
important for lots of purposes -- research, documentation. So it would be
better if other dimensions of quality suffered a bit.

I realize size is the simplest dimension to control cpu demand, but we
would often want to grab something where a user might want a full-screen


  • Karl H. Beckers

    Karl H. Beckers - 2003-10-30

    Logged In: YES

    (a) the user can be told ...
    if you start xvidcap in verbose mode (-v) you will see messages
    like "missing so and so many ms. for frame somesuch". The
    with letting the user know is that sometimes the messages
    slow down xvidcap enough to cause more dropped frames than you
    would have otherwise. Now, while writing to a TTY may be
    slow, I suppose the issue would remain with any other means.

    (b) of course there are other tunables ...
    - lower the quality
    in the options dialog there is a control to do that. The
    controls the bitrate for the MPEG encoding ... to be used
    to quality controls for saving JPEGs in e.g. Gimp.
    The algorithm for setting the bitrate may be less than optimal,
    because I have only been able to determine sensible limits to
    the birate very very roughly.
    Then again, bitrate will only help, if you don't suffer from
    issues: 8-bit pseudo-color displays will require preprocessing
    for every frame, so do even 32bit TrueColor displays on big-
    endian machines.

    - try MPEG1 and convert to MPEG4 later
    might be easier on the CPU but require slightly more disk space.

    - decrease the frame rate or size of the area to be captured
    this will help most ...

    So, back on (a) I'm not really sure that's really a big benefit.
    Like: how much does it help you if you see a red light telling
    you of frame drops? It tells you the video you're capturing atm
    might not be usable, OK. So you would stop, do some tuning
    and start again.
    My usual strategy would be: Do a test-capture on the target
    machine, have a look at the result, tune, try again, and start
    the real capture when all settings are OK.
    The only case I can see where there might be a real benefit
    from an
    accurate frame rate vs. the visual impression of the resulting
    video would be one where exact timing is the key issue of
    the thing that's supposed to be shown in the video.

    Something I can imagine is to have an autotuning option, where
    you can start the capture and xvidcap will change values for
    bitrate and frame rate till there are no more dropped frames.
    Afterwards the user could be asked if he/she wants to keep the
    parameters determined.

  • David Liontooth

    David Liontooth - 2003-12-21

    Logged In: YES

    Thanks for the thoughts -- I see the difficulties. An autotuning option is
    very attractive. Ideally, there would be two options:

    * Next to the compression field, a checkbox saying "Optimize" and a
    mouseover that explains, "Lower the bitrate as necessary to avoid
    dropped frames"

    * Next to the frame per second field, a checkbox saying "Optimize" and
    a mouseover that explains, "Lower the frame rate as necessary to avoid
    dropped frames"

    If both are checked, you would get full autotuning -- wouldn't it even
    make sense to set this as default?

    I agree this is a better solution than wasting CPU cycles on warnings --
    which would have the effect of more frames being dropped!

    BTW, I didn't realize the compression parameter worked for mpeg4 -- I
    though it was just jpeg. In the parameter file .xvidcap.scf, the line says

    # compression (PNG, GZIP)

    If it also works for mpeg (all types?), that should be indicated, and it's
    great news!


Log in to post a comment.