Forums > Jitter

Is it possible 100 frames for one second Mr. jitmatriset?

October 21, 2008 | 10:55 pm


October 22, 2008 | 5:12 pm

nobody, ok, trying other formulation:

How many fps is possible/allowing in jitter?

Thank you!


October 22, 2008 | 6:46 pm


October 22, 2008 | 7:27 pm


October 23, 2008 | 9:30 am

On Wed, Oct 22, 2008 at 9:27 PM, Bruce Tovsky wrote:

> i believe that Derrick is inquiring about "capture rate" here, not playback
> fps – correct, Derrick? i am curious about this too, as there are some
> digital still cameras on the market now that can shoot fairly hi-rez movies
> in "burst mode" that reach the frame rates of slo-mo. up to now i have been
> using software solutions to post-process standard framerate movie clips into
> slo-mo.cheers
> b
>
>
The frame rate in Jitter is limited by your computer architecture and
possibly the sheduler. I’m guessing jit.qt.grab works in low priority mode.
If you set the low priority sleep (performance settings) to 1ms, it should
(in theory) be possible to process at 1000fps. In practice this is less and
fluctuates depending on the processing load.

Frame rates in Jitter are always fluctuating and I don’t know of any way to
get around this (except for using the non-realtime engine). A while back I
had to capture a steady 200fps data input stream (non video) in Jitter and
only managed to do so by getting the data inside a separate thread and
buffering the output to max so the sheduler could access the data in little
chunks while no frames were dropped. You can only do this from within your
own external and like I said it wasn’t video.

I see where the black frames in your patch are coming from. You are using a
metro to drive the counter and qt.grab. The bangs to the jit.qt.grab will be
deferred to the low priority queue (and thus dropping frames depending on
processing load) while the counter will be counting every single bang. So
for every frame that is dropped, you will skip the position in the
jit.matrixset, resulting in an empty/black frame. Try using a qmetro
instead. You will loose your notion of "time" because you don’t know what
frames (and how many) have been dropped. You could record a timestamp for
every frame to work around this issue somehow.

Afaik the only way to capture a steady framerate is to use direct-to-disk,
but I’m not very experienced with this so don’t take my word for it.

Thijs


October 23, 2008 | 9:43 am

On Thu, Oct 23, 2008 at 11:30 AM, Thijs Koerselman <
thijskoerselman@gmail.com> wrote:

>
> I see where the black frames in your patch are coming from. You are using a
> metro to drive the counter and qt.grab. The bangs to the jit.qt.grab will be
> deferred to the low priority queue (and thus dropping frames depending on
> processing load) while the counter will be counting every single bang. So
> for every frame that is dropped, you will skip the position in the
> jit.matrixset, resulting in an empty/black frame. Try using a qmetro
> instead. You will loose your notion of "time" because you don’t know what
> frames (and how many) have been dropped. You could record a timestamp for
> every frame to work around this issue somehow.
>
>
BTW removing the jit.pwindow and other unnecessary object in the process
chain will improve the framerate. Jit.pwindow is particularly "expensive". I
always put a gate in front of them so you switch them on only when you want
to look it.

I just realized that there might be an easy alternative to the timestamp
thing I mentioned. If you filter the empty frames from your matrixset output
stream you will keep the time correct (using metro like you do now). You can
for example display the last valid frame instead. Next step might be to do
some fancy interpolation…

Thijs


October 24, 2008 | 5:24 pm


Viewing 7 posts - 1 through 7 (of 7 total)