Search options (Page 89 of 129)

Normalement toutes les webcams qui marchent par ailleurs sous Windows devraient fonctionner…
En quoi consiste le bug exactement ?
Est-ce que ça ressemble au bug décrit plus haut ? (InvalidArgument=la valeur '0' n'est pas valide pour "selectedIndex')

S'il s'agit d'un autre problème, pouvez vous copier les données de l'erreur ?
Merci

It was introduced in the experimental versions after 0.8.7 release. Check the sticky threads at the top of this forum.

(Note: your user name is very reminiscent of what a spam bot might use, it is fortunate you posted a message before I checked for the daily dose of spam accounts )

This alternate driver was mentioned in the other thread. Maybe it's more capable ?

edit: forget it, it's the same one apparently.

If you can please try with the experimental version here and report if it's better or not. As noted in the bug report I have tried to mitigate the issue according to most common cause for this error message.
However I cannot reproduce the issue myself (tried with 100+ stopwatches) and so far there's no feedback about whether the changes are helping or not.
Thanks

Also, when comparing two videos, it would be nice to be able to directly take the current frame from one screen and import it as an image overlay on the second screen.
Combined with the resizing controls and maybe opacity property, it should allow for a good deal of flexibility.

En attendant que ce soit supporté, vous pouvez toujours importer des images au format SVG en passant par la fonction Image > Référence d'observation.
Tous les fichiers .svg qui sont déposés dans le sous dossier "guides" du dossier d'installation sont accessible ainsi sous forme de menu.

Il est d'autre part possible de convertir une image JPG ou autre en SVG (dans Inkscape par exemple).

Lorsque l'outil "Image" sera intégré, il le sera probablement sous la forme d'une extension du concept de référence d'observation (à l'heure actuelle uniquement pour les images vectorielles SVG).
(voir aussi [en])

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.

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…

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.