Hallo nochmal,
wir wollen demnächst unseren Rechner aufrüsten, insbesondere weil der für Videobearbeitung mit BroadCast2K genutzt werden soll. Mein jetziger Rechner (400Mhz) hat beim Framegrabbing arge Pro- bleme und lässt viele Bilder aus. Meinen Erkenntnissen nach liegt das maßgeblich an der Rechenleistung - die Festplatte ist ausreichend schnell und auch RAM ist reichlich vorhanden. Deshalb meine Frage: Ab welcher Leistungsklasse ist Video- bearbeitung unter Linux möglich? Es sollen damit Video-CDs er- stellt werden. Dabei müssen 25 Bilder/s bei einer Auflösung von 352x288 Pixel + Stereoton 44.1kHz aufgezeichnet und nach Möglichkeit gleich komprimiert werden. Momentan sind die Athlon/1000 ziemlich preiswert - hat jemand Erfahrungen ob dessen Leistung schon ausreicht ist? Gibt es pauschal eine prozentuale Angabe, wie sich die Rechen- leistung eines Systems erhöht, wenn man anstelle SDRAMs die gleiche Kapazität an DDR-RAMs installier?
Danke,
Matthias
Matthias Petermann wrote:
Hallo nochmal,
Momentan sind die Athlon/1000 ziemlich preiswert - hat jemand
Aufgrund der aktuell angekündigten Preissenkung bei AMD kannst Du auch gleich nach einem Größeren greifen.
http://www.heise.de/newsticker/data/ciw-28.08.01-000/
Ciao, Rico
On Wed, Aug 29, 2001 at 10:51:58AM +0200, Matthias Petermann wrote:
stellt werden. Dabei müssen 25 Bilder/s bei einer Auflösung von 352x288 Pixel + Stereoton 44.1kHz aufgezeichnet und nach Möglichkeit gleich komprimiert werden. Momentan sind die Athlon/1000 ziemlich preiswert - hat jemand Erfahrungen ob dessen Leistung schon ausreicht ist?
Mit einem $CPU-400 kann man *locker* einen derartigen Strom grabben. Unkomprimiert reicht schon eine 200er CPU. Die Frage ist also: Sind die Platten schnell genug? Was für einen Codec wollt Ihr benutzen? Was für ein Grabber?
Wir hatten mal folgendes Szenario:
Dual-P2-400, BT848, ein Strom in CIF (352x288) gegrabbt, Video und Audio komprimiert, übers Netz geschickt, 3 äquivalente Ströme übers Netz empfangen, dekomprimiert und angezeigt. Und das in 20-25fps bei 768kBit/s. (Vierpunktkonferenz)
Ein CIF Strom erzeugt eine Datenrate von 6,5MB/s bei 25fps, mit schwacher Kompression reicht auch schon eine langsame Platte.
Erzähl doch mal ein bissl mehr Details...
Gruß, Eric
Hallo,
On Wed, Aug 29, 2001 at 03:46:44PM +0200, Eric Schaefer wrote:
Mit einem $CPU-400 kann man *locker* einen derartigen Strom grabben. Unkomprimiert reicht schon eine 200er CPU. Die Frage ist also: Sind die Platten schnell genug? Was für einen Codec wollt Ihr benutzen? Was für ein Grabber?
Also ich konnte Framegrabbing bisher nur direkt in BroadCast2000 testen - unter Verwendung des eingebauten Quicktime-(Codecs?) oder wie man das nennt. Die eigentliche Bildkompression erfolgt bei diesem wohl auch als mpeg. Mit dieser Konf. ist der K6/400 quasi nicht brauchbar - die Platte ist schnell genug, es liegt wirklich am Komprimieren der Frames. Ist euch eine schnellere Variante dieses Framegrabbers bekannt?
Erzähl doch mal ein bissl mehr Details...
Naja die Details sehen momentan so auf: AMD K6/2-400, 128MB RAM, Festplatte IBM UDMA/33 10GB, BT878 (848 kompatibel) Ich will eine ganze Sammlung Konzert-Videos von VHS auf VideoCD "retten" - was ich mit BroadCast2000 tun will. Im Linux-Magazin 06/2000 hab ich da auch einen ganz interessanten Artikel gelesen, insbesondere was das Umwandeln der Framesequenzen in echte VideoCD- Tracks betrifft ist das gut erklärt.
Viele Grüße,
Matthias
On Wed, Aug 29, 2001 at 11:10:49PM +0200, Matthias Petermann wrote:
On Wed, Aug 29, 2001 at 03:46:44PM +0200, Eric Schaefer wrote:
Mit einem $CPU-400 kann man *locker* einen derartigen Strom grabben. Unkomprimiert reicht schon eine 200er CPU. Die Frage ist also: Sind die Platten schnell genug? Was für einen Codec wollt Ihr benutzen? Was für ein Grabber?
Also ich konnte Framegrabbing bisher nur direkt in BroadCast2000 testen - unter Verwendung des eingebauten Quicktime-(Codecs?) oder wie man das nennt. Die eigentliche Bildkompression erfolgt bei diesem wohl auch als mpeg. Mit dieser Konf. ist der K6/400 quasi nicht brauchbar - die Platte ist schnell genug, es liegt wirklich am Komprimieren der Frames. Ist euch eine schnellere Variante dieses Framegrabbers bekannt?
Deine TV-Karte ist der Framegrabber, nicht die Software. Für MPEG ist die CPU tatsächlich zu klein. Ich kann Dir leider nicht sagen, was Du für ein System brauchst um live MPEG zu kodieren. Ich glaube, sowas macht man normalerweise mit einer Kompressionskarte, deren Preis jenseits von Gut und Böse liegt. Bei MPEG und verwandten Verfahren hängt die benötigte Rechenleistung auch immer vom Videomaterial ab. Wenn es viel Gezappel gibt, dauert die Komprimierung eben etwas länger... Sinnvoller ist es normalerweise, den Strom erstmal unkomprimiert auf die Platte zu werfen und dann hinterher zu komprimieren. Braucht man halt große Platten. Und Geduld.
Naja die Details sehen momentan so auf: AMD K6/2-400, 128MB RAM, Festplatte IBM UDMA/33 10GB, BT878 (848 kompatibel)
Hey, das ist mein System. Gibs wieder her!
Ich will eine ganze Sammlung Konzert-Videos von VHS auf VideoCD "retten" - was ich mit BroadCast2000 tun will. Im Linux-Magazin 06/2000 hab ich da auch einen ganz interessanten Artikel gelesen, insbesondere was das Umwandeln der Framesequenzen in echte VideoCD- Tracks betrifft ist das gut erklärt.
Hört sich nach Privatvergnügen an und dafür willst Du extra in einen neuen Rechner investieren? Eine extradicke Platte rein und dann offline komprimieren. Ist billiger.
Gruß, Eric
Hallo,
On Thu, Aug 30, 2001 at 08:19:02AM +0200, Eric Schaefer wrote:
Hört sich nach Privatvergnügen an und dafür willst Du extra in einen neuen Rechner investieren? Eine extradicke Platte rein und dann offline komprimieren. Ist billiger.
...das ist noch das nächste Problem. Bei meinem BIOS ist eine Plattenkapazität von 33,7GB das Höchste der Gefühle. Eine 40GB Platte mit UDMA/100 hab ich schon hier liegen. Auch ein Flash-Update auf die aktuellste Version brachte da keine Besserung. Wie in einem anderen Thread hier schon geschrieben wurde, erkennt Linux die Platte ja trotzdem - allerdings mit katastrophalen Übertragungsraten ( <1MB/s ). Ich hab schon ver- sucht mit hdparm mal mit den DMA-Einstellungen eine Besserung zu erreichen - die Platte lässt sich dann gar nicht mehr an- sprechen.
Matthias
On Thu, Aug 30, 2001 at 10:38:28AM +0200, Matthias Petermann wrote:
...das ist noch das nächste Problem. Bei meinem BIOS ist eine Plattenkapazität von 33,7GB das Höchste der Gefühle. Eine 40GB Platte mit UDMA/100 hab ich schon hier liegen. Auch ein Flash-Update auf die aktuellste Version brachte da keine Besserung. Wie in einem anderen Thread hier schon geschrieben wurde, erkennt Linux die Platte ja trotzdem - allerdings mit katastrophalen Übertragungsraten ( <1MB/s ). Ich hab schon ver- sucht mit hdparm mal mit den DMA-Einstellungen eine Besserung zu erreichen - die Platte lässt sich dann gar nicht mehr an- sprechen.
CIF, 16Bit, unkomprimiert 1h -> 17GB
Gruß, Eric
On Wed, Aug 29, 2001 at 10:51:58AM +0200, Matthias Petermann wrote:
bearbeitung unter Linux möglich? Es sollen damit Video-CDs er- stellt werden. Dabei müssen 25 Bilder/s bei einer Auflösung von 352x288 Pixel + Stereoton 44.1kHz aufgezeichnet und nach Möglichkeit gleich komprimiert werden.
Mit dem Format wird eine halbwegs aktuelle Festplatte selbst mit unkomprimierten Daten fertig.
Momentan sind die Athlon/1000 ziemlich preiswert - hat jemand Erfahrungen ob dessen Leistung schon ausreicht ist?
Das kommt ganz auf den verwendeten Codec an. Die nötige Rechenleistung kann da um 2 Größenordnungen auseinander liegen. So pauschal ist das also nicht zu beantworten. Videos in der Größe konnte man schon mit einem besseren Pentium-1 auf die Platte bannen und dann 'offline' in andere Formate umrechnen lassen.
Gibt es pauschal eine prozentuale Angabe, wie sich die Rechen- leistung eines Systems erhöht, wenn man anstelle SDRAMs die gleiche Kapazität an DDR-RAMs installier?
Nein. Nach allem was ich bisher zu real existierenden Boards mit DDR-RAM gelesen habe, bringt die theoretisch doppelten Speichertransferrate (im Idealfall) abgesehen von synthetischen Benchmarks nahezu nichts.
Reinhard
lug-dd@mailman.schlittermann.de
-
Eric Schaefer -
Matthias Petermann -
Reinhard Foerster -
Rico Koerner