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


    Oct 21 2008 | 10:55 pm

    • Oct 22 2008 | 5:12 pm
      nobody, ok, trying other formulation:
      How many fps is possible/allowing in jitter?
      Thank you!
    • Oct 22 2008 | 6:46 pm
    • Oct 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
    • Oct 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
    • Oct 24 2008 | 5:24 pm