Also die 19" Gehäuse hat doch eigentlich jeder Computerhändler an der Straßenecke und auch Google liefert dafür relativ viele brauchbare Ergebnisse:
http://www.google.de/search?hl=de&q=19%22+computergeh%C3%A4use&meta=
Auch bei Elektroniksortimentern wie Reichelt, Conrad, etc. sind mir 19" Industriegehäuse noch in Erinnerung geblieben. Meist ist bei den handelsüblichen 19"-Gehäusen zwar die Frontoptik nicht die eines Hippotizers oder eben die der angesprochenen ArKaos Medienserver aber hier zählen ja auch eher die inneren Werte.
Ich bin gespannt was dieser Thread noch an nützlichen Hardwaretipps für Videorechner ans Licht bringen wird. Aus eigener Erfahrung hatte ich häufig den Eindruck, das Medienserver (auch Eigenbauten) mit Ati Grafikkarten besser funktionieren, als eben NVidia Karten. Auch einige Videoleute haben mir hier und da schon berichtet, das Ati Grafikkarten "angeblich" herstellungsbedingt eine bessere Anbindung an die übrige Hardware haben und deshalb wohl besser, schneller bzw. ruckelfreier agieren. Vielleicht kann sich dazu ja jemand äußern, der in der Materie gut bewandert ist.
Bezüglich deiner Frage zur Ansteuerung habe ich die Erfahrung gemacht, dass sich ArKaos (Eigenbau-Medienserver mit NVidia-Karte) gut über ArtNet in die Lichtsteuerung integrieren lässt. Das funktioniert aber von Version zu Version unterschiedlich gut. Auch die Effekte lassen sich viel besser steuern u. kombinieren und zudem auch schnell mal live zurechtschrauben. Die ausschließliche Bedienung mit Maus u. Tastatur ist dagegen ein Krampf, vor allem wenn mal eben Farbe, Effekteinstellung, Größe o.a. geändert werden muss. In Kombination mit einer GrandMA (für einfache Zwecke reicht schon die OnPC-Version + Remotesteuerung) lies sich ArKaos sehr gut bedienen.
Bei 4 Video-Layern und hoher Effektlastigkeit fängt aber zumindest die Eigenbau-Variante schnell an das Video nur noch sporadisch und zerstückelt (ruckelig) auszugeben.
kurze Frage zum Verständnis: Wozu die Capture-Karte?
Zum Thema Grafikkarte: Oft ist es eher ein CPU bzw. Bus-Problem wenn 2D-Video ruckelt.
Hier kann man durch radikales Abspecken auf der Software-Seite eine deutliche Verbesserung erreichen. Vor allem Windows-Komponenten, die standardmäßig laufen.
4 Video-Streams (SD) gleichzeitig sind keine Raketenwissenschaft...
kurze Frage zum Verständnis: Wozu die Capture-Karte?
Zum Thema Grafikkarte: Oft ist es eher ein CPU bzw. Bus-Problem wenn 2D-Video ruckelt.
Hier kann man durch radikales Abspecken auf der Software-Seite eine deutliche Verbesserung erreichen. Vor allem Windows-Komponenten, die standardmäßig laufen.
4 Video-Streams (SD) gleichzeitig sind keine Raketenwissenschaft...
Die Capture Karte ist für eine Livecam gedacht denk ich mal, so eine haben wir dafür nämlich letztens händeringend gesucht...
Die Capture Karte ist für eine Livecam gedacht denk ich mal, so eine haben wir dafür nämlich letztens händeringend gesucht...
Nenn mich altmodisch, sowas mache ich meist per ADC analog-DV über Firewire... Oder ich nehme gleich eine Kamera mit DV-out, wenn die Kabellänge es hergibt.
Zum Thema Grafikkarte: Oft ist es eher ein CPU bzw. Bus-Problem wenn 2D-Video ruckelt.
Hier kann man durch radikales Abspecken auf der Software-Seite eine deutliche Verbesserung erreichen. Vor allem Windows-Komponenten, die standardmäßig laufen.
Das natürlich alles unnötige abgeschaltet wird ist selbstverständlich. Schon allein um Systemfehlern entgegenzuwirken, die von Tools verursacht werden die im Betrieb sowieso nicht genutzt werden.
Über welchen Eingang kann man am besten eine Livecam einbinden. ( Kabellänge meistens so um 50 - 60 m wenn der MS am FOH steht, sonst kürzer bis 25m.
Billig: FBAS über BNC-Leitung, stinknormales Captureinterface (USB-'Grabber' oder PCI-TV-Karte, gibts fürn Appel und n Ei beim Arlt oder sonstwo)
Gut und nicht ganz so billig: DV/1394 über Firewire. Brauchste allerding so ab 20m nen Aufholverstärker damit das läuft, kostet um die 50€ pro Stck und die Kabel sind auch teuer. Es gibt btw. auch Konverter von FBAS auf Firewire, so könntest du die Analoglösung oben mit der 1394-Lösung hier kombinieren, aber so richtig sinnig ist das auch nicht...
Amtlich und überhaupt gar nicht mehr billig: SDI-Captureinterface und der entsprechende Kram drumherum (SDI-fähige Kamera oder Mischer o.ä.)
Grüße,
phlo
bei 50m wird die digitale (DV-) Lösung unpraktisch, bei der Datenrate sollte es theorethisch funktionieren (nur 1/4 der Datenrate und nur unidirektional), ich würde es aber analog verkablen, also FBAS.
Und (siehe oben) würde ich 200 Euro für einen FBAS-DV-Wandler ausgeben, dann per Firewire in den Rechner. Damit wird der Rechner durch den live-Input nicht belastet. USB ist da suboptimal.
Die Grafikkarte ist dann jetzt wieder ein ganz anderes Thema.
Dabei ist auf 2D-Performance zu achten, 3D ist für Video-Ausspielung egal (und kostet Strom und produziert Wärme).
Und (siehe oben) würde ich 200 Euro für einen FBAS-DV-Wandler ausgeben, dann per Firewire in den Rechner. Damit wird der Rechner durch den live-Input nicht belastet. USB ist da suboptimal.
Hast du da konkrete Werte oder Erfahrungen? Würde mich echt interessieren, da mal eine ca.-Prozent-Angabe zu bekommen, die üblichen Vergleiche werden ja immer nur für Harddisks gemacht...Aber logisch klingts schon, nachdem Firewire ja selber für Datenflusskontrolle etc. sorgt, im Gegensatz zu USB wo der Rechner den ganzen Steuerkram auch noch nebenher miterledigt.
Nur hab ich beides schon verwandt und es hat meinen (nur ca. 1/2 Jahr alten Core2Duo) Rechner beides recht stark in die Knie gewzungen. Wobei das auch eine Liveshow war mit 2 Ebenen MPG-Video, Effekten, und eben dem Livebild über 1394...und die Latenz oberste Priorität hatte...aber ich hab das gleiche Setup schon auch mit USB-Capture gefahren und keine nennenswerten Unterschiede in der gefühlten Leistung festgestellt...
Würde mich freuen wenn du dazu noch ein bißchen was aus der Praxis schreiben könntest!
Grüße,
phlo
Hallo,
habe mich auch schonmal mit der materie befasst, habs aber mangels notwendigkeit in letzter zeit nicht weiterverfolgt. habe aber mit folgenden komponenten schon gute tests gemacht:
windows xp embedded - (einfach um keine leistung an nicht benötigte dienste, etc. zu verlieren)
bei dualcore/quad, etc. darauf achten dass die speicherbänke getrennt angesprochen werden können (machen imho mittlerweile die meisten boards)
habe mir von 4gb ram 2gb für eine ramdisk reseviert um hochauflösenden (1080p) content ohne delay abrufbar zu haben, klappt wunderbar. hatte das ganze noch nicht mit capture-card probiert, aber mein nächster test wäre gewesen den aufgenommen content wieder im ramlaufwerk zu puffern um delays evtl. zu verkürzen. weiss aber auch nicht ob das gegen ein ordentliches raid-system zum tragen kommt. bei heutigen ram-preisen auf jeden fall günstiger (nur auf zugriffszeiten und durchsatz bezogen). wenns einer testet würd ich gerne mal nen erfahrungsbericht lesen.
was grafikkarten angeht bin ich nicht auf den laufenden, habs selber mit zwei nvidia 7800ern probiert, denke aber dass mit bluray und so weiter verstärkt karten mit ordentlicher 2D-performance kommen werden.
achja, 4 strams (SD) - sind keine Raketenwissenschaft 
grüße,
m
ps: lass mal was hören wenns läuft
..Aber logisch klingts schon, nachdem Firewire ja selber für Datenflusskontrolle etc. sorgt, im Gegensatz zu USB wo der Rechner den ganzen Steuerkram auch noch nebenher miterledigt.
Genau dadurch "steht" der firewire-Stream, wenn er steht, bei USB weiß man nicht, wie lange bzw. wie sauber...
Also es kann dann z.B. sein daß ein Frame ausgelassen wird oder Artefakte entstehen. Wie schlimm das letztlich im Gesamtkontext ist - keine Ahnung.
mpeg-Video ist auch ein großer Performance-Fresser, wenn man Effekte darüberlegt. Da muß fast jedes Einzelbild aufwändig aus einem früheren Bild und den bildweisen Änderungen errechnet werden.
Besser einen Codec nehmen, der jedes Bild diskret codiert und dafür größere Dateien produziert (sollte nicht das Problem sein, Festplatte sehe ich hier eher unkritisch im Vergleich zur codec-Schlacht)
Hier ist z.B. P/M-JPEG ein guter Kompromiss, hierbei wird jedes Einzelbild mit dem JPEG-Codec codiert. Die CPU-Last ist deutlich geringer.
Jo, ich hatte mir die MPEG auch nicht rausgesucht 
Aber was macht man wenn der Drummer der auftretenden Formation erst 10 Min. vor der Show an der Videoregie auftaucht und dir ne HDD mit MPGs gibt mit den Worten "Wäre cool wenn ihr da so ne Art Visuals-Show machen könnt..."? Stimmt, man macht das beste draus 
Zumindest mach ich es soweit möglich immer so...
Aber back to topic, wenn ich dich richtig verstanden habe ist also der Unterschied USB-Firewire nicht wirklich stark einwirkend auf die Systemlast, sondern mehr auf die Performanz/Zuverlässigkeit des eigehenden Streams? Woher kommt es dann dass bei einer 1394-Übertragung auch Dropframes auftauchen können? Ist das dann quasi erst ein Drop wenn das Frame schon im Rechner wäre, und halt der Rechner nicht mit verarbeiten nachkommt, im Gegensatz zum USB-Drop, wo der Rechner das Frame schon gar nicht mehr rechtzeitig abholen konnte? Ich glaube ich sollte mir dringend mal die genauen 1394-Specs durchlesen... :?
Grüße,
phlo
Aber back to topic, wenn ich dich richtig verstanden habe ist also der Unterschied USB-Firewire nicht wirklich stark einwirkend auf die Systemlast, sondern mehr auf die Performanz/Zuverlässigkeit des eigehenden Streams? Woher kommt es dann dass bei einer 1394-Übertragung auch Dropframes auftauchen können? Ist das dann quasi erst ein Drop wenn das Frame schon im Rechner wäre, und halt der Rechner nicht mit verarbeiten nachkommt, im Gegensatz zum USB-Drop, wo der Rechner das Frame schon gar nicht mehr rechtzeitig abholen konnte? Ich glaube ich sollte mir dringend mal die genauen 1394-Specs durchlesen... :?
Grüße,
phlo
Solange die 1394-Quelle ein stabiles Signal liefert und der Rechner die Daten schnell genug "wegspeichert" ist alles gut.
Drop Frames kommen bei mir aus zwei Hauptgründen vor.
1. Rechner zu langsam / mit anderen Sachen beschäftigt
2. 1394-Quelle liefert Timecode-Sprung
3. (einmal passiert) Laserstrahl trifft Kameraoptik. Es war eine Bandaufzeichung, die ab dieser Stelle ca. 30 Sekunden unbrauchbar war. Ein Stream wäre in diesem Fall wohl auch zusammengebrochen.
