Wie mit Threads Daten von Webcam holen?

kuhlmaehn

Erfahrenes Mitglied
Hallo,
ich will über eine DLL Daten von einer Webcam holen und verarbeiten. Für die Verarbeitung sind viele Threads verantwortlich, die alle auf die Bild-Daten zugreifen müssen.
Dafür fallen mir jetzt zwei Varianten ein.
1. Es gibt einen zusätzlichen Thread bzw. ein zusätzliches Objekt mit einem Thread, welches nur die Daten von der Kamera holt und alle anderen Threads holen die Daten dann von diesem.
2. Alle Threads holen sich selber über die DLL die Daten der Kamera.

Jetzt bin ich mir nicht sicher, was da besser ist?
Bei 1. könnte es ja sein, dass vor lauter Threads der Kamera-Thread nicht oft genug rankommt und daher die Daten nicht immer auf dem neuest möglichen Stand sind.
Bei 2. könnte es (vielleicht) sein, dass die DLL bzw. Kamera mit den ganzen Anfragen nicht klar kommt. Oder meint ihr es ist normal, dass die DLL von alleine die Daten zwischenpuffert und nicht jedes Mal neu holt?
Wie würdet ihr das machen?
Danke!
 
Hi

Ich würde Variante 1 nehmen.

Prinzipiell glaub ich erst einmal nicht, dass mir eine DLL eine Arbeit abnimmt, die nicht explizit irgendwo in der Beschreibung steht.
Wenn in der Doku nichts steht, das gebuffert wird, nicht drauf verlassen.

Nur...was meinst du bei 1 genau mit dem "nicht oft genug drankommen"?
Dass der Computer allgemein zu langsam sein könnte? Das wird durch 2 auch nicht besser.
Und alles andere kann man über den Code mehr oder weniger ausgleichen.
 
Naja z.B. auf einem Ein-Kern-Prozessor und mit 50 Threads neben dem "Datenhol"-Thread kann es ja sein, dass der "Datenhol"-Thread die Daten immer nur alle 51 Zeiteinheiten (= wie lange jeder Thread rechnen darf) einmal holen kann. Vielleicht wäre die Webcam aber im Stande, ein Bild alle 20 Zeiteinheiten auszuliefern. Dann würde man ja ganz schön an Genauigkeit verlieren oder nicht?
 
Die holen sich das Kamera-Bild und durchsuchen ihren Bereich im Bild nach Rot.
Ist also nicht wirklich Zeitkritisch, es wäre allerdings schön, wenn das Bild möglichst aktuell ist.
 
Willst du die Rotanteile eigentlich speichern/weiterverarbeiten oder nur "in Echtzeit" anzeigen?
 
Ist das wichtig? :)
Weiß ich noch nicht genau, warscheinlich beides. Erstmal will ich nur etwas in der Konsole ausgeben...
 
Naja...wenn du nur in einer Gui ein Diagramm oder so anzeigst wäre es ja kein Problem, bei Bedarf einfach ein paar Frame-verarbeitungen auszulassen.
Die Threadpriorität vom Auslesethread raufstellen und das wärs.

So aber musst du dich wohl einfach darauf verlassen, dass der Compute genug Leistung übrig hat.
Der Scheduler teilt schon gerecht auf, das ist nicht das Problem.
 
Zuletzt bearbeitet:
Ah ok :)
Ich programmiere in C#, meinst du da ist der Scheduler so schlau? Merkt der, dass wenn Threads Daten aus einem anderen Thread beziehen, dass dieser dann wohl wichtiger ist und daher öfter darf? Das wäre natürlich sehr gut.
Mit der Priorität hatte ich auch überlegt aber in C# gibt es irgendwie nur so absolute Werte, dass dann der Bild-Thread immer zuerst an der Reihe wäre (http://msdn.microsoft.com/en-us/library/system.threading.thread.priority(v=vs.71).aspx).
Aber ich denk, ich verlass mich dann wohl auf den Scheduler. Danke dir :)
 
Ich programmiere in C#, meinst du da ist der Scheduler so schlau?
.NET verwendet auch nur den internen vom Windowskernel.

Merkt der, dass wenn Threads Daten aus einem anderen Thread beziehen, dass dieser dann wohl wichtiger ist und daher öfter darf?
Mit den eingebauten Threadsafemöglichkeiten (zB. Keyword lock in c#) kann man das ziemlich gut seinen eigenen Vorstellungen anpassen. Alles eine Frage des Codes.

Mit der Priorität hatte ich auch überlegt aber in C# gibt es irgendwie nur so absolute Werte
Hmm..machen relative Werte einen Sinn? A muss 97.59% von B haben? :D
Bei deinem Link sind 5 Stufen angegeben. Mit den nativen C-Funktionen hat man Zugriff auf 6.
Und das wars dann auch schon wieder. Die Beschränkung hängt ja auch nicht wirklich von der Programmiersprache ab, sondern wieder mal vom Kernel.

Gruß
 
Zurück