# Rendern von Videos dauert ewig..



## Sebastian1989101 (22. Juli 2013)

Kurz erstmal die Systeminformationen, bevor jemand auf der Idee kommt die Hardware wäre zu langsam:

*CPU*: i7-3970X
*GPU*: GTX Titan AMP
*RAM*: 32GB DDR3-2133 Quad-Channel
*HDD*: Corsair Force GS 360GB (Programm), 2TB WD Black (Video Sourcen), 600GB WD Velociraptor (Video Exportziel)
Dazu kommt ein X79 Chipsatz Motherboard.
*Software*: Win8 64Bit, Adobe CS6 (Premiere Pro, Media Encoder)

Ich habe bereits verschiedenes Versucht um die Rendergeschwindigkeit zu beeinflussen. Ich habe es sowohl über den MPE GPU als auch MPE Software als Renderer Versucht aber ohne bessere Ergebnisse.. Die Renderzeit beträgt aktuell für ein mit Fraps aufgenommenes Video + Audio Spur ohne zusätzliche Effekte, 3 Stunden und 40 Minuten bei einen 1 Stunden Video als H.264 / YouTube 1080p25 export. Die Ergebnisse vom Media Encoder decken sich mit jene von Premiere.

Da die Auslastung der CPU gerade einmal knapp 30% sind, die GPU offensichtlich Ignoriert wird (diese habe ich nachträglich in der supported-cuda Textdatei eingefügt da nur die GTX780 drin war, welche den gleichen GPU Chip nutzt) und auch die RAM Auslastung noch lange nicht beim Maximum ist, gehe ich von irgendwelchen Fehlern in der Konfiguration aus. Da ich mich aber überhaupt nicht damit auskenne, würde mich Interessieren ob mir da jemand weiter helfen kann, oder sind diese Wahnsinnigen Werte normal? Wobei ich mich dann Fragen würde, warum geht die Software nicht ans Limit der vorhandenen Leistung...

Max Render Quality habe ich derzeit deaktiviert, das einzige was sich ändert ist dass die CPU Last durchgehend bei 50-55% ist anstatt bei 30% wenn dies aktiv ist. Die Zeit bleibt die gleiche und die GPU bleibt ebenfalls <5% Auslastung, was jedoch nur Windows etc. sein werden und nicht ein Adobe Export...


----------



## Martin Schaefer (22. Juli 2013)

Wird das Video beim Export in irgendeiner Form skaliert?


----------



## Sebastian1989101 (22. Juli 2013)

Es wird von 2560x1440 auf 1920x1080 skaliert. Aber das dürfte ja nun wirklich nicht so eine Differenz erklären und schon gar nicht, warum der Media Encoder nicht alle vorhandenen Ressourcen nutzt.


----------



## Martin Schaefer (22. Juli 2013)

Das kann durchaus eine Rolle spielen, doch.
Wenn z.B. dein Quellmaterial auch H.264 kodiert ist, dann muss Premiere oder Media Encoder das Video lesen, dekodieren, skalieren (Lanczos2 bikubisch bei CUDA Einsatz), kodieren, schreiben. Das kann den Prozess deutlich verlangsamen. Lanczos2 ist ein hervorragender Skalierungs-Algoritmus, der aber auch sehr langsam ist. Ein Grund, warum es ihn in Photoshop nicht gibt.

Aber das muss natürlich nicht die Hauptursache sein. Vermutlich ist sie das auch nicht, da sonst die GPU ordentlich am arbeiten wäre. Die Tatsache, dass weder GPU, noch CPUs wirklich motiviert arbeiten lässt für mich darauf schließen, dass CUDA überhaupt nicht bzw. nur sehr eingeschränkt genutzt wird.

Und da sind wir evtl. schon beim eigentlichen Knackpunkt. Die GTX Titan wird von Premiere Pro CS6 nicht unterstützt. Der Hack ist zwar nett, ändert aber offensichtlich nichts an der Tatsache.


----------



## Sebastian1989101 (22. Juli 2013)

Der "Hack" wie du ihn nennst, macht die GPU nur CS6 bekannt. Es ist genau der gleiche GPU-Chip wie in der GTX780. Außerdem gibt es halt keinerlei Anzeichen auf einen Versuch der CUDA Nutzung. Außerdem müsste dennoch CPU und RAM genutzt werden - umso mehr wenn meine GPU nicht Unterstützt wäre (ich hatte es ja auch ohne GPU versucht mit gleichen Ergebnis). 

Das Quellmaterial ist Unkomprimiertes AVI Material von Fraps + Mono Audiospur von Audacity (WAV). Ziel ist das genannte H.264 in Full-HD.


----------



## Matthias (23. Juli 2013)

...ich warte immer noch auf den Tag, wann Adobe mal Software herstellt, die technisch (nicht gestalterisch/künstlerisch) halbwegs auf einem akzeptablen Stand ist...

Es gibt andere, gute Softwarebuden wenn es darum geht, die heute üblichen, technischen Möglichkeiten zu nutzen.

Was du beschreibst ist für Adobe gängig.


----------



## Martin Schaefer (23. Juli 2013)

Sebastian1989101 hat gesagt.:


> Das Quellmaterial ist Unkomprimiertes AVI Material von Fraps + Mono Audiospur von Audacity (WAV). Ziel ist das genannte H.264 in Full-HD.



Na herzlichen Glückwunsch! Da hast du also deine Festplatte mit rund 1TB für eine Stunde Video vollgekritzelt und wunderst dich jetzt ernsthaft, warum das alles so lange dauert? Das sind ja schonmal rund 2 Stunden, die nur für das Lesen des gesamten Videos draufgehen ... und da ist noch nix skaliert und wieder kodiert und geschrieben.

@Matthias:
Kleines Quiz für dich: Wer hat als erster CUDA-Unterstützung gehabt während alle anderen noch die CPU gequält haben? Avid? Final Cut? Magix Video? Premiere Pro?


----------



## Matthias (23. Juli 2013)

hast ja recht...

Gegenfrage:
Wer verzichtet bis heute auf die vollumfängliche Nutzung von Mehrprozessorsystemen obwohl es kaum noch Singleprozessorsysteme gibt?


----------



## Sebastian1989101 (23. Juli 2013)

Martin Schaefer hat gesagt.:


> Na herzlichen Glückwunsch! Da hast du also deine Festplatte mit rund 1TB für eine Stunde Video vollgekritzelt und wunderst dich jetzt ernsthaft, warum das alles so lange dauert? Das sind ja schonmal rund 2 Stunden, die nur für das Lesen des gesamten Videos draufgehen ... und da ist noch nix skaliert und wieder kodiert und geschrieben.



Und du glaubst ich hätte etwas gesagt wenn die Platten Auslastung da wäre? Die Festplatte gammelt ebenso wie die CPU, der RAM und die GPU bei wenigen Prozenten rum.. Davon ab ist eine 1h Aufnahme mit Fraps auch "nur" 150GB groß und die WD Black ist eine sehr schnelle Platte, sicher keine die dafür lange brauchen würde... Wenn ich auf die Platte Benchmarks, Copy & Paste Aktionen Ausführe erreiche ich eine knapp 100x so hohe Datenrate wie wenn der Media Encoder das einlesen beginnt.


----------



## Martin Schaefer (23. Juli 2013)

Wenn die Aufnahme 1 Stunde lang ist und 2560x1440 Pixel Auflösung und 25fps hat, dann ist es bei 150GB kein unkomprimiertes Video. Das ist ganz simple Mathematik. Wir können ewig im Trüben stochern, wenn wir nicht ganz genau wissen, was Sache ist.

Fakt ist: Premiere Pro CS6 nutzt überall da Mehrprozessor-Verarbeitung und/oder CUDA/GPU, wo dies möglich ist und Sinn macht. Wenn es das in deinem Fall nicht tut, dann hat das bestimmt Gründe, die wir eben nur dann finden können, wenn wir genau wissen wie du was womit machst. Und das bezieht sich auch auf das Format deines Rohmaterials.
Ich kenne Fraps nicht bzw. nutze es nicht. Was wäre z.B., wenn Fraps z.B. nur 6fps aufzeichnet und dies auch noch in irgendeinem möglicherweise exotischen Codec? Möglicherweise interpoliert Premiere Pro dann Zwischenbilder, um auf die gewünschten 25fps zu kommen? Ich kann das ohne entsprechende Infos nicht wissen, sorry.
Oder vielleicht ist der von Fraps verwendete Codec nicht Mehrprozessor-tauglich. Auch das weiß ich nicht, solange ich nicht weiß, welchen Codec Fraps verwendet.


----------



## Matthias (23. Juli 2013)

Martin Schaefer hat gesagt.:


> Ich kenne Fraps nicht bzw. nutze es nicht. Was wäre z.B., wenn Fraps z.B. nur 6fps aufzeichnet und dies auch noch in irgendeinem möglicherweise exotischen Codec? Möglicherweise interpoliert Premiere Pro dann Zwischenbilder, um auf die gewünschten 25fps zu kommen? Ich kann das ohne entsprechende Infos nicht wissen, sorry.



@Martin Schaefer
...dein Schuss (ins blaue?  ) hat gute Chancen zu treffen - ich wurde neugierig und siehe da:

http://www.fraps.com/faq.php

...es scheint, als könne man sich da tatsächlich etwas vertun.


----------



## Sebastian1989101 (23. Juli 2013)

Ok, demnach scheint Fraps wirklich ja einen Codec zu nutzen... Und ich habe gerade mal Nachgerechnet bei einer Stunde müssten es ja wirklich 926,97GB sein... 

Wie dem auch sei.. Erklärt das weiterhin nicht, warum Adobe der Ansicht ist nur einen Bruchteil der vorhandenen Ressourcen zu nutzen. Den gerade wenn es auch noch um das decodieren geht sollte Adobe doch die CPU / GPU und den RAM nutzen... 

Bedingt durch Hinweise eines Freundes werde ich heute Abend auch mal Sony Vegas und einige Freeware Programme testen. Nur weil Adobe teuer ist, ist es ja noch lange nicht gut. 

Aber so im Übrigen: Das Encoding ist nur ein Format und Formate sind nicht abhängig von der Anzahl der Prozessorkerne. Lediglich der Treiber der dieses Format auf dem System Installiert kann oder eben auch nicht Multithreading Unterstützen. Darum würde ich den Codec als Ursache ausschließen.. Aber das werde ich ja heute Abend bemerken, wenn sich andere Programme gleich verhalten.


----------



## Martin Schaefer (23. Juli 2013)

Ich bin mir einfach nur der Tatsache bewusst, dass Videobearbeitung eine grauenvolle "can of worms" sein kann ... und da gibt es bestimmte Ecken und Kanten an denen es gerne mal klemmt.

Einerseits schwierig, ohne ALLE Informationen irgendwas mit Sicherheit zu sagen, andererseits würde sich so manche Frage erst gar nicht stellen, wenn der Anwender selbst diese Informationen schon alle hätte. Also stochert man eben solange rum, bis irgendwas deutlich vernehmbar quiekt.


----------



## Martin Schaefer (23. Juli 2013)

Sebastian1989101 hat gesagt.:


> Wie dem auch sei.. Erklärt das weiterhin nicht, warum Adobe der Ansicht ist nur einen Bruchteil der vorhandenen Ressourcen zu nutzen. Den gerade wenn es auch noch um das decodieren geht sollte Adobe doch die CPU / GPU und den RAM nutzen...


Nicht zwingend, da Adobe selbst (abgesehen von CinemaDNG) keine Codecs programmiert, sondern nur Codecs im Rahmen derer vorgegebenen Möglichkeiten nutzt.

Es gibt auch andere Ecken wo Premiere Pro keine Mehrprozessor-Technik oder CUDA/GPU einsetzen *kann*. Zum Beispiel dann, wenn Bilder so interpoliert werden müssen, dass Bild B davon abhängt wie Bild A aussieht usw. Dann ist eine parallele Verarbeitung mehrerer Bilder schlicht und einfach nicht möglich.



> Bedingt durch Hinweise eines Freundes werde ich heute Abend auch mal Sony Vegas und einige Freeware Programme testen. Nur weil Adobe teuer ist, ist es ja noch lange nicht gut.


Und im Umkehrschluss ist Premiere Pro noch lange nicht schlecht, nur weil du noch Schwierigkeiten im Umgang mit Codecs und/oder dem Verständnis von Parallelisierung von Aufgaben hast. 



> Aber so im Übrigen: Das Encoding ist nur ein Format und Formate sind nicht abhängig von der Anzahl der Prozessorkerne. Lediglich der Treiber der dieses Format auf dem System Installiert kann oder eben auch nicht Multithreading Unterstützen. Darum würde ich den Codec als Ursache ausschließen.. Aber das werde ich ja heute Abend bemerken, wenn sich andere Programme gleich verhalten.


Siehste, auch da wieder eine Wissenslücke.  Adobe hat wie oben schon gesagt keinen Einfluss auf die technischen Details von Codecs ... wenn wir mal von CinemaDNG absehen.


----------



## Sebastian1989101 (23. Juli 2013)

Ich habe nicht gesagt, dass Premiere schlecht sei.  Nur Kosten != Leistung. Und nein die Wissenlücke ist offensichtlich bei dir. Ich habe oben bereits erklärt das ein Format (Codec) von nichts abhängig ist sondern dies Sache des jeweiligen Interpreters (Treibers) ist. Klar hast du recht wenn der Fraps-Codec-Interpreter dies so aufbaut dass dann schlichtweg kein MT möglich ist. *Aber*: Selbst bei Sigle-Threading müsste ja wenigstens 1-Kern auf 100% laufen. 100% / 12 Threads = 8,33% pro Thread, bzw. 16,66% pro Kern. Allerdings laufen alle Kerne in etwa bei gleicher Auslastung sehr niedrig während des decoding / encoding. Gut diese Info hätte oben mir ran gehört konntest du ja nicht wissen dass die Auslastung eine verteilte ist. Aber sämtliche Erkenntnisse Entziehen sich der Sinnlichkeit. Gerade wenn es für Premiere komplex und schwierig wird müssten Ressourcen genutzt werden und solange dies nicht der Fall ist, muss eine Fehlkonfiguration von mir vorliegen. Oder eben was ich derzeit mit in Betracht ziehe (das heißt nicht das es so ist), ist dass Premiere einfach nicht in der Lage ist die Hardware korrekt zu bedienen und dass es deswegen zu der Niedrigen Auslastung kommt. 

Ich werde heute Abend wie gesagt noch die anderen Systeme testen und auch Detaillierte Systeminformationen abliefern.. Ist ja kein großes Problem.


----------



## Sebastian1989101 (23. Juli 2013)

Soo ich habe das ganze nun mit Vegas getestet. Mit Vegas erreiche ich eine Renderzeit von ~1h was meiner Ansicht nach aber weiter inakzeptabel ist für diese Hardware den auch hier liegt CPU und GPU gerade einmal bei jeweils ~60%, RAM bei ~50% und Festplatten bei ~5-10%. 

Beim Media Encoder von Adobe konnte ich nun ebenfalls leicht höhere Werte aber immer noch unter denen von Sony Vegas und weit unter den vorhandenen Ressourcen nach dem Aktualisieren der Software feststellen (war ein Update für den Media Encoder verfügbar, welches ich noch nicht hatte). 

Nun kurz zum System, damit auch hier die detaillierten Informationen vorliegen. 

*CPU*: Intel Core i7 3970X
*GPU*: 6144MB ZOTAC GeForce GTX Titan AMP! Edition 
*RAM*: 32GB G.Skill RipJawsZ DDR3-2133 DIMM CL9 Octa Kit
*Mainboard*: Asus Rampage IV Extreme Intel X79 So.2011 Quad Channel DDR3 EATX
*SSD*: 360GB Corsair Force GS
*HDD1*: 2000GB WD Black WD2002FAEX 64MB 3.5"
*HDD2*: 600GB WD VelociRaptor WD6000HLHX 32MB 3.5" 

*Software*: Windows 8 64-Bit, Adobe CS6, Fraps 3.4.5, Audacity 

Alternativ kann ich noch einen DirectX Bericht zur Hardware anbieten. Der Vorgang für Videos ist -> Projekt erstellen, Zusammenfügen, Speichern, Import im Media Encoder, Rendern mit vorgegebenen YouTube 1080p25 Settings - mehrere Stunden pro Video warten trotz einer nicht vorhandenen Auslastung. 

Das gleiche Quellmaterial auf meinem MacBook Pro nutzt die Hardware vollkommen aus, nur leider ist hier sehr viel weniger Hardware drin als im Desktop PC hier. Von daher kann es auch nicht am Multi-Threading liegen mit den Codec (da auch dort ein 4-Core 8-Threads i7 eingebaut ist).


----------



## Martin Schaefer (23. Juli 2013)

Also ich kann dir nur sagen, dass es bei mir mit allen verfügbaren Mitteln und maximaler Kraft aus allen Rohren voran geht, wenn ich irgendwas rendere oder in H.264 umkodiere. Und meine Rechner sind kein Gramm schwächer, abgesehen davon dass ich keine GTX Titan habe, sondern einmal eine GTX 285 in der großen Workstation und einmal eine GT 650M im Workstation Notebook.

Allerdings habe ich schlicht und einfach kein Fraps Video, um es mal damit zu testen.


----------



## Sebastian1989101 (23. Juli 2013)

Ich kann dir gerne ein paar Minuten Fraps-Material zur Verfügung stellen. Sind dann halt nur X-Gigabyte (pro 4GB ca. 40 Sekunden). Müsste man dann nur hoch rechnen für die Zeit.. 

EDIT: Mir fällt gerade ein, ich kann auch erstmal mit der Elgarto Capture Card ein wenig Material aufnehmen und versuchen dies zu Rendern. Vielleicht liefert mir dies ja andere Ergebnisse was die Zeit betrifft.


----------



## Sebastian1989101 (23. Juli 2013)

Ok, gerade eine 45 Minuten Aufnahme mit der Elgato Game Capture HD Capture Card gemacht (Export als H.264 MP4-File in 1080p25). Hier werden die Ressourcen schon besser vom Media Encoder genutzt (haben zusätzlich eine mit Audacity aufgenommene Mono-Tonspur drunter gelegt). Nun habe ich eine CPU Last von 65-80% auf allen kernen, 30-80% auf den CUDA Kernen sowie 70% RAM last. Festplatten weiterhin bei ~10%. Die angegebene Renderzeit für diese Aktion beträgt 40min bei 45min Videomaterial (Aufnahme der Wii U während einer Mario Bros U Session + gedümpel im Wii U Menü). 

Aber auch hier wäre ja noch ein Nutzbarer Ressourcenpool vorhanden. Warum wird dieser also nicht genutzt? Es gibt keinerlei Restriktionen diesbezüglich und der Render Thread sowie der Media Encoder laufen mit Echtzeit Priorität. Die Zeit ist schon mal Akzeptabel, wenn auch nicht optimal. Mal abwarten was die Qualität sagt. 

Zusätzlich habe ich auch gerade in einem anderen Forum gelesen das Fraps beim Rendern geschlossen werden sollte. Gesagt getan ist auch hier die Ressourcen Nutzung nochmals 10-15% besser und die Renderzeit bei nur noch 2h für 1h Video (wobei hier ja auch noch die Skalierung dazu kommt). 

Gibt es Möglichkeiten dies noch zu Optimieren? Den Media Encoder irgendwie dazu zu zwingen immer alle Ressourcen zu nutzen? Bin auch mal gespannt wie es beim Rendern von 3DS Aufnahmen aussehen wird, da hier ja noch Skalierung (Zoom etc.) sowie Overlay Grafik hinzu kommen.


----------



## MetroAffe (24. Juli 2013)

Ich würde sagen du versuchst es einfach mal mit einem anderen Programm, wie zb. Sony Vegas Pro - ladest Dir einfach die 30-tägige Testversion und versuchst dein Glück. Wenns genauso lahm ist schauen wir mal


----------



## Martin Schaefer (24. Juli 2013)

Um nochmal weiterzustochern in der trüben Videosuppe ...

Ich vermute mal, dass das H.264 deiner Elgato Karte nicht nur Intra-Frames speichert, sondern im GoP (Group of Pictures) Modus mit P- und B-Frames arbeitet. Das macht das dekodieren des Videos deutlich komplexer und lässt die Encoder Prozesse länger warten.
Wie ich schon mehrfach sagte, Video kann manchmal wirklich eine nervenaufreibende Angelegenheit sein. Insbesondere auch dann, wenn man keinen guten Intermediate Codec für den Schnitt verwendet, sondern wie in deinem Fall z.B. H.264 mit GoP direkt als Rohmaterial verwendet.

Profis nutzen spezielle Codecs, die für die Videobearbeitung optimiert sind und nicht als End-Ausgabeformat verwendet werden. Alles was an Rohmaterial reinkommt wird dann (falls nötig) erstmal transkodiert und dann erst im Schnitt verwendet.
Dass das in deinem relativ simplen Fall nach übertriebenem Aufwand klingt ist verständlich. Aber Premiere Pro ist, um ganz offen zu sein, für komplexere Aufgaben gedacht.


----------



## Sebastian1989101 (24. Juli 2013)

@MetroAffe: Hab ich schon versucht kommt auf gleiche Ergebnisse raus wie Premiere nur das ich die Export Einstellungsmöglichkeiten von Sony Vegas schrecklich finde. 

@Martin Schaefer: Aber gerade wenn dinge komplex sind, sollten doch Ressourcen genutzt werden. Es geht ja nicht voran wenn Premiere dann einfach die vorhandenen Ressourcen frei lässt. Aber wie gesagt ist die Ressourcen Auslastung bei der Elgato schon deutlich besser (vor allem weil GPU und CPU zu ca. zu 3/4 genutzt werden). Schön wäre es nur Premiere davon überzeugen zu können sowohl bei Elgato Material als auch bei Fraps Material immer 100% der Ressourcen zu nutzen. Klar kann etwas länger dauern weil Aufwändiger, mehr zu tun oder was auch immer. Aber ich erwarte das vorhandene Rechenressourcen genutzt werden. Würde wenigstens eines davon am Limit laufen wäre dies der Flaschenhals und ich würde es so hinnehmen den wenn die Ressourcen von etwas leer sind und deswegen die anderen nicht voll genutzt werden können - ok. Aber so das immer noch freie Ressourcen zu genüge da sind, ist für mich ein No-Go egal welches Quell und Zielmaterial. Es geht nur voran wenn die gegebenen Ressourcen genutzt werden und würde dies geschehen könnte es auch schneller gehen.


----------



## Sebastian1989101 (24. Juli 2013)

Um das letzte noch einmal kurz zu erweitern: Sobald der Rendervorgang eine Ressourcen zu >95% nutzt wäre ich zufrieden. Aber solange dies nicht der Fall ist, kann und will ich es nicht hinnehmen das der Prozess zum Rendern so lange dauert. Den solange es freie Ressourcen gibt bzw. solange alle Ressourcenquellen freie Ressourcen haben ist es nicht akzeptabel das es lange dauert. Wäre auch nur eine Komponente komplett ausgelastet wäre das für mich alles ok aber so nicht. 

Folglich ist mein eigentliches Problem nicht die lange Renderzeit sondern dass die Ressourcen nicht voll genutzt werden und da spielt kein Codec dieser Welt eine Rolle den solange auf jeder Komponente so viele freie Ressourcen sind, ist es klar das es lange dauert. Sobald also GPU, CPU, RAM oder SSD / HDD die Ressourcen sehr gut nutzen bin ich zufrieden und akzeptiere die benötigte Renderzeit vorher nicht. Es macht halt für mich absolut kein Sinn das die Renderprogramme Ressourcen frei liegen lassen wenn sie doch eigentlich mehr benötigen um voran zu kommen.


----------



## Martin Schaefer (24. Juli 2013)

Eigentlich hab ich gar keine große Lust, in Computertechnik einzusteigen. Deshalb nur soviel:

Wenn du Prozesse parallelisierst UND noch verschiedene Vorgänge zeitgleich passieren (wie z.B. decoden, skalieren und encoden), dann sind eine Reihe von Vorgängen von einander abhängig. Ein Bild kann nicht encoded werden, solange es nicht decoded und skaliert ist.
Dadurch laufen eben bestimmte Prozesse zwischendurch mal im Leerlauf, weil sie noch auf das Ergebnis eines anderen Prozesses warten. Diese Leerlauf-Prozesse immer zu beenden (um Resourcen freizugeben) und dann wieder neu zu starten, wenn sie wieder benötigt werden, ist VIEL langsamer, als sie einfach laufen und kurz warten zu lassen.

Wenn du professionelle Intermediate Codecs für den Schnitt verwendest, dann ist das decoden weit weniger komplex und damit oft wesentlich schneller als das Berechnen von Effekten und das Encoden. Da entsteht dann kein solcher Flaschenhals.


----------



## Sebastian1989101 (24. Juli 2013)

Aber den gibt es anderen Prozesse welche die Leistung aktuell benötigen und ein Prozessor funktioniert nicht so das ein Kern oder Thread nur für einen Thread im OS dient. Jeder Schritt der getan werden muss wird in einer Warteschlange eingereiht und kommt dran sobald Ressourcen frei sind. Aktuell gibt es aber weniger Prozesse die sich einreihen möchten Offensichtlich da Ressourcen frei bleiben. Soviel zur PC-Technik. 

Klar wenn Threads Suspended werden, machen die erstmal nichts mehr. Aber anderen Threads wiederum können doch die freien Ressourcen nutzen und es müsste selbst bei Singleton-Threads dann immerhin ein Kern auf 100% laufen - was nicht der Fall ist. Die nun etwas höhere Auslastung ist ja immer noch quer verteilt. 

Und das hat auch wenig mit den Codec zu tun. Mir kommt es eher so vor als würden alle Threads beim Rendern aus einen mir nicht ersichtlichen Grund limitiert werden. Da aber Ressourcen noch vorhanden sind, selbst wenn gerade auf etwas gewartet wird, so müsste der "arbeitende" Teil dies ja nutzen - zumindest auf einen Kern muss die last liegen was aber ja nicht der Fall ist da alle Kerne gleich Hoch bzw. eher Niedrig in dem Fall belastet sind (Beispiel anhand der CPU). 

Ich weiß auch nicht wie ich es besser erklären soll aber fakt ist es sind noch verfügbare Ressourcen da die nicht genutzt werden ohne das aktuell irgendetwas auf dies Sinnvoll limitiert. Wäre es so wie du sagst, wenn das wirklich das Problem wäre, müsste mindestens ein Kern der CPU sowie RAM, SSD / HDD und einige CUDA Prozessoren bei 100% Auslastung liegen.


----------



## Martin Schaefer (24. Juli 2013)

Gut, ich geb auf.
Dir scheint es eh völlig egal zu sein, was man schreibt, da du eh eigentlich alles schon weißt oder sogar besser weißt. Bitteschön. Wünsche dir viel Erfolg auf der Suche nach konstanter Vollauslastung mit besseren Programmen als Premiere Pro.


----------



## Sebastian1989101 (24. Juli 2013)

Ich kenne mich halt ein wenig mit PCs aus, vielleicht auch weil ich das ganze Beruflich mache. Ich verstehe nur nicht warum Premiere meint die Ressourcen nicht nutzen zu wollen da dies für mich absolut kein Sinn macht. Es gibt keine Limitierung durch andere Schnittstellen und Premiere kann die Ressourcen in dem Moment brauchen. Außerdem habe ich auch nicht gesagt das ich eine alternative zu Premiere suche sondern nur will dass die vorhandenen Ressourcen von diesem genutzt werden solange bis Premiere nun mal an einer Limitierung stößt.


----------



## Another (24. Juli 2013)

Dann schreib doch mal den Adobe Kundensupport an.


----------



## Sebastian1989101 (25. Juli 2013)

Das habe ich bereits getan. Laut dem Adobe Kundendienst liegt der Fehler nicht an den Adobe Produkten da diese Anforderung eigentlich so Funktioniert und wohl sonst kein Fall bekannt wäre dass die Software diese Art Fehler auslöst. Darum gehe ich nach wie vor, von Konfigurationsfehlern aus.


----------

