Logo Logo
/// 

Welche Encoder unterstützen Quad-Core?



Noch was unklar? Dann in unserem Forum nachfragen!


Frage von Christian Grünwaldner:


Siehe Betreff.

Ich werde den Kauf der nächsten CPU davon abhängig machen, ob es sich
für meine Zwecke (;%kaum Spiele, aber Videoschnitt, MP3,
3D-Animationen/Modeling) lohnt. THG listet deutlich schnelleres
MPEG-4/H.264 und etwas schnelleres MPEG-2 Encoding für Quad-Core CPUs
von Intel, aber nutzt als Referenz den Mainconcept Codec sowie Pinnacle
Studio 11 Plus. Da ich beides nicht verwende, würden mir die 4 Kerne
nichts bringen, wenn meine SW nur Dual unterstützt.

Weiß jemand, ob TMPEG Enc. 2.5x Plus, Premiere Pro 2 (;oder Essential
3.x) und TMPEG DVD Author 2.x (;3.x soll angeschafft werden), sowie
VirtualDUB für H264/AVC Codec Quad's unterstützen bzw. daraus einen
nennenswerten Nutzen (;im Vergleich mit Dual-Core) ziehen?

Derzeitige CPU ist PentiumD805 @ 2x3GHz. OS soll so lange als möglich XP
bleiben.

Xpost & f'up




Antwort von Sebastian Kaps:

Christian Grünwaldner schrieb:

> Studio 11 Plus. Da ich beides nicht verwende, würden mir die 4 Kerne
> nichts bringen, wenn meine SW nur Dual unterstützt.

Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt.
Entweder ist die Software so geschrieben, daß Teilaufgaben in separaten
Threads abgehandelt werden - dann sorgt das Betriebssystem für eine
möglichst optimale Verteilung auf die zur Verfügung stehenden CPUs -
oder eben nicht. Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung
stehen.

--
Ciao, Sebastian




Antwort von Christian Potzinger:

Sebastian Kaps maltreated the Keyboard with following:

> Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung stehen.

Ack. Man muss allerdings sicher stellen, dass das OS (;meine
W2K Version unterstützt max. 2) alle CPUs unterstützt.
--
ryl: G'Kar









Antwort von Sebastian Kaps:

Christian Potzinger schrieb:

> Ack. Man muss allerdings sicher stellen, dass das OS (;meine
> W2K Version unterstützt max. 2) alle CPUs unterstützt.

Das ist bei XP ja der Fall.

--
Ciao, Sebastian




Antwort von Jens Heydekorn:

Hallo,

ich kann nicht sagen, ob die von Dir genannten Applikationen auf
Multi-Core-CPUs schneller arbeiten.

Doch ist es prinzipiell unerheblich, wie viele Kerne die CPU hat, wenn
der Algorithmus nicht geeignet ist. Oder anders herum formuliert: Sollte =

ein Programm einen Vorteil aus zwei Kernen ziehen, so kann bzw. könn=
te
es auch einen Vorteil aus noch mehr Kernen ziehen.
Allerdings hängen die Geschwindigkeitsvorteile von einer Reihe von
Faktoren ab, die Theorie und Praxis abweichend erscheinen lassen. Hier
sind die Praxistests von THG nützlich, doch allg. Rückschlü=
sse erlauben
diese nicht.

Gruß
-JH





Antwort von Norbert Müller
Christian Grünwaldner schrieb:
> Siehe Betreff.
>
> Ich werde den Kauf der nächsten CPU davon abhängig machen, ob es sich
> für meine Zwecke (;%kaum Spiele, aber Videoschnitt, MP3,
> 3D-Animationen/Modeling) lohnt. THG listet deutlich schnelleres
> MPEG-4/H.264 und etwas schnelleres MPEG-2 Encoding für Quad-Core CPUs
> von Intel, aber nutzt als Referenz den Mainconcept Codec sowie
> Pinnacle Studio 11 Plus. Da ich beides nicht verwende, würden mir die
> 4 Kerne nichts bringen, wenn meine SW nur Dual unterstützt.
>
> Weiß jemand, ob TMPEG Enc. 2.5x Plus, Premiere Pro 2 (;oder Essential
> 3.x) und TMPEG DVD Author 2.x (;3.x soll angeschafft werden), sowie
> VirtualDUB für H264/AVC Codec Quad's unterstützen bzw. daraus einen
> nennenswerten Nutzen (;im Vergleich mit Dual-Core) ziehen?
>
> Derzeitige CPU ist PentiumD805 @ 2x3GHz. OS soll so lange als möglich
> XP bleiben.

DVD-Author 2.0 (;verwende ich auch):
http://tmpgenc.pegasys-inc.com/de/product/tda20.html
Optimiert für Intel Pentium4 Prozessor mit HT-Technologie

DVD-Author 3.0:
http://tmpgenc.pegasys-inc.com/de/product/tda3d.html
Optimiert für Intel Pentium4 Prozessor mit HT-Technologie und Intel® CoreT 2
Duo Prozessor

TMPGEnc Plus 2.5
http://tmpgenc.pegasys-inc.com/de/product/tp.html
Optimized for Intel® Pentium®4 processor with HT technology

Ausser der höheren Rechenleistung eines Quad-Core wird also von den
Programmen her nichts zu erwarten sein - wobei ich mich frage, wie das mit
der Programmoptimierung geht.

Mein Problem derzeit ist, dass die neuen DirectX 10 Grafikkarten für
Avid/Pinnacle Liquid Edition ein Problem darstellen - das Programm
funktioniert damit nicht.
http://forums.pinnaclesys.com/forums/thread/45551.aspx - muß mich einmal
durch diesen Wust an englischsprachigen Zuschriften durchkämpfen :-(;
Habe auch aus diesem Grund noch immer ein i865/Pentium 4HT System mit ATI
X800GT, würde aber gerne auf ein P35 Board wechseln, auch wenn dessen
Northbrige ziemlich heiss wird. Doch welche Grafikkarte bleibt kühl und
leise und bietet min. 256bit-Anbindung an 512MB Speicher?

Gruß, Norbert





Antwort von Heiko Nocon:

Sebastian Kaps wrote:

>Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt.

Doch, natürlich. Windows z.B. Da hast du doch schonmal von gehört, oder?

>Entweder ist die Software so geschrieben, daß Teilaufgaben in separaten
>Threads abgehandelt werden - dann sorgt das Betriebssystem für eine
>möglichst optimale Verteilung auf die zur Verfügung stehenden CPUs -
>oder eben nicht. Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung
>stehen.

Nein, das stimmt so natürlich auch nicht. Wenn eine Anwendung eine
zeitaufwendige Aufgabe z.B. in zwei Threads zerlegt, dann hat sie von
vier Cores genau garnix, sondern nutzt maximal zwei davon und vielleicht
ab und an noch einen dritten, wenn's im Haupthread der Anwendung
(;Benutzeroberfläche) etwas zu tuen gibt.

Auch der Ausweg, einfach immer sehr viele Threads zu erzeugen und dem OS
die Arbeit zu überlassen, sie möglichst effizient laufen zu lassen, ist
kein wirklicher Ausweg.

Zum einen gibt es nämlich mehr als genug nicht parallelisierbare
Probleme, die lassen sich einfach nicht in Threads aufsplitten,
zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden.

Und zum anderen erzeugen Threads auch einen gewissen
Verwaltungsoverhead, der mit der Zahl der Threads überproportional
ansteigt. Es ist also kontraproduktiv, ein Problem in meinetwegen 32
Threads zu zerlegen, wenn man nur zwei Cores für deren Abarbeitung zur
Verfügung hat.

D.h: Um eine zunehmende Anzahl von Kernen so zu benutzen, daß die
effektive Rechenleistung wenigstens annähernd proportional mit der Zahl
der Kerne wächst, muß eine Anwendung nicht nur ein parallelisierbares
Problem bearbeiten, sondern außerdem die Zahl der Threads entsprechend
der Zahl der Kerne anpassen (;erste Näherung, eigentlich muß sie die Zahl
der Kerne mit freier Rechenzeit als Bezug nehmen).

Das umzusetzen, ist alles andere als einfach. Das Problem kann man sich
ja sowieso nicht aussuchen und die Zahl der Kerne ändert sich in der
Realität leider auch von System zu System. Es ist also praktisch
unmöglich, eine Software zu schreiben, die auf jedem System optimal
läuft.





Antwort von Sebastian Kaps:

Heiko Nocon schrieb:

>> Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt.
> Doch, natürlich. Windows z.B. Da hast du doch schonmal von gehört, oder?

Windows? Ja, da war mal was. Dort ist das aber keine Einschränkung der
Software, sondern der Lizenz. (;Und, ja, es gibt natürlich Software, die
explizit nur eine CPU unterstützt.)

> Nein, das stimmt so natürlich auch nicht. Wenn eine Anwendung eine
> zeitaufwendige Aufgabe z.B. in zwei Threads zerlegt, dann hat sie von
> vier Cores genau garnix, sondern nutzt maximal zwei davon und vielleicht
> ab und an noch einen dritten, wenn's im Haupthread der Anwendung
> (;Benutzeroberfläche) etwas zu tuen gibt.

So gesehen richtig, nur funktioniert das so nicht. Wenn eine Software
gleichzeitig auf mehr als einer CPU laufen soll, dann fängt der
Entwickler nicht an und "zerlegt Aufgaben in zwei Threads", sondern er
wird sämtliche Aufgaben in soviele Threads wie (;sinnvoll) möglich
kapseln.

Der Schritt von Software für eine CPU zu Software, die auf mehreren CPUs
läuft ist groß, weil man die entsprechenden Aufgaben erstmal in
Teilaufgaben unterteilen muß und man sich bei parallel laufenden Threads
einige Gedanken über Synchronisierung der Threads und die Konsistenz der
Daten machen muß. Hat man das erstmal getan, dann ist es egal, ob die
Software auf 2 oder 200 CPUs läuft.

> Zum einen gibt es nämlich mehr als genug nicht parallelisierbare
> Probleme, die lassen sich einfach nicht in Threads aufsplitten,
> zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden.

Ich gehe mal davon aus, daß das Encoding von Videos durchaus gut
parallelisierbar ist.

> Und zum anderen erzeugen Threads auch einen gewissen
> Verwaltungsoverhead, der mit der Zahl der Threads überproportional
> ansteigt. Es ist also kontraproduktiv, ein Problem in meinetwegen 32
> Threads zu zerlegen, wenn man nur zwei Cores für deren Abarbeitung zur
> Verfügung hat.

Ja. Und? Deswegen (;u.a.) ist ein Quad-Core-Rechner auch nicht doppelt so
schnell wie ein Dual-Core-Rechner. Das war aber nicht das Thema.

> D.h: Um eine zunehmende Anzahl von Kernen so zu benutzen, daß die
> effektive Rechenleistung wenigstens annähernd proportional mit der Zahl
> der Kerne wächst, muß eine Anwendung nicht nur ein parallelisierbares
> Problem bearbeiten, sondern außerdem die Zahl der Threads entsprechend
> der Zahl der Kerne anpassen (;erste Näherung, eigentlich muß sie die Zahl
> der Kerne mit freier Rechenzeit als Bezug nehmen).

Letzteres ist Aufgabe des Betriebssystems und nicht der Anwendung.

> Das umzusetzen, ist alles andere als einfach. Das Problem kann man sich
> ja sowieso nicht aussuchen und die Zahl der Kerne ändert sich in der
> Realität leider auch von System zu System. Es ist also praktisch
> unmöglich, eine Software zu schreiben, die auf jedem System optimal
> läuft.

Stimmt. Hat aber mit dem Thema nix zu tun ;-)

--
Ciao, Sebastian




Antwort von Christian Schroeder:

Heiko Nocon schrieb:
> Sebastian Kaps wrote:
>
>> Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt.
>
> Doch, natürlich. Windows z.B. Da hast du doch schonmal von gehört, oder?
>
>> Entweder ist die Software so geschrieben, daß Teilaufgaben in separaten
>> Threads abgehandelt werden - dann sorgt das Betriebssystem für eine
>> möglichst optimale Verteilung auf die zur Verfügung stehenden CPUs -
>> oder eben nicht. Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung
>> stehen.
>
> Nein, das stimmt so natürlich auch nicht. Wenn eine Anwendung eine
> zeitaufwendige Aufgabe z.B. in zwei Threads zerlegt, dann hat sie von
> vier Cores genau garnix, sondern nutzt maximal zwei davon und vielleicht
> ab und an noch einen dritten, wenn's im Haupthread der Anwendung
> (;Benutzeroberfläche) etwas zu tuen gibt.
>
> Auch der Ausweg, einfach immer sehr viele Threads zu erzeugen und dem OS
> die Arbeit zu überlassen, sie möglichst effizient laufen zu lassen, ist
> kein wirklicher Ausweg.

Der Programmierer zerlegt die Aufgabe nicht in eine feste Anzahl von
Threads, sondern nutzt z.B. das MPI-Konzept. Da wird im Grunde eine
Warteschlange von parallel zu verarbeitenden Daten erstellt und dann von
den Prozessoren abgearbeitet. Wenns zwei sind, machen das zwei, oder
eben vier oder oder. Lediglich die Datenmenge (;und ihre Struktur)
bestimmen, wie viele Prozessoren man sinnvoll nutzen kann.

> Zum einen gibt es nämlich mehr als genug nicht parallelisierbare
> Probleme, die lassen sich einfach nicht in Threads aufsplitten,
> zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden.

Wie Sebastian schon sagte, sollte das bei Videocodierung nicht so sein.
>
> Und zum anderen erzeugen Threads auch einen gewissen
> Verwaltungsoverhead, der mit der Zahl der Threads überproportional
> ansteigt. Es ist also kontraproduktiv, ein Problem in meinetwegen 32
> Threads zu zerlegen, wenn man nur zwei Cores für deren Abarbeitung zur
> Verfügung hat.

Wie gesagt: Die Anzahl der Prozessoren wird nicht hart codiert.

> D.h: Um eine zunehmende Anzahl von Kernen so zu benutzen, daß die
> effektive Rechenleistung wenigstens annähernd proportional mit der Zahl
> der Kerne wächst, muß eine Anwendung nicht nur ein parallelisierbares
> Problem bearbeiten, sondern außerdem die Zahl der Threads entsprechend
> der Zahl der Kerne anpassen (;erste Näherung, eigentlich muß sie die Zahl
> der Kerne mit freier Rechenzeit als Bezug nehmen).
>
> Das umzusetzen, ist alles andere als einfach. Das Problem kann man sich
> ja sowieso nicht aussuchen und die Zahl der Kerne ändert sich in der
> Realität leider auch von System zu System. Es ist also praktisch
> unmöglich, eine Software zu schreiben, die auf jedem System optimal
> läuft.

Das ist natürlich richtig, gilt aber nicht in Bezug auf die Anzahl der
Kerne.

--
Gruß Chris
Wer Freiheit aufgibt, um Sicherheit zu gewinnen, wird beides verlieren




Antwort von Andreas Erber:

Norbert Müller wrote:

> dessen Northbrige ziemlich heiss wird. Doch welche Grafikkarte bleibt
> kühl und leise und bietet min. 256bit-Anbindung an 512MB Speicher?
>

Ich hab gute Erfahrungen mit einer Club3D Ati Radeon X1952TX gemacht, im
idle ist die genauso leise wie mein Dell Dimension 9150, der nicht unhörbar
leise ist, aber so unterm schreibtisch nicht weit davon entfernt. Wenn man
spielt dreht der Lüfter natürlich auf, aber das macht der CPU Lüfter auch
und man hört beide deutlich aber nicht unangenehm.

Allgemein liest man dass die Club3D Karten das mit der Kühlung ganz
ordentlich hinbekämen, evtl bestellst dir mal eine von denen, kannst sie ja
dank Fernabsatzgesetz wieder zurücksschicken wenn sie doch zu laut ist.

LG Andy





Antwort von Norbert Müller
Andreas Erber schrieb:
> Norbert Müller wrote:
>
>> dessen Northbrige ziemlich heiss wird. Doch welche Grafikkarte bleibt
>> kühl und leise und bietet min. 256bit-Anbindung an 512MB Speicher?
>>
>
> Ich hab gute Erfahrungen mit einer Club3D Ati Radeon X1952TX gemacht,
> im idle ist die genauso leise wie mein Dell Dimension 9150, der nicht
> unhörbar leise ist, aber so unterm schreibtisch nicht weit davon
> entfernt. Wenn man spielt dreht der Lüfter natürlich auf, aber das
> macht der CPU Lüfter auch und man hört beide deutlich aber nicht
> unangenehm.
> Allgemein liest man dass die Club3D Karten das mit der Kühlung ganz
> ordentlich hinbekämen, evtl bestellst dir mal eine von denen, kannst
> sie ja dank Fernabsatzgesetz wieder zurücksschicken wenn sie doch zu
> laut ist.

Vielen Dank, ich hab' nämlich derzeit überhaupt keine Ahnung von den
GraKa's, meine Sapphire Radeon X800GT, im Vorjahr um teure 200.- gekauft,
256MB/256bit (;AGP) reicht an sich für mein Videoschnittsystem in DV, jedoch
sollte mein überarbeiteter PC auch für HDV-Schnitt passen. Dafür wird eine
AGP/besser PCIe-Karte mit 256/besser 512MB empfohlen*, sonst keine Angaben.
Und Spiele spiele ich keine.

Drum auch meine Frage, es könnte doch vielleicht auch
einfacher/leistungsschwächer gehen als mit der X1952TX? Habe die Radeon HD
3850 entdeckt, die soll auch relativ kühl und sehr leise laufen, am liebsten
wäre mir jedoch eine HD 2600 (;Pro oder XT, keine Ahnung, was der Unterschied
ist), leider hat die nur 128bit Speicheranbindung, auch bei 512 MB, jedoch
auch eine Controller-Ringleitung mit 256bit -- wiederum keine Ahnung, ob das
die 128bit aufmotzt.

Für OpenGL (;3D) und sehr viele Spuren in der Timeline verwenden die
Semiprofis (;*auf Videoschnittsystem Avid/Pinnacle Liquid Edition, das ich
auch verwende) Grafikkarten-Monster wie GeForce 7800, so eine Zusatzheizung
will ich aber nicht haben. So 35-50 Watt würden mir reichen - die
Matrox-Karten haben nur 12 Watt, sind angeblich auch für Video geeignet,
haben aber nur 64bit oder 128 bit an 256 MB und das Schnittsystem rendert
viele Effekte über die GPU.

VG, Norbert





Antwort von Heiko Nocon:

Sebastian Kaps wrote:

>Wenn eine Software
>gleichzeitig auf mehr als einer CPU laufen soll, dann fängt der
>Entwickler nicht an und "zerlegt Aufgaben in zwei Threads"

Doch, du wirst lachen, genau so wird auf breiter Front existierende
Software erstmal notdürftig "multicoretauglich" gemacht. Leicht
isolierbare Teilaufgaben werden explizit in getrennte Threads gepackt
und laufen dann (;weil eigentlich nicht parallelisierbar) in einer Art
"daisy chain", teilweise sogar mit busy loops als Synchronisation.
(;Wohl, um die Core-Auslastung den erwünschten 100% besser anzunähern)

Extrem traurig und kaum zu glauben, aber ganz real an sehr vielen
kommerziellen Produkten zu bewundern, auch und gerade im Bereich
Video-Encoder...

Natürlich sind die Dinger so immer noch schneller als auf einem
Einzelkern, aber deutlich langsamer, als sie sein könnten.










Antwort von Christian Schroeder:

Marcus Jodorf schrieb:
> Christian Schroeder schrieb:
>
>>> Zum einen gibt es nämlich mehr als genug nicht parallelisierbare
>>> Probleme, die lassen sich einfach nicht in Threads aufsplitten,
>>> zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden.
>> Wie Sebastian schon sagte, sollte das bei Videocodierung nicht so
>> sein.
>
> Nicht wirklich. Das ist genau bei Videokodierung ein Problem.
> Denn bei verlustbehafteten Verfahren bestehen gewisse Abhängigkeiten im
> Datenstrom, die man beachten muß. Nachfolgeframes bauen z.B. auf
> vorhergehenden auf und das kann man nicht mal eben einfach
> entserialisieren.
> Einige Abhängigkeiten kann man zwar mißachten, was aber zu Lasten der
> Effizienz geht -> schlechtere Kompression und/oder
> Qualitätsverschlechterung.

Klar muss das Keyframe abgearbeitet sein, um die nächsten Frames zu
bearbeiten, aber ab dem nächsten Keyframe gehts doch wieder von vorn
los. Das sollte doch kein Problem sein.

--
Gruß Chris
Wer Freiheit aufgibt, um Sicherheit zu gewinnen, wird beides verlieren




Antwort von Christian Schroeder:

Marcus Jodorf schrieb:
> Christian Schroeder schrieb:
>
>>> Einige Abhängigkeiten kann man zwar mißachten, was aber zu Lasten der
>>> Effizienz geht -> schlechtere Kompression und/oder
>>> Qualitätsverschlechterung.
>
>> Klar muss das Keyframe abgearbeitet sein, um die nächsten Frames zu
>> bearbeiten, aber ab dem nächsten Keyframe gehts doch wieder von vorn
>> los. Das sollte doch kein Problem sein.
>
> Denk einfach nochmal drüber nach. Wie willst Du z.B. das
> Quellmaterial möglichst optimal aufteilen?
>
> Sagen wir mal, Du würdest jeden Thread jeweils von Keyframe zu Keyframe
> (;auf das Ergebnis bezogen!) arbeiten lassen, also GOP basiert. Das wird
> dann schon schwierig, wenn man es mit einem Codec zu tun hat, der mit
> variablen GOP-Längen arbeitet.
> Ein Thread verarbeitet dann beispielsweise drei Quellframes und der
> nächste bringt in seiner GOP dann 16 Frames unter und der dritte schafft
> aufgrund des Quellmaterials vielleicht 5 Frames, usw.
> Problem bei der Geschichte ist halt, daß man nicht unbedingt schon
> vorher - wenn man die Quellframes den Threads zuteilt - weiß, wann der
> nächste Keyframe gesetzt wird. Selbst wenn man ein Maximalintervall
> festlegt, kann es quellmaterialbedingt nötig sein, noch an ganz anderen
> Positionen Keyframes zu setzen.
>
> Kurz: Du kannst vorher nicht wirklich wissen, wieviele Frames ein Thread
> jeweils optimal im nächsten Abschnitt bearbeiten sollte. Wo der nächste
> Keyframe sitzt, entscheidet sich erst bei der Kodierung. Da hat man also
> ein Allokationsproblem bei der Aufteilung der Quellabschnitte.
> Um sowas einigermaßen in den Griff zu kriegen, muß man teilweise
> erheblichen Aufwand treiben.
>
> Falls Du das mit den Keyframes oben andersherum meinst und auf das
> Quellmaterial bezogen hast, dann hast Du sofort ein Qualitätsproblem.

So meinte ich das.

> Fütterst Du die Threads einfach mit den Frames von Keyframe zu Keyframe
> des Quellmaterials, dann ist auch der Thread gezwungen, spätestens mit
> dem letzten Frame eine GOP abzuschließen. Je nach Material und Codec
> kann das völlig ineffizient sein.

Ich dachte mir das so (;ohne es zuende gedacht zu haben), dass die
Threads im Quellmaterial auf Keyframes zugreifen und dann die
notwendigen Informationen untereinander austauschen.

--
Gruß Chris
Wer Freiheit aufgibt, um Sicherheit zu gewinnen, wird beides verlieren




Antwort von Ka Prucha:

"Marcus Jodorf" schrieb
> Ka Prucha schrieb:
>
>> Ich denke da eher an die Mechanik,
>
> Was habt ihr nur alle mit Eurem defragmentieren? Selbst MS ist doch
> schon lange genug von fat weg, als daß das immer noch die Köpfe so
> verseuchen könnte?

Servus

Wir verwenden in der Firma Mutiprozessorsysteme und eine Software
bei der explizit die Anzahl der Prozessoren vorgeben werden kann.
Ist zwar nicht Video sondern Photogrammetrie, aber das Geräusch der
Festplatten zeigt, das es reichlich Zeit ist etwas besseres als diese
alte Magnetscheibentechnologie zu verwenden.

Ach ja, FAT verwende ich seit mindestens fünf Jahren nur auf den
Speicherkarten diverser Digitalkameras.

Defragmentieren ist normalerweise heute nicht notwendig, sonder
eher Unsinn. Ausgenommen man würde wirklich die von dir
vorgeschlagene Teilungsstrategie für Videocodierung verwenden.

Wie schon einmal geschrieben, erst bei Solid-State Disks oder
vergleichbaren, ist das dann die bessere Strategie.

mfg Ka Prucha





Antwort von Andreas Erber:

Ka Prucha wrote:

> Wie schon einmal geschrieben, erst bei Solid-State Disks oder
> vergleichbaren, ist das dann die bessere Strategie.

Auf Solid State Disks sollte es völlig egal sein wie die Daten drauf stehen,
da jederzeit auf jeden Datenblock gleich schnell zugegriffen werden kann.
Selbst bei Maximalster Fragmentierung sollte sich da kein allzugroßer effekt
Einstellen.

LG Andy





Antwort von Ka Prucha:

"Andreas Erber" schrieb
>
> Auf Solid State Disks sollte es völlig egal sein wie die Daten drauf =
stehen,
> da jederzeit auf jeden Datenblock gleich schnell zugegriffen werden =
kann.
> Selbst bei Maximalster Fragmentierung sollte sich da kein =
allzugroßer effekt
> Einstellen.

Servus

Genau! Allerdings sind die noch dafür zu bezahlenden 250 Euro, bei der =
für
Video empfehlenswerte Mindestgröße von 32 GB, für Amateure noch in =
der
oberen Preislage. Ist schon ernsthaft zu überlegen, aber man darf dann
nicht traurig sein wenn es nächstes Jahr nur noch die Hälfte kostet.

mfg Ka Prucha












Noch was unklar? Dann in unserem Forum nachfragen!


Antworten zu ähnlichen Fragen:
Apple: Neues MacBook Air etwas günstiger, mit besserer Tastatur und max. Quad-Core CPU
Hardware Encoder oder nicht? Welche Karte nehmen?
Endlich Desktop-Achtkerner von Intel - Core i9-9900K und Core i7-9700K
Atomos Connect Modellreihe wird optional NDI|HX unterstützen
Google Chrome und Firefox Betaversionen unterstützen AV1 Videocodec
Atomos Ninja V wird Nikon N-Log unterstützen // Photokina 2018
TV-Karte m. Quad-Tuner + Hardware-Capture?
Kostenloser VLC Mediaplayer erreicht 3 Milliarden Downloads und wird bald AirPlay unterstützen // CES 2019
OnePlus 8 Pro Smartphone mit Quad-Kamera vorgestellt
Rekord: Samsung Galaxy A9 (2018) mit Quad-Kamera vorgestellt
Blackmagic: Neuer DeckLink Quad HDMI Recorder und zwei Updates
Quad-LNB / High ClassA Koaxkabel 8.2mm >120dB: Fachgerechter Anschluss
Accsoon CineView Quad: Dual Band Videofunkstrecke mit SDI und HDMI für 529 Dollar
Quad Switch LNB oder externe Switch?
Steadicam: M-2 Core Kits
TV Monitor fürs Wohnzimmer - welche Größe und welche Marke ? Tipps ?
Xvid und AMD Dual Core
Coden für Filmer - welche Sprachen, welche Anwendungen?
Intel Core i5 vs i9 CPU - welcher ist schneller?
Neu: Core SWX Akkuplatte für Sony FX6
Mac Pro 6.1 2013 gebraucht 8- 10- oder 12-Core kaufen?
Intel Sechs-Core i9 im neuen Macbook Pro 2018 gedrosselt?
Intels Comet Lake Prozessoren für Notebooks - Core i9-10980HK
Gerücht: Intel Core i9-9900K mit 8 Kernen und 5 GHz Turbo
Neu: Core SWX Nano-F 45Wh Akku im Sony L-Serien Format
Intel Rocket Lake-S: Neue Core i-11000 Desktop CPUs vorgestellt

















weitere Themen:
Spezialthemen


16:9
3D
4K
AI
ARD
ARTE
AVCHD
AVI
Adapter
Adobe After Effects
Adobe Premiere Pro
After effects
Akku
Akkus
Apple
Apple Final Cut Pro
Audio
Aufnahme
Aufnahmen
Avid
Avid Media Composer
Band
Bild
Bit
Blackmagic
Blackmagic DaVinci Resolve
Blackmagic Design DaVinci Resolve
Blende
Book
Brennen
Cam
Camcorder
Camera
Canon
Canon EOS
Canon EOS 5D MKII
Canon EOS C300
Capture
Capturing
Cinema
Clip
ClipKanal
Clips
Codec
Codecs
DSLR
Datei
Digital
EDIUS
ENG
EOS
Effect
Effekt
Effekte
Empfehlung
Euro
Export
Fehler
Festplatte
File
Film
Filme
Filmen
Filter
Final Cut
Final Cut Pro
Format
Formate
Foto
Frage
Frame
GoPro
Grass Valley Edius
HDMI
HDR
Hilfe
Import
JVC
KI
Kabel
Kamera
Kanal
Kauf
Kaufberatung
Kaufe
Kaufen
Kurzfilm
Layer
Licht
Light
Live
Lösung
MAGIX video deLuxe
MPEG
MPEG-2
MPEG2
Mac
Magix
Magix Vegas Pro
Menü
Mikro
Mikrofon
Mikrophone
Monitor
Movie
Musik
Musikvideo
NAB
Nero
News
Nikon
Objektiv
Objektive
PC
Panasonic
Panasonic GH2
Panasonic HC-X1
Panasonic S1 mit V-Log
Panasonic S5
Pinnacle
Pinnacle Studio
Player
Plugin
Plugins
Premiere
Produktion
Projekt
RAW
RED
Recorder
Red
Render
Rendern
Schnitt
Software
Sony
Sony HDR
Sound
Speicher
Stativ
Stative
Streaming
Studio
TV
Test
Titel
Ton
USB
Umwandeln
Update
Vegas
Video
Video-DSLR
Videos
Videoschnitt
Windows
YouTube
Zoom