Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel - Was ist für Videobearbeitung besser geeignet? Dualcores oder Quadcores?
Bandit666
2008-04-20, 13:41:24
Hi!
Ich habe eine kleine Frage zu Prozessoren von Intel!
Was ist für Videobearbeitung aktuell besser geeignet? Dualcores oder Quadcores?
Lieber einen 3Ghz Dualcore oder besser einen 2.5Ghz Quadcore?
Stehe vor der Wahl und bin eher unschlüssig. Das Eingesetzte Programm (Magix VDL plus) schweigt sich zu diesem Thema auch aus.
mfg
Das würde mich auch interessieren. aus preisgründen würde ich momentan aber eher zu nem dualcore greifen
welche Engine nutzt denn das Magix-Programm?
blackbox
2008-04-20, 13:50:22
Hi!
Ich habe eine kleine Frage zu Prozessoren von Intel!
Was ist für Videobearbeitung aktuell besser geeignet? Dualcores oder Quadcores?
Lieber einen 3Ghz Dualcore oder besser einen 2.5Ghz Quadcore?
Stehe vor der Wahl und bin eher unschlüssig. Das Eingesetzte Programm (Magix VDL plus) schweigt sich zu diesem Thema auch aus.
mfg
Kommt immer auf die eingesetzte Software an.
In deinem Fall: beim Support nachfragen.
Kommt immer auf die eingesetzte Software an.
In deinem Fall: beim Support nachfragen.
Dito.
Das kann man so pauschal nicht beantworten und es hat auch nichts mit Intel-Prozessoren im Speziellen zu tun.
Bandit666
2008-04-20, 14:33:12
welche Engine nutzt denn das Magix-Programm?
Mc-Encoder (MainConcepts)
Kommt immer auf die eingesetzte Software an.
In deinem Fall: beim Support nachfragen.
Habe ich natürlich gemacht. Leider bis jetzt keine Antwort.
Dito.
Das kann man so pauschal nicht beantworten und es hat auch nichts mit Intel-Prozessoren im Speziellen zu tun.
Ja aber irgendwo muss ich ja anfangen mit dem nachfragen! :biggrin:
Dann lasst es uns mal bitte verallgemeinern. Also weg von speziellen Programmen und hin zum konvertieren aller möglichen Formate mit Dualcore bzw. Quadcore.
mfg
Dann lasst es uns mal bitte verallgemeinern. Also weg von speziellen Programmen und hin zum konvertieren aller möglichen Formate mit Dualcore bzw. Quadcore.
Der Quadcore ist natürlich schneller, wenn man alle seine Kerne ausnutzen kann. Video-Encoding bietet sich grundsätzlich recht gut zur Parallelisierung an und es laufen in der Praxis auch oft mehrere Filter (Skalieren, Schärfen, Entrauschen, Deblocking, Deinterlacing, etc.) im Hintergrund mit, die einen eigenen Kern dankend annehmen. In der Praxis sind in diesem Spektrum viele - aber natürlich auch nicht alle - Programme für Multicore-CPUs optimiert (Beschränkungen auf "nur" Dual-Core sind mir noch nicht untergekommen). Der Mainconcept Encoder soll sogar sehr gut mit mehreren Kernen skalieren und dürfte entsprechend auch von einem Quadcore profitieren.
Der Quadcore natürlich schneller, wenn man alle seine Kerne ausnutzen kann. Video-Encoding bietet sich grundsätzlich recht gut zur Parallelisierung
Ach und wie bitte?
Viel mehr als die Bewegungsvorhersage lässt sich m.M. nach nicht parallelisieren
Oder man lässt B-Frames außen vor. Selbst bei der Bewegungsvorhersage muss man Qualitätsabstriche machen wenn man die einzelnen Macroblöcke auf Threads verteilt.
Ach und wie bitte?
Viel mehr als die Bewegungsvorhersage lässt sich m.M. nach nicht parallelisieren
Oder man lässt B-Frames außen vor. Selbst bei der Bewegungsvorhersage muss man Qualitätsabstriche machen wenn man die einzelnen Macroblöcke auf Threads verteilt.
Ich habe in diesem Bereich selbst noch nichts geproggt, beziehe mich also rein auf Dinge die ich gelesen habe. Die Praxis scheint eine gute Parallelisierbarkeit aber zu bestätigen - kaum ein anderes Anwendungsfeld skaliert so gut mit mehreren Kernen wie die Video-Bearbeitung.
Ich habe in diesem Bereich selbst noch nichts geproggt, beziehe mich also rein auf Dinge die ich gelesen habe. Die Praxis scheint eine gute Parallelisierbarkeit aber zu bestätigen - kaum ein anderes Anwendungsfeld skaliert so gut mit mehreren Kernen wie die Video-Bearbeitung.
Ich hab einen VideoCodec selber geschrieben und die Parallelisierbarkeit ist von sehr vielen Rahmenbedingungen abhängig. Was ich bis jetzt gesehen habe bezieht sich auch immer auf die Bewegungsvorhersage die um die 30% an der gesammten Laufzeit teilhat. Nur das wird faktoriell beschleunigt.
Byteschlumpf
2008-04-20, 17:00:56
Der Premiere MediaEncoder nutzt bei meinem Quad bis zu 80% aus - laut Taskmanager.
Multiprozessorunterstützung ist heute Standard und muß in den Specs eines Programms nicht mehr explizit erwähnt werden, was vor wenigen Jahren noch ganz anders war.
KinGGoliAth
2008-04-20, 18:45:36
mittelfristig wird ein quad besser ankommen. wenn du viel mit videoschnitt zu tun hast würde ich mir jetzt keinen dual core kaufen nur weil dein programm aktuell noch keinen angemessenen nutzen aus quads zieht.
Bandit666
2008-04-20, 19:03:04
Ah ok. Danke für eure Postings.
Ich tendiere auch zum QC.
Aber mal angenommen mein oder ein Programm kommt mit beiden CPU klar. Was wäre von der Performance denn besser.......2x3,17Ghz oder 4x2,5Ghz?
mfg
Lieber einen 3Ghz Dualcore oder besser einen 2.5Ghz Quadcore?Bei Magix wäre ich mir garnicht so sicher, ob sie von Mainconcept nicht eine Sparversion des Endcoders einsetzen. Normalerweise ist MainConcept aber ohne Tadel.
Sonst habe ich gerade das hier gelesen. Sollte so passen.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6445268#post6445268
Das beste wäre wirklich das System - wenn es nicht zu teuer sein sollte oder wenn du dir nicht sicher bist ob 45nm Quads auf deinem Board gehen - einen Q6600/G0 draufpacken und ihn ohne Mühen auf 3.1Ghz über FSB übertakten. Das bringt dir für kleines Geld das meiste.
Aber mal angenommen mein oder ein Programm kommt mit beiden CPU klar. Was wäre von der Performance denn besser.......2x3,17Ghz oder 4x2,5Ghz?Selbst wenn du von beiden Ergebnissen real jeweils 10% abziehen kannst, kannst du trotzdem mit 6.34Ghz vs. 10Ghz rechnen. Noch Fragen? ;)
robbitop@work
2008-04-21, 13:20:44
Ich hab einen VideoCodec selber geschrieben und die Parallelisierbarkeit ist von sehr vielen Rahmenbedingungen abhängig. Was ich bis jetzt gesehen habe bezieht sich auch immer auf die Bewegungsvorhersage die um die 30% an der gesammten Laufzeit teilhat. Nur das wird faktoriell beschleunigt.
Was ist mit dem Bereich Irrelevanzreduktion:
Läßt sich die diskrete Kosinustransformation und die nachfolgende Quantisierung nicht parallelisieren? Das findet doch sowieso in 8x8 Blöcken statt, die recht unabhängig voneinander sein müßten.
Laut einem PDF vom Fraunhofer Institut macht die Bewegungsvorhersage einen Großteil der Berechnung bei Videokomprimierung aus.
Was ist mit dem Bereich Irrelevanzreduktion:
Läßt sich die diskrete Kosinustransformation und die nachfolgende Quantisierung nicht parallelisieren? Das findet doch sowieso in 8x8 Blöcken statt, die recht unabhängig voneinander sein müßten.
stimmt, daran habe ich garnicht gedacht, mein Codec hat Wavelets benutzt
allerdings auch wieder nur unter bestimmten Vorraussetzungen, die DC-Komponente wird z.B. aus den umgebenen Blöcken vorhergesagt.
Die Abhängigkeiten sind geringer, aber der Anteil an der Laufzeit auch
wie groß die Blockgröße ist hängt weiterhin vom Codec ab (H.264 verwendet z.B. 4x4)
Laut einem PDF vom Fraunhofer Institut macht die Bewegungsvorhersage einen Großteil der Berechnung bei Videokomprimierung aus.
unter der reinen Bewegungsvorhersage verstehe ich das Blockmatching
da existieren ziemlich effiziente Algorithmen
ich denke i.A. nimmt man das R&D beim Laufzeitverhalten mit dazu, da wären auch 60% drin.
Das Problem ist, das man die reine Suche innerhalb eines Bilders gut parallelisieren kann.
Die Entscheidung welche Zusammensetzung der Macroblock hat, aber nicht, da diese von umgebenen Macroblöcken und vorangegangen Bildern abhängig ist. Selbst wenn man versucht die Threads auf mehrere Bilder zu erweitern wird's problematisch, da diese ja in den meisten Fällen von vergangenen und zukünftigen Bildern abhängen.
Dazu benötigt man diese aber in dekodierter Form.
robbitop@work
2008-04-22, 11:39:48
RapiHD zeigt ja bereits, dass die Parallelisierung recht hoch sein muss. (Das Ding nutzt mittels CUDA ja ein enormes Reservoir an parallel vorhandener Rechenleistung im G8x/9x)
Zusätzlich kann man ja noch schön Videoprocessing (Detailrekonstruktionsalgoritmen, Skalieralgoritmen, Deblocking, Denoise, evtl noch sehr gutes DNM ect) machen, um SD-Videomaterial aufzuwerten. Spätestens dann sollte es hervorragen zu parallelisieren sein.
Sagmal dein wavletbasierender Codec: was brachte der für Ergebnisse? :)
Laut Fraunhofer Institut ist der leider nicht so toll parallelisierbar, aber es gab mal eine Forschungsarbeit im Jahr 2000, die sich mit spezieller Hardware für Wavlet-Videokomprimierung befasst hat.
Bandit666
2008-04-22, 16:47:14
ick versteh nur Bahnhof, wa?
mfg
N0Thing
2008-04-23, 01:24:50
Zum Vergleich DualCore / Quadcore kann ich leider noch nichts sagen, aber so schlecht kann die Unterstützung für mehrere Kerne nicht sein, wenn ich beim Umstieg vom A64 3000+ auf den x2 4200+ sehr genau nur noch die halbe Zeit brauche, um ein Video mit TMPGenc oder HCenc zu bearbeiten.
Bei Techreport wird auch mit Videotools gebencht, allerdings nicht mit dem MC-Enceroder
http://techreport.com/articles.x/14573/9
Ectoplasma
2008-04-23, 08:24:52
... Video-Encoding bietet sich grundsätzlich recht gut zur Parallelisierung an und es laufen in der Praxis auch oft mehrere Filter (Skalieren, Schärfen, Entrauschen, Deblocking, Deinterlacing, etc.) im Hintergrund mit, die einen eigenen Kern dankend annehmen.
Nein. Die Filter laufen mit Sicherheit nicht im Hintergrund. Wenn sie an einen Kern gebunden wären, dann wäre das auch nur single-threaded. Vielmehr ist es so, dass sich jeder der oben genannten Filter auf mehrere Threads aufteilen lässt.
Bei Premiere hab ich praktisch eine 100% Auslastung meiner beiden Cores.
Ich träume von 80% Quad auslastung...
MasterElwood
Bei heutiger und Audio und Videobearbeitung sind die Befehlssätze und ein schneller und/oder grosser Cache wichtiger als die Taktrate.
Du gewinnst bei einem QuadCore also schon alleine durch die zwei zusätzlichen SSE-Einheiten an Geschwindigkeit.
Meine Empfehlung: QuadCore.
Der HeinZ
2008-04-28, 22:49:08
Du gewinnst bei einem QuadCore also schon alleine durch die zwei zusätzlichen SSE-Einheiten an Geschwindigkeit.
Oo oo oo....:| bitte nicht den Thread Starter verwirren.
Das stimmt so nicht, als einfaches Beispiel, ein Auto mit 8 Achsen und zwei motoren läüft auch nur dann auf voller Leistung wenn beide Motoren die 8 Achsen auch entsprechend befeuern, dafür braucht der zweite Motor auch Sprit, den er aufgrund des alten verteilers aber nicht bekommt... bevor ich jetzt hier unnütz ausschweife... Nur weil du 2 Einheiten für SIMD mehr hast bedeutet das überhaupt nicht das die auch genutzt werden. Zwar bin ich kein pro in diesem Bereich. Aber wie meine vorredner bereits treffend erwähnt haben geht es um Parallesierung, also mehrere Threads gleichzeitig erledigen anstatt nacheinander. So und das kann im groben der QUADCore besser. Dementsprechend muss die Software ausreichend multithreaded sein damit der Quad seine Stärke ausspielen kann.
Auch der Cache wird nicht automatisch effektiv verdoppelt, da sich 2 Kerne immer (bei Intel) immer einen Cache (2nd Level)teilen, von dem die anderen beiden nix haben. (anders als der gemeinsame 3rd Level Cache beim Phenom zum Beispiel den alle Kerne nutzen können/dürfen/wollen)
Schlichtweg kommt es auf den Encoder und die darüber liegende Software an ob und wie gut der mit mehreren Threads umgeht, und das ist von Encoder zu Encoder anders.
Beispielsweise hat das Programm DVDX 2.6 Filter die singelthreaded sind, während die Encoder die du mit dem Programm nutzen kannst auch multithreaded sein können(beispiel xH264). Dadurch kann man auch bei diesem älteren Programm immer noch einen ordentlichen Geschwindigkeitzuwachs bei Multiprozessor Systemen erzielen.
Es gibt aber gerade in der Videobearbeitung bereits gute unterstützung von Mehrkernprozessoren.
Ich denke auch das ein Quad auf dauer besser sein wird, vorallem wenn der Quad genauso teuer ist wie der Dual und du den so schön takten kannst wie den Intel. Und Takt ist immer wichtig, egal welche Prozziarchitektur du benutzt und welches Programm zur Videobearbeitung zum Einsatz kommt.
Mein Rechner könnte 8 Kerne haben und 20000 Mhz und ich würde immer noch meckern warum das DVD rippen 5 Sekunden und nicht eine dauert.
Ich sehe bei großen Dateien immer erstmal das problem bei dem langsamsten Teil in deinem Rechner, bei der Festplatte und dem optischen Laufwerk...
Oo oo oo....:| bitte nicht den Thread Starter verwirren.
Das stimmt so nicht, als einfaches Beispiel, ein Auto mit 8 Achsen und zwei motoren läüft auch nur dann auf voller Leistung wenn beide Motoren die 8 Achsen auch entsprechend befeuern, dafür braucht der zweite Motor auch Sprit, den er aufgrund des alten verteilers aber nicht bekommt... bevor ich jetzt hier unnütz ausschweife... Nur weil du 2 Einheiten für SIMD mehr hast bedeutet das überhaupt nicht das die auch genutzt werden. Zwar bin ich kein pro in diesem Bereich. Aber wie meine vorredner bereits treffend erwähnt haben geht es um Parallesierung, also mehrere Threads gleichzeitig erledigen anstatt nacheinander. So und das kann im groben der QUADCore besser. Dementsprechend muss die Software ausreichend multithreaded sein damit der Quad seine Stärke ausspielen kann.
Auch der Cache wird nicht automatisch effektiv verdoppelt, da sich 2 Kerne immer (bei Intel) immer einen Cache (2nd Level)teilen, von dem die anderen beiden nix haben. (anders als der gemeinsame 3rd Level Cache beim Phenom zum Beispiel den alle Kerne nutzen können/dürfen/wollen)
Schlichtweg kommt es auf den Encoder und die darüber liegende Software an ob und wie gut der mit mehreren Threads umgeht, und das ist von Encoder zu Encoder anders.
Beispielsweise hat das Programm DVDX 2.6 Filter die singelthreaded sind, während die Encoder die du mit dem Programm nutzen kannst auch multithreaded sein können(beispiel xH264). Dadurch kann man auch bei diesem älteren Programm immer noch einen ordentlichen Geschwindigkeitzuwachs bei Multiprozessor Systemen erzielen.
Es gibt aber gerade in der Videobearbeitung bereits gute unterstützung von Mehrkernprozessoren.
Ich denke auch das ein Quad auf dauer besser sein wird, vorallem wenn der Quad genauso teuer ist wie der Dual und du den so schön takten kannst wie den Intel. Und Takt ist immer wichtig, egal welche Prozziarchitektur du benutzt und welches Programm zur Videobearbeitung zum Einsatz kommt.
Mein Rechner könnte 8 Kerne haben und 20000 Mhz und ich würde immer noch meckern warum das DVD rippen 5 Sekunden und nicht eine dauert.
Ich sehe bei großen Dateien immer erstmal das problem bei dem langsamsten Teil in deinem Rechner, bei der Festplatte und dem optischen Laufwerk...
Irgendwie reden wir aneinander vorbei.
Natürlich muss die jeweilige AV-Applikation multithreaded sein. Aber welche semi-pro./pro. Applikation ist das denn bitte noch nicht?
Nochmal:
Sobald mehrere Prozessoren/Kerne genutzt werden, werden logischerweise auch die Befehlssätze dieser genutzt (sofern von der Applikation unterstützt).
Und da Integer- und Gleitkommaberechnungen nunmal am effektivsten über die Befehlssätze gelöst werden, sind diese für AV-Applikationen entscheidend.
Während meine Diplomarbeit habe ich unter Cubase SX 2.0 die Wirkung von SSE gemessen. Dafür stand mir ein Athlon Thunderbird 1400MHz und ein Athlon XP 2400+ 2000MHz zur Verfügung.
In einem Testprojekt mit VSTi's und VST-Plugins habe ich dann die Auslastungsanzeige geprüft.
Resultat:
Athlon XP 2400+ 2000MHz mit SSE: 45% IDLE (Stopp), 60% Last (Play)
Athlon XP 2400+ 2000MHz ohne SSE: 69% IDLE (Stopp), 80% Last (Play)
Athlon Thunderbird 1400MHz: 70% IDLE (Stopp), 80% Last (Play)
Das sind muntere 600MHz Taktunterschied.
Hier ist es natürlich so gravierend, weil beim Athlon Thunderbird überhaupt kein Befehlssatz ausser E3DNow! zur Verfügung stand.
Bei den "neueren" Prozessoren ist ja min. SSE3 schon garantiert. Bei den heutigen Prozessoren ist ja schon SSSE3 garantiert.
Natürlich kann man das nicht 1:1 für Videoapplikationen übernehmen. Jedoch behaupte ich, dass ein 2.5GHz QuadCore SSE4 schneller ist als ein 3GHz QuadCore SSE3.
Aber: Auch hier ist der Befehlssatz der Turbo, wenn es ums rechnen geht. Das die Festplatte bei AV ein Flaschenhals sein kann, ist mittlerweile klar.
Meine Devise: Prof. AV-Applikationen -> neuester Befehlssatz, viele Kerne/Prozessoren, RAM!. Optional ein integrierter Speichercontroller (momentan nur von AMD) und RAID.
Das würde heute für den Sockel-775/AM2+ heissen: SSE4.1/SSE4a und QuadCore.
Der HeinZ
2008-05-01, 14:06:40
Nochmal:
Sobald mehrere Prozessoren/Kerne genutzt werden, werden logischerweise auch die Befehlssätze dieser genutzt (sofern von der Applikation unterstützt).
Und da Integer- und Gleitkommaberechnungen nunmal am effektivsten über die Befehlssätze gelöst werden, sind diese für AV-Applikationen entscheidend.
AHA... das hast du aber oben nicht geschrieben... wir beide wissen das.... aber der Threadstarter glaub ich nicht... nix für ungut. ;D
Klar wenn der entsprechende Befehlssatz drin ist und unterstützt wird kann man theoretisch noch einige Prozent gewinnen. Ganz extrem ging es eben dem Pentium 4 der ja quasi von diesen Instruktionen lebt und ohne die völlig überfordert ist.
Ich ergänze nochmal deine Empfehlung: 64 Bit Betriebsystem (auch wenn ich VISTA hasse) dann kann mehr Speicher verbauen und auch da sind video anwendungen immer sehr dankbar.
Ich ergänze nochmal deine Empfehlung: 64 Bit Betriebsystem (auch wenn ich VISTA hasse) dann kann mehr Speicher verbauen und auch da sind video anwendungen immer sehr dankbar.Was nutzt einer 32bit Anwendung ein 64bit OS mit 4GB?
Bandit666
2008-05-01, 16:15:05
@all
Ja man merkt ihr seit Spezies. Danke für eure Aufklärung. Dann wird es wohl ein Q9450!
Was nutzt einer 32bit Anwendung ein 64bit OS mit 4GB?
Hi!
Wie meinst du das? Das bevorzugte Video-Programm bei mir ist 64bit fähig.
mfg
(del)
2008-05-01, 16:23:12
Ja man merkt ihr seit Spezies. Danke für eure Aufklärung. Dann wird es wohl ein Q9450!Keine super preiswerte Geschichte, aber ohne Frage die leistungsfähigste :up:
Ich hätte das Geld trotzdem davor lieber in eine bessere Cam gesteckt und mich mit einem Q6600-G0 abgegeben ;)
Wie meinst du das? Das bevorzugte Video-Programm bei mir ist 64bit fähig.Na dann wirds rennen :)
Ich ergänze nochmal deine Empfehlung: 64 Bit Betriebsystem (auch wenn ich VISTA hasse) dann kann mehr Speicher verbauen und auch da sind video anwendungen immer sehr dankbar.
Wenn es einem nur um die 64 Becks geht, muss es kein Vista (x64) sein. Es gibt auch XP x64 ... und ganz Hartgesottene mit zu viel Zeit sollen zu Linux greifen. ;)
MfG,
Raff
Der Premiere MediaEncoder nutzt bei meinem Quad bis zu 80% aus - laut Taskmanager.
Das sagt überhaupt nichts aus. Du musst die Zeit messen, dann kannst du die Skalierung ausrechnen.
Klar wenn der entsprechende Befehlssatz drin ist und unterstützt wird kann man theoretisch noch einige Prozent gewinnen.
Naja, es kann auch locker in den zweistelligen Prozentbereich gehen, je nach Vergleich. ;)
Ich ergänze nochmal deine Empfehlung: 64 Bit Betriebsystem (auch wenn ich VISTA hasse) dann kann mehr Speicher verbauen und auch da sind video anwendungen immer sehr dankbar.
Dann ergänze ich das auch nochmal:
Wenn ein 64Bit-Betriebssystem eingesetzt wird, dann können auch nur 64Bit-Applikationen auf mehr als 4GB zugreifen.
Programme die über WoW64 in Vista64 laufen sind weiterhin 32Bit Applikationen und können somit max. 4GB RAM nutzen.
Grundsätzlich kann man sagen: Wer nicht mehr als 2GB pro Prozess braucht fährt mit 32Bit Betriebssystemen besser.
Denn die meisten Komponenten von heutigen angeblichen 64Bit-Videobearbeitungsprogrammen sind immernoch 32bittig.
Wenn es einem nur um die 64 Becks geht, muss es kein Vista (x64) sein. Es gibt auch XP x64 ... und ganz Hartgesottene mit zu viel Zeit sollen zu Linux greifen. ;)
MfG,
Raff
Magix VDL 2008 gibt es nicht für Linux. XP64 ist für die meisten AV-Entwickler seit Vista64 keine relevante Umgebung mehr.
Nochmal zur Klärung für uns alle, da wir wohl alle ein wenig vom Threadthema abgewichen und nicht intensiver auf die eingesetzte Software von Bandit666 eingegangen sind:
Bandit666 will mit Magix VDL 2008 arbeiten; einer 32Bit Applikation. Das ist keine Applikation aus dem Pro-Bereich und dementsprechend auch an eine andere Klientel gerichtet. Weiterhin werden hier wohl nicht mehr als 4GB benötigt und er kann schon froh sein, wenn SSE4.1 mal nachgeliefert wird.
Wenn man sich die Meinungen zu Magix VDL so anschaut, dann scheint dieses Programm wohl selbst in der billigsten Version der Multithreadingunterstützung im Videobereich (Rendering) schon nicht grandios zu sein.
Fazit:
Es hat sich nichts geändert. Wer mehr will muss zu Avid, Adobe, Sony oder Apple greifen. Wer wirklich mehr als 4GB bei jedem Arbeitsschritt braucht, der muss noch warten.
Sony Vegas und Canopus Edius in 64Bit sollten schon da sein, Apple setzt wohl erst ab Final Cut Studio 3 auf eine native 64Bit Architektur und Avid bringt es wohl erstmal nur für MC mit Adrenaline.
Klar ist aber: Der Speicherbedarf ist bei grösseren Projekten in HD massiv gestiegen und behindert teilweise jetzt schon den Workflow.
64Bit ist keine Option, sondern ein Muss.
(del)
2008-05-01, 23:19:56
Magix VDL 2008 gibt es nicht für Linux. XP64 ist für die meisten AV-Entwickler seit Vista64 keine relevante Umgebung mehr.Ja sicher. Sie haben ggbf. ihre alte Basis und Klientel mit einem kurzen Räusper weggeworfen und die Klientel hat ihre Systeme mit fliegenden Fahnen von XP64 auf Vista64 umgesattelt. Ja ist klar :uup:
Mit Vista64 ist es für XP64 sogar einfacher geworden. Da sind für die Manager einige Entschedungswege zu gehen, aber "keine Frage mehr" ist Quark mit schlechter Sose, falls es bereits ein XP64 Produkt gab.
edit:
Sonst kann man deinen Beitrag aber nur fett unterschreiben. Stimmt schon.
Ja sicher. Sie haben ggbf. ihre alte Basis und Klientel mit einem kurzen Räusper weggeworfen und die Klientel hat ihre Systeme mit fliegenden Fahnen von XP64 auf Vista64 umgesattelt. Ja ist klar :uup:
Mit Vista64 ist es für XP64 sogar einfacher geworden. Da sind für die Manager einige Entschedungswege zu gehen, aber "keine Frage mehr" ist Quark mit schlechter Sose, falls es bereits ein XP64 Produkt gab.
edit:
Sonst kann man deinen Beitrag aber nur fett unterschreiben. Stimmt schon.
Ähm...kann es sein, dass du die kleine aber feine Einschränkung AV-Entwickler überlesen hast? ;)
Wieviele native 64Bit Pro. Audio-/Video Tools gibt es denn für XP64?
Praktisch Keine. Warum sollte man nach dem Erscheinen von Vista64 jetzt noch für XP64 entwickeln, wenn so ziemlich jeder Hersteller der überhaupt 64bittige Treiber rausbringt dies mittlerweile fast ausschliesslich für Vista64 tut?
XP64 ist nie wirklich beim AV-Kunden angekommen. Vista64 spielt jetzt nur das Bestattungsinstitut.
=Floi=
2008-05-03, 16:28:11
wenn du noch übertakten willst, würde ich noch zu einem besseren kühler raten. Denn dan kannst du noch gut übertakten und das system bleibt sehr leise (http://geizhals.at/deutschland/a255442.html mit einem guten 120er lüfter)
Sagmal dein wavletbasierender Codec: was brachte der für Ergebnisse? :)
Nach 3 Monaten Coden war ich bei LowMotion+verlustfrei besser als x264,
noch dazu mit einer extrem simplen Bewegungsvorhersage, außer das sie überlappendende Bewegungskompensation benutzt hat um Randartefakte zu vermeiden
dann hatte ich keine Lust mehr ;)
Das Prob bei VideoCodecs ist die Geschwindigkeit.
Ich habe eine Variante da die JPEG2000 für I-Frames locker hintersich läßt, aber da gabs dann 1-2fps auf nem Athlon-1400 :(
hätte ich die Geschwindigkeit so erhöht das es so schnell ist wie z.B. XViD, hätte ich diese Qualität nie halten können, aber Ideen habe ich noch genug ;)
robbitop@work
2008-05-06, 11:47:42
Das Prob bei VideoCodecs ist die Geschwindigkeit.
Ich habe eine Variante da die JPEG2000 für I-Frames locker hintersich läßt, aber da gabs dann 1-2fps auf nem Athlon-1400 :(
hätte ich die Geschwindigkeit so erhöht das es so schnell ist wie z.B. XViD, hätte ich diese Qualität nie halten können, aber Ideen habe ich noch genug ;)
Wie erwähnt, wollte das Fraunhofer ja daran forschen (vor 8 Jahren IIRC) ob man spezielle Hardware für Wavelettvideokompression bauen könnte, um das Geschwindigkeitsproblem zu reduzieren.
Mit CUDA und RapiHD zeigt sich ja soetwas schon bei der DCT-basierenden Videokompression. Ich weiß nicht, welche Restriktionen dieses Konzept hat, aber das Encoding scheint dadurch ernom schneller zu werden. Zumindest so zeigten es die ersten Ergebnisse. Ohne Details ist das aber schwer zu kommentieren.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.