Klagen auf "sehr hohem" Niveau... ;-)

[Troox]

Hallo,

Nur eine kurze Verständniss Frage, warum ist TS Doctor so "langsam"? Ich schneide Aufnahmen von Syfy/Fox/... HD, Die Aufnahmen liegen auf einer SSD (Samsung 840 EVO), die geschnittene Datei wird auf einer 2. SSD (ebenfalls Samsung 840 EVO) gespeichert. CPU ist bei dem gesamten Vorgang max. zu 20% ausgelastet (Intel 4770k @ 8x 4.2 GHz - Hyperthreading). Das die SSDs den Vorgang ausbremsen kann ich mir nicht vorstellen. Zieht TS Doctor überhaupt aus Hyperthreading einen Vorteil?

Grundlagen

HD TV Mitschnitt, 3155 MB, Dauer 01h06m02s (H264, 25FPS, AC3 5.1 GER/AC3 2.0 ENG), ENG zum löschen gekennzeichnet.
Werbung Vorne/Hinten als Schnitt gekennzeichnet, neue Länge 00h41m26s.

Dauer des Schnittvorgangs : ca. 30s, also bitte nicht flamen. Es ist schnell, könnte aber beim abarbeiten der Aufnahmen vom Vortag gefühlt gern noch zulegen ;-)

MfG
Troox

Edit : TS Doctor V1.2.163Beta, -Registriert-

[Mam]

Zieht TS Doctor überhaupt aus Hyperthreading einen Vorteil?

Wie sollte er ?
Ein Stream fängt vorne an und hört hinten auf, den kann man nur sequenziell abarbeiten, da ist dann nichts mit mehreren CPUs oder deren Dummies.

Aber 30s ist wirklich etwas lahm, Du solltest doch mal Dein System auf richtige Treiber oder sonstige Spaßbremsen absuchen.

[Djfe]

naja 20%, da könntest du höchstens noch 5 drauflegen bei nem Vierkerner

wenn du in den Taskmanager reinsiehst, ist einer der Kerne sicherlich voll ausgelastet

den TS Doctor parallelisieren könnte man höchstens auf GUI Ebene, aber die eigentliche Struktur lässt sich laut Aussage von Cypheros nicht wirklich in threads packen, da der TSD ja die Pakete neu schreibt und die Timecodes beachten muss
außerdem kannst du glaub ich schlecht eine Datei schreiben und mittendrin anfangen zu schreiben (man weiß ja nicht wie groß sie wird, sonst hätte man nachher einen riesigen fragmentierten Haufen auf der Platte, weil dein Programm plötzlich merkt, dass es zwischen Szene 1 und 2 mehr Platz braucht, als vorhanden ist)

außerdem hätte er nicht mit diesem Erfolg gerechnet (dass es so ausartet) und hat das Programm einfach so geschrieben
ansonsten hätte er es komplett anders gemacht und besser strukturiert
GUI-Threading würde also das neuschreiben des Programms erfordern
der Nutzen ist aber recht begrenzt (der Aufwand lohnt nicht für so eine kleine Verbesserung)


Multicore wurde auch nur erfunden, weil man plötzlich festgestellt hat, dass man aufgrund der Hitzeentwicklung nicht höher als 5 GHz gehen kann, aber trotzdem mehr Leistung braucht
letztendlich wäre man sonst sicherlich bei Single Core oder eventuell Duo geblieben

vielleicht ändert sich was in ein paar Jahrzehnten daran (Graphen verspricht im Gegensatz zu Silizium als Halbleiter theoretische 100 GHz Taktung, was dann zu einem enormen leistungszuwachs führen würde)

[peterfido]

Die Auslastung würde man nur prozentual sehen. Auch Single-Tasks hopsen von Kern zu Kern. Multicore gibt es schon länger. Da hieß es dann Coprozessor. Der Amiga konnte während eines Ladevorgangs Musik abspielen. Beim PC gab es dann solange Stille oder ein sich ständig wiederholender Ton nervte aus dem nicht weiter gefüllten Buffer der Soundkarte.  - OK hinkt etwas, passt aber grob vereinfacht 

[Djfe]

um die Theorie zu testen könntest du dem TSD bei der Bearbeitung mit dem Taskmanager (Rechtsklick auf den Prozess) einen bestimmten Kern zuweisen

wenn dann ca. 25% ausgelastet sind, kannst du das ganze nur mit einer CPU verschnellern, die eine höhere Frequenz hat (übertakten oder neu kaufen)