1 Topic by Dee (edited by Dee 2011-02-10 12:55:29)

  • Dee
  • Member
  • Offline

Using two capture screens and two usb cameras with a delay of 8 seconds with 640x480 resolution seems to work fine.
Once delay is set any longer or resolution increased Kinovea freezes and comes up with error message that there is insufficient storage available to process the command even on a desktop PC with 16GB available.

I have tried setting the memory available in the preferences section to maximum (1 Gb) but that did not help

Is there any work around for this, or can memory settings be increased.?
Thanks

2 Reply by Dee (edited by joan 2011-02-11 21:33:45)

  • Dee
  • Member
  • Offline

Managed to capture a log of when this happens, hope someone can make some sense of it as it would be really useful to capture video from two different directions at the same time.

(…)
494465 - DEBUG - [1] - FrameGrabberAForge - Picked best size capability: 1600×1200 px @ 10 fps
494465 - DEBUG - [1] - FrameServerCapture - Screen connected.
494465 - DEBUG - [1] - FrameGrabberAForge - Starting to grab frames from the capture device.

<snipped long log>

3 Reply by joan (edited by joan 2011-02-11 21:42:49)

  • joan
  • joan
  • Admin
  • Offline

Thanks for the report and the log.
I have cut the long log from your message and pasted it in a file and attached it in bug 235.
I have reproduced this issue as well.

By the way, from reading the log, it would seem that you are also suffering from bug 234 ? (Trying to change capture resolution doesn't work: disconnects and reconnects at the default resolution.)

4 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Small update on this issue,
The cause of the error is that on a 32-bit system, we can't address more than 2GB of memory per process. (It's not actually running out of memory per se, it's running out of a way to address it. The ammount of physical memory in the computer is irrelevant).

Now this limit is a hard one, so the only solution is to prevent the buffers from taking up that much space.

I think the most straightforward way from the user point of view would be if the memory setting in the preference were to be understood for both screens combined ?
Other suggestions welcomed.

5 Reply by Dee

  • Dee
  • Member
  • Offline

Thanks Joan,

that makes sense but is always going to be a problem, has anyone considered producing a 64 bit version of Kinovea?

I do appreciate that I am well beyond the limits of my knowledge here and may be asking for the impossible.

6 Reply by Archer4

  • Archer4
  • Member
  • Offline

It does run on 64bit...
smile

7 Reply by Dee

  • Dee
  • Member
  • Offline

Thanks, I know it runs on 64 bit, I do and very very good it is to.   So do many other 32 bit programs, the point is that it has a maximum of 2GB addressable memory (a feature of all 32 bit programs) which is reducing its ability to buffer high definition video in the latest experimental version.   

That is why I asked the question about the possibility of a true 64 bit version of Kinovea.  See discussion above.

Hope that explains the reason for the question a little better

8 Reply by Archer4

  • Archer4
  • Member
  • Offline

I see, I have the IT knowledge of a small mollusc and always thought that the 2Gb restriction was a function solely of the OS rather than the program too

Thanks

9 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

It is a restriction of the OS, but Kinovea is compiled as a 32 bit program. When installed on a 64 bits OS, it runs in compatibility mode.

10 Reply by Dee

  • Dee
  • Member
  • Offline

Same question I am afraid

Is anyone thinking of producing (or is it recompiling) a 64 bit version of Kinovea which would get around this problem ?

I belive 64 bit Windows is slowly becoming mainstream even on laptops, though I appreciate there is a huge base of 32 bit still out there. 

Incidentally I tried to run two copies of Kinovea under Windows 7 to sidestep this issue but cannot find any way that will allow me to do it (usual hold shift or left click does not open another copy when trying to open Kinovea though it works fine for many programs)  Does anyone know if it can (or cannot ) be done ?

11 Reply by Dee

  • Dee
  • Member
  • Offline

Although I am still interested in any answers to my previous post I have found that if you set the buffer in preferences to under 600MB and keep both cameras on VGA you can achieve a reasonably stable buffer of 15 seconds on both screens.

Comments
1) The slider bar seems to become very inaccurate doing this (the number of seconds indicated becomes very erratic when trying to adjust)
2) The cameras still want to drop out and go back to their default resolution (impatiently waiting the release of the bug fix for this)
3) It would be really nice to be able to achieve a little better screen resolution, is is possible to have the buffer written to somewhere else (eg high speed flashdrive or a SSD)

Hope this helps anyone else trying this.

12 Reply by joan

  • joan
  • joan
  • Admin
  • Offline
Dee wrote:

Although I am still interested in any answers to my previous post I have found that if you set the buffer in preferences to under 600MB and keep both cameras on VGA you can achieve a reasonably stable buffer of 15 seconds on both screens.

Yes, this corresponds to what I meant by saying "the memory setting in the preference to be understood for both screens combined".
Right now, if you set the memory setting sufficiently low, the combined space of the two buffers + the rest of the program + the .NET runtime, will stay under 2GB and you won't have the crash.

Dee wrote:

Comments
1) The slider bar seems to become very inaccurate doing this (the number of seconds indicated becomes very erratic when trying to adjust)

Here is some more context to understand how it currently works:
The number of seconds is actually computed dynamically by taking into account: 1. the memory space taken by each frame, 2. the total amount of memory allowed, and 3. the speed at which we receive frames.

The trick here is that when choosing a configuration (say 30fps), we only ask the device to send us frames at this rate, but in reality, we may receive frames a bit more slowly. And the difference really depends on the burden the CPU is currently under.
For now I decided to track and use the actual frame rate we receive. It is more accurate, but its stability depends on external parameters…
I agree it's not optimal. I'm not too sure how to improve this part right now. It also negatively impacts the recording function because we store the frame rate of the created video upfront, and then we receive frames even more slowly, which makes the final video not frame rate accurate…

Dee wrote:

3) It would be really nice to be able to achieve a little better screen resolution, is is possible to have the buffer written to somewhere else (eg high speed flashdrive or a SSD)

Well, at some point we'll have to consider this option, yes. Right now I'd like to explore a bit more the in-memory buffer concept. I think it opens some possibilities that will not be available with an on-disk buffer.

13 Reply by Dee

  • Dee
  • Member
  • Offline

Many thanks for the detailed explanation and the very prompt reply.  Sorry if I was a bit slow to understand what you were getting at about the buffer

I was wondering if it is possible to split the buffer for the two screens so that you could have detailed video on one capture screen whilst the other has a less detailed overall picture.  At the moment it seems to split the buffer 50/50 and so you end up with a short delay possible on the high resolution picture and a very long possible delay on the low resolution one.