Nimm den SSM (auch hier im Tutorialbereich).
Beiträge von Zantos
-
-
Ohnehin mal die Frage, auf welche Werte sind bei Festplatten besonders zu achten?
Joa, hohe Transferraten sowie ggf. (für Aufnahmeplattem eher weniger wichtig) niedrige Zugriffszeiten.
Meine Empfehlung ist da eine Seagate Barracuda 7200.14 .
-
Kann man das rendern noch verschnellern
Ressourcenfressende Prozesse wie Skype beenden, ansonsten ist [lexicon]x264[/lexicon] schon verdammt gut optimiert.
nutzt das Programm Hyperthreading
Ja.
gibt es noch möglichkeiten das schneller zu machen ?
Schnelleres [lexicon]x264[/lexicon] Preset.
-
Gräser, Büsche, feine sowie kontrastreiche Texturen etc. sind immer schlecht zu komprimieren.
-
Also bezieht sich slow und fast auf die Qualität und nicht auf die Dateigröße?
Auf beides. -
Mit langsameren Presets wird effizienter encodiert, beispielsweise größerer Lookahead für effizientere B-Frames (=> größere Auslastung des RAMs), genauere, aber eben langsamere Analyse-Algorithmen etc.
Bei schnelleren Presets ist das genau das Gegenteil; wenn nun aber beispielsweise ein vergleichsweise ungenauer, schnellerer Algorithmus für die Bewegungssuche verwendet wird, ist es nur logisch, dass auch die Qualität darunter leidet. -
Premiere Pros H.264 Encoder (MainConcept H.264) kann bzgl. Effizienz nicht mit x264 mithalten. x264 wird eigentlich in der CLI ausgeführt (die vfw Version ist nicht aktuell und H.264 in AVI passt auch nicht wirklich); MeGUI ist hier nur ein GUI, welches die Konfiguration des Encoders, eine optionale Bearbeitung via Avisynth und einige weitere Tools wie Muxer zur einfacheren Verwendung bereitstellt.
-
Oder gilt dies nur für Leute die keine Programme wie Premiere Pro oder [lexicon]Sony Vegas[/lexicon] haben?
Das gilt für alle, die effizient encodieren möchten, ohne dabei ständig in der [lexicon]CLI[/lexicon] herumtippen zu müssen.
-
-
Naja, also pro Sekunde zwei Vollbilder @4K in den Stream reinzuhauen verringert die Effizienz wohl deutlich stärker als ein auf z.B. 30 verminderter Lookahead...
-
Vor allem da FFMPEGSource durch das Indexieren beim Decodieren schneller sein sollte, da beispielsweise die I-Frame Positionen bekannt sind.
-
Eine weitere Möglichkeit zur Senkung des Arbeitsspeicherverbrauchs wäre eine Absenkung des Lookaheads von [lexicon]x264[/lexicon]. Nur weiß ich nicht, ob man [lexicon]x264[/lexicon] bei [lexicon]TMPGEnc[/lexicon] so explizit konfigurieren kann.
-
Zu hoher Wahrscheinlichkeit verwendet dein "Schneideprogramm" nicht den effizienten [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] für [lexicon]H.264[/lexicon], also hast du bei gleicher Qualität weniger stark komprimierte Dateien, was zu größeren Dateien führt.
-
In der Nacht encodieren.
Btw da nun bald Ferien sind, werde ich deutlich mehr Zeit in die Programmentwicklung stecken und so hoffentlich noch in den ersten Wochen des neuen Jahres erste Beta-Versionen zum Testen und zum üblichen Bugreport raushauen können.
-
Tyerell
So rein aus dem Gefühl würde ich da als erstes auf die genaueren Algorithmen zur Bewegungssuche tippen - du kannst das Quellmaterial ja mal testweise @Slow mit
encodieren. -
Wie erkenn ich den SATA Controller?
Sollte in der Gebrauchsanweisung des Mainboards vermerkt sein. Ggf. nochmal auf der Herstellerseite nachschauen.
Wenn ich das BS auf die ssd packe ist die dann die hauptplatte? Also wo standardmäßig die programme drauf installiert werden?
Letzteres macht zumindest Windows standardmäßig bei den meisten Setups (Stichwort: Program Files).
-
Haali MKV Splitter installieren.
-
Ich denke, dass das ein 16:10 Monitor ist? Dann würde ich in 1440p 16:9 spielen und aufnehmen sowie anschließend auf 1800p 16:9 skalieren.
-
Wird denn auch ein Audiostream in der MediaInfo des encodierten Videos angezeigt?
-
1) 4 Kern und 4 verarbeite Prozesse Leistung ca 4,5 GHz oder 2) 4 Kern & 8 Prozesse bei 3,8 GHz
Eindeutig der mit acht Threads.
