Beiträge von chris*joker

HF_100 & Jim_Pansen:

Zitat

Soll heißen, die Daten werden einfach nicht schnell genug auf die Platte(n) geschrieben.

Wenn das o.a. Testprojekt zuerst gerendert wird und anschl. in CanopusHQ exportiert wird, so wird es innerhalb 8sec. auf die Platte geschrieben. Es handelt sich also NICHT um ein Performance-Problem der Festplatten.

Hallo Herr Peters,

Zitat

1. die aktuelle EDIUS Version unterstützt maximal 10 Kerne

Also, beim Export in ein m2v-Format werden alle Kerne zu 100% beansprucht. Aber sei's drum. Das ist ja gar nicht Thema des Threads.

Zitat

2. Sie sprechen von 12 Kernen, davon ist die Hälfte auch nur virtuell vorhanden

Weil Ihr Kollege von 8 Kernen sprach, habe ich von 12 gesprochen. An den Verhältnissen ändert sich ja nichts, wenn man von 4 und 6 Kernen spricht.

Zitat

3. wie schon erwähnt, hat der HQ Codec den VORTEIL die CPU nur wenig zu belasten

Sind das die Wünsche der Kunden im Zeitalter schneller Multicore-Prozessoren? Meiner ist es nicht.

Zitat

Ich denke, dass Edius schon eine optimale Ausnutzung der CPUs/Cores bietet.

Eine gute Ausnutzung: ja. Eine optimale: nein. Da wird jeder User nach den Erkenntnissen aus den o.a. Tests zu Recht widersprechen müssen.
Es geht mir keineswegs um eine Negativkritik an Edius. Ich bin begeisterter User seit Edius 1.0 und werde es auch weiterhin sein. Aber auf diesem Gebiet besteht seitens Grass Valley auf jeden Fall Handlungsbedarf.

Viele Grüße,
Chris

Wieso muss sich das zügige Arbeiten mit hochkomprimierten Systemen mit einem zügigen Arbeiten in der Timeline (Canopus HQ Codec) widersprechen?

Ich bins nochmal!
Nun möchte ich es aber wissen...

Ich habe den Test wie von Moderator 2 beschrieben durchgeführt und wie ich finde ein überraschendes Ergebnis erhalten:
Das Rendern hat ebenfalls exakt 46sec gedauert, allerdings mit einer Prozessorauslastung von ca.10% auf insgs. 12 Cores.

Was ist daran für mich überraschend? Nun, Moderator 2 hat einen 960er i7 System mit 8 Cores im Einsatz - unser System läuft mit einem 980er i7 und 12 Cores.

Ein um 50% schnellerer Prozessor führt demzufolge nicht zu schnellerem Rendern in der Timeline, sondern einfach dazu, dass die CPU beim Rendern der Timeline um ca. 50% weniger beansprucht wird.
Das hatte ich mir beim Kauf des sehr teuren Prozessors irgendwie anders vorgestellt... für mich zumindest geht es beim Videoschnitt weniger darum Prozessorleistung zu sparen, als vielmehr darum, Zeit zu sparen.

Ist dbzgl. Nachbesserung seitens Grass Valley geplant? Denn für mich sieht es nun so aus, als ob dieses Problem Edius-bedingt ist, also hausgemacht.

Danke & liebe Grüße,
Chris

Au Backe! Ganz dummer Anfängerfehler von mir!!!

Habe den TL-Bereich ungerendert in den Exporter geschickt. Nun braucht der Exporter auch bei mir exakt die gleiche Zeit für den TL-Bereich wie das Rendern innerhalb der TL . Ist also voll OK so!
Wie peinlich...

Sorry, dass ich damit wohl für einen überflüssigen Thread gesorgt habe...

Vielen Dank für die Hilfe,
Chris

Hallo Herr Peters,

das alles ist ja richtig und nachvollziehbar. Aber meine eigentliche Frage ist damit immer noch nicht beantwortet, ob es systembedingt normal ist, dass der Exporter die Daten ca. 8Mal so schnell wie die Timeline verarbeiten kann oder ob ein Fehler in unserem System vorliegt. Es handelt sich schließlich um den gleichen Codec, der bei dem Vergleichstest benutzt wurde. D.h. von Festplatten-Durchsätzen ist dieses "Performace-Problem" wohl unabhängig.

Freundliche Grüße,
Chris Ehrlich

Hallo zusammen,

OK - ich habe nun mal ein Testprojekt angelegt, das wie ich finde schön zeigt, dass irgendetwas faul ist. Entweder in meinen Settings oder in der Edius-Verwaltung.

- Projekteinstellung: 1920x1080i (keine individuellen Änderungen vorgenommen)
- Testbitmap: weiß, 1920x1080i, bmp, 6MB groß
- Testbitmap auf Timeline gelegt und Dauer = 1min gesetzt
- 3D PiP hinzugefügt, und keine Einstellungen im PiP Dialog vorgenommen (habe ihn einfach so gelassen, wie er standardmäßig ist)
- In und Out auf Cliplänge angeglichen (1min)
- Bereich "In-Out" rendern lassen (in den Projekteinstellungen ist definiert, dass dies im Canopus HQ Standard Codec erfolgt)
--> Ergebnis: 52sec, CPU-Auslastung permanent bei ca. 10%
- Nun über den Exporter den gleichen Timeline-Bereich rendern lassen; ebenfalls als Canopus HQ Standard; nur eben über den Exporter (F11)
--> Ergebnis: 8sec, CPU-Auslastung permanent bei ca. 2%

Mein Fazit:
- Am Festplattendurchsatz wird dieses Problem wohl nicht liegen. Dafür ist die Bitmap Testdatei zu klein.
- Habe zwei Kombinationen hinsichtlich Speicherorten des Projektes und der Bitmap-Datei ausprobiert (beides auf verschiedenen Laufwerken, beides auf gleichen Laufwerken). --> Keine nennenswerte Abweichung von den o.a. Ergebnissen.
- Am Festplatten-Modus (IDE vs. AHCI) liegt es nicht. Habe beides ausprobiert, was sich hinsichtlich der Performance nicht unterschieden hat.
- Das Editing innerhalb der Timeline müsste wesentlich schneller berechnet werden können - wird es aber nicht.

Warum???

Ich freue mich auf Eure Tipps & Hinweise...:-)

Das verstehe ich ja. Aber es interessiert mich schon, welche Maßnahmen ich erfreifen muss, um die CPU-Power besser zu nutzen. 10% kann man ja wirklich nicht als effizient bezeichnen... Evtl. gibt es ja nur einen dummen Fehler in meinem Setup.
Wie ist es denn bei Dir oder anderen Usern? Wird bei Euch ebenfalls nur verhältnismäßig wenig CPU beim Rendern von Clips in der Timeline benutzt? Falls das systembedingt "normal" ist, brauche ich ja nicht lange weiterzusuchen.

Danke,
Chris

Hallo Jim,

vielen Dank für die schnelle Antwort.
Hm - ein zu langsames Laufwerk? Das Systemlaufwerk macht 90MB/sec. Alle Daten-Laufwerke machen zwischen 120 und 140MB/sec. Die Schreibgeschwindigkeit kann ich leider nicht messen. Interessant wäre wahrscheinlich ein Live-Monitoring der HDDs hinsichtlich ihrer Schreib/Leseperformance. Kennst Du da ein entsprechendes Tool? Wie gesagt, meines kann nur die Lesegeschwindigkeit auslesen (und das auch nicht "live" während des Arbeitens, sondern bei einem definierten Lesetest, der nichts mit dem aktuellen Workflow zu tun hat).

Keinen spürbaren Performance-Unterschied macht es, auf welcher HDD ich das Projekt abspeichere (denn dorthin werden ja auch die Render-Dateien geschrieben). Ebenso, auf welcher HDD die Footage-Dateien gespeichert sind.

Hmmm... irgendwelche Ideen?

Danke,
Chris

Hallo zusammen,

ich habe beim Rendern innerhalb der Timeline nur eine CPU-Ausnutzung von ca. 10 % (siehe Screenshot). Rendervorgänge dauern dadurch unnötig lange.
Beim Exportieren nach m2v jagt der Prozessor mit vollen 100% den Vorgang voran.
Beim Exportieren nach Canopus HQ avi hingegen liegt die Prozessorauslastung bei 2%.

Ist das normal??? Oder kann es sein, dass auch hier ein IRQ-Konflikt vorliegt? Das war ja bei mir neulich der Fall, als das Playback einfacher Files ruckelte (was mittlerweile aber behoben ist).

Danke,
Chris

Ja, die Erweiterungskarte steckte auch im einzigen PCI Slot.
Im 2. PCI-X Slot steckt eigentlich eine Firewire-Erweiterungskarte. Auf die müssen wir verzichten. Habe alle ICHs im Bios dektiviert, die sich die IRQs mit dem 2. PCI-X Slot teilen (PCI-X Slot 1 und 2 liegen nämlich nicht wie von mir anfänglich angenommen auf einer IRQ). Trotzdem ruckelt die Wiedergabe sobald der 2. PCI-X Slot belegt ist.

An der Kabellänge scheiter's also nicht . Aber vielen lieben Dank für das tolle Angebot!

Fazit: der Slot leibt leer & dann funktioniert's!

LG,
Chris

Hallo,

folgende Tests sind erfolgt:

- Bios auf die aktuelle Version 1107 geupdatet --> keine Veränderung
- alle Karten bis auf die NX ausgebaut --> eine Veränderung - siehe da... es läuft wieder unter 1920x1080i ruckelfrei!
- alle Karten eine nach der anderen wieder eingenbaut --> sobald der zweite PCI-X Slot belegt wird (egal, mit was für einer Karte) stottert die Wiedergabe. Laut Handbuch gibt es nur eine IRQ für diese beiden Slots, was sich aber im Bios zumindest nicht ändern lässt.

Fazit: ich muss den zweiten PCI-X Slot freihalten und dann funktioniert auch alles. Wie ich das mache, weiß ich auch nocht nicht - aber das ist nun mein Problem, und nicht mehr Euers :-).

Vielen Dank für das schnelle feedback & die guten Tipps!!!
Chris

Hallo Erich,

hmmm... unter OHCI (egal ob HD oder SD Einstellungen) pausiert das Playback nach einem Frame - und das egal, ob der Cursor im Bereich eines Clips ist oder im leeren Bereich der Timeline. Sehr seltsam...! Mir gehen so langsam die Ideen aus, wo das Problem liegen könnte.

Liebe Grüße & bis morgen hoffentlich,
Chris

Hallo Erich,

nein - leider rede ich nicht von movs oder AVCHD.
In SD habe ich avis mit Canopus DV (dem guten alten... :-)) getestet.
In HD Clips mit dem Canopus HQ Codec.

Ich habe auf Deine Rückfrage der Projekteinstellungen aber genau diese noch einmal unter die Lupe genommen. Habe dabei herausgefunden, dass beim Wechsel der Projekteinstellungen von 1920x1080i hin zu 1440x1080i alles bestens funktioniert. Mit "bestens" meine ich, dass vier Clips übereinander ohne Rendern ruckelfrei abspielen (mit dem Layouter an verschiedenen Positionen hinterlegt, sodass wirklich alle Clips berechnet werden müssen), wovon der oberste sogar noch ein 3D PiP Key beinhaltet. Mehr will ich ja gar nicht - nur noch das ganze in HD.

Dabei ist es egal, ob Clips mit 1440x1080 zum Einsatz kommen oder welche mit 1920x1080. Bei der Einstellung 1920x1080i ruckelts und bei 1440x1080i nicht. Ich benutze die Standard-Einstellungen von Edius (siehe Screenshots).

Irgendwie vermute ich das Problem beim Treiber der Karte. Es handelt sich um die Version 4.1.0.1 vom Januar 2009. Habe auch hiervon mal einen Screenshot angehängt. Bei der Installation von 5.51 hat es nicht im Gehäse "geklickt", was ja gerne mal geschieht, wenn ein Treiber für die Schnittkarte installiert wird. Laut Readme Datei soll er ja in der Update-exe enthalten sein, obwohl er nicht im Installationsdialog auftaucht. Der neueste Treiber, den man von der Grass Valley Seite als einzelnen Treiber downloaden kann ist aus dem Jahr 2007. Ich glaube, den brauche ich nicht zu probieren...
Welche Treiberversion steht bei Dir im Geräte-Manager?

Liebe Grüße,
Chris

Hallo zusammen,
es ist ja erst kurz her, dass ich mich im Forum informiert habe, ob denn die 64 oder 32 bit Version von Win7 die bessere Wahl für uns wäre. Die Wahl ist wegen der höheren Speichernutzungsmöglichkeit auf die 64 bit Variante gefallen. Nun mein Problem nach Installation der Hardware: wenn als Projekteinstellung HD gewählt wird so ruckelt bereits beim Playback eines einzigen Videofiles (avi, mov, etc.) die Wiedergabe. Bei Projekten in SD gibt es die Probleme nicht.

Die Eckdaten:

Mainboard: ASUS P6T WS PROFESSIONAL X58
Prozessor: CPU Intel S1366 i7-980 XE Box, 6x3.3 GHz
RAM: DDR3-1600 i7 6GB(3x2) Corsair CL8
Betriebssystem: Win 7 Ultimate @64bit
Ediusversion: 5.51 (das Präfix-Dropdown führt nur Version 5.50 auf - daher der Unterschied zur Angabe in der Übersicht des Forums)
Edius-Hardware: HX-E1

Randerscheinungen:
- Die CPU Auslastung liegt während des ruckelnden Playbacks bei 4-6%
- Die RAM-Auslastung liegt während des ruckelnden Playbacks bei ca. 1,5GB (also nur gering höher als wenn Edius nicht gerade läuft)
- Das Ruckeln ist unabhängig von der HDD von der der Clip stammt (verschiedene HDDs getestet).
- Das Ruckeln ist unabhängig von der HDD auf der das Projekt gespeichert ist (verschiedene HDDs getestet).
- Das Ruckeln ist unabhängig von der Soundkarte, die installiert ist (verschiedene Soundkarten getestet).
- Das Ruckeln tritt auch dann auf, wenn der Clip als Clip oder als Timelinebereich gerendert wurde.
- Das Ruckeln ist unabhängig davon, ob es ein SD oder HD-Clip ist (erst beim Wechsel der Projekteinstellung von SD nach HD kommt das Ruckeln).
- Das Ruckeln ist unabhängig von der Clipgröße (ein kurzer 5MB kleiner Clip ruckelt genau so wie ein 5GB großer Clip).

Ich habe nach Austesten der o.a. verschiedenen Konstellationen alle Puffer unter den Anwender- und Hardwareeinstellungen auf max. gesetzt. Leider ohne den gewünschten Erfolg.

Weiß jemand weiter? Ich weiß es nämlich nicht mehr...

Vielen lieben Dank,
Chris

Vielen Dank für die Infos. Wusste ich so nicht!
In meinem Fall wird es dann auf die 64bit Variante hinauslaufen, um die 6GB Ram nutzen zu können. Und wer weiß: vielleicht wird aus Edius eines Tages ja doch noch einmal eine 64bit App...

Danke,
Chris

Hallo zusammen,
ich erhalte in den kommenden Tagen ein neues Mainboard, RAM (6GB) + Prozessor (6x3,33GHZ). Ebenfalls dabei ist ein Win7, um die 6GB Speicher nutzen zu können (bisher arbeite ich mit XP). Hauptsächlich wird der Rechner in Zuzkunft weiterhin fleißig mit Edius (NX-Karte) Videos schneiden, ein bisschen Photoshoppen und ab und zu kleinere Animationen mit dem guten alten Production Studio von ehem. Ulead erstellen.

Nun meine Fragen:
- Edius 5.5 ist weiterhin eine 32bit Anwendung, richtig?
- Welche Vorteile habe ich von einer 64bit Installation von Win7 falls Edius nur 32bit nutzt?
- Laufen im Kompatibilitätsmodus von der Win7 64bit Version "alte" XP Programme? Oder muss hierfür Win7 als 32bit Version installiert werden?

Vielen Dank im Vorfeld,
Chris

Tatsächlich! Detaileinstellung aktivieren und keine Option anhaken. Dann funktionierts!

Wusste gar nicht, dass ich das in der Vorgängerversion (anscheinend unterbewusst) richtig geklickt hatte. Nun denn.

Vielen Dank für die prompte Hilfe!
Chris

Hallo zusammen.
Nach Update auf 5.50 können wir keine DVD mehr direkt aus der Edius Timeline mit Hilfe des Exporters brennen (Exportieren --> Auf Datenträger brennen).
Der Timelinebereich wird zwar im Burn-to-disc Dialog korrekt encodiert, aber anschließend nicht auf den Rohling gebrannt. Der Vorgang wird beendet mit "Codierung erfolgreich". Schön, aber früher lautete die Meldung "Schreibvorgang beendet".
Die Einsstellung "Datenträger-Bilddatei erstellen" ist aktiviert.

Wird anschließend über die Menüleiste "Erfassen" der "Burn-to-disc" Dialog aufgerufen, so kann ein Ordner mit entsprechendem Image ausgewählt werden (z.B. das zuvor wie oben beschrieben erstellte). Das wird dann auch korrekt auf einen Rohling gebrannt.

Wo liegt das Problem?
Vielen Dank für jeden Tip.
Chris

Alles klar.
Vielen Dank für die schnellen Antworten. Wie immer, eine große Hilfe!

Liebe Grüße
Chris