Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
das mit dem [lexicon]Frameserver[/lexicon] hört sich genau nach dem an was ich brauch 
die Videos mit der Software bearbeiten und sie dann abschließend [lexicon]rendern[/lexicon] mit [lexicon]meGui[/lexicon]! aber wie kann ich des einstellen / installieren ?
das mit dem [lexicon]Sagaras Scriptmaker[/lexicon] hat mir nicht gefallen
Oh, lese gerade, es funktioniere kein [lexicon]Frameserver[/lexicon] mit MVD 2015, aber ich habe das nicht, also kann ich leider nichts genaues sagen 
Dann bliebe aber jedenfalls noch der [lexicon]x264vfw[/lexicon], der geht glaube ich mit [lexicon]Magix[/lexicon], ist halt [lexicon]x264[/lexicon] als [lexicon]Codec[/lexicon] für Programme, unterstützt jedoch ein paar Dinge wie 10-bit nicht 
Servus beinander! Ich danke mal für das Tutorial, das mir in der Hinsicht sehr weitergeholfen hat die Qualität meiner Videos zu verbessern.
Ich bin noch nicht lange LPler und bin noch am herumschrauben was bestimmte Dinge betrifft, aber den sogennanten "Workflow" bekomme ich langsam hin.
Ich habe einen fast niegelnagelneuen PC, mit dem ich so ziemlich alles auf Höchststufe spielen kann. Als mein erstes Projekt habe ich deswegen The Witcher 2: Assassins of Kings ausgewählt, was ich in 1080p mit 60 FPS aufnehme. Das heißt soweit ich das verstanden habe ist die Komplexität bei Kampfszenen in denen viel Motionblur vorkommt relativ hoch.
Ich verwende Sony Movie Studio Platinum 12, Debug [lexicon]Frameserver[/lexicon], [lexicon]SSM[/lexicon], [lexicon]MeGui[/lexicon] und KVM Merge. Ich konvertiere mit Constant Quality mit 21 auf Medium.
Nun zum Problem: Ein Video von mir hat bei 20 Minuten durchschnittlich 1,5 bis 2GB Größe, was für mich auch so passen würde. Jetzt hab ich aber festgestellt, dass zwei Videos mit ähnlichem Inhalt (ich laufe im Wald herum und töte ein paar Monster) und bei gleichen Einstellungen und mit selber Länge in [lexicon]MeGui[/lexicon] ganze 4GB an Speichergröße auseinanderliegen. Woran kann das liegen und was für Möglichkeiten hab ich das herunterzukürzen ohne zu große an Qualität einzubüßen? Ich weiß natürlich, dass die doppelte Framerate gleich mal Dateien explodieren lässt, aber bis ca. 2GB hab ich kein Problem damit.
Hier wäre das Script von [lexicon]SSM[/lexicon], das ich für die Konvertierung in [lexicon]MeGui[/lexicon] benutze:
ZitatAlles anzeigen### [lexicon]SagaraS Scriptmaker[/lexicon] - Version 5.6 ###
### Lade Plugins und setze die globalen Variablen ###
Global breite = 1920
Global hoehe = 1080
Global AR = 1
### Lade Videoquellen ###
SetMTMode(3,2)
### Filter Verarbeitungszone ###
SetMTMode(2)
Tweak(0.0, 1.0, 0.0, 1.0, True)
### Funktion für Video-Laderoutine ###
Function AVIload (String file, int loading, int cl, int co, int cr, int cu, string pixtype, string afps, int fpsn, int fpsd) {
(loading == 1) ? FFIndex(file) : nop()
clip0 = (loading == 3) ? LWLibavVideoSource(file) : (loading == 2) ? Import(file).KillAudio() : (loading == 1) ? FFVideoSource(file, threads=1) : (pixtype == "Auto") ? AVISource(file, false).KillAudio() : AVISource(file, false, pixel_type=pixtype).KillAudio()
clip0 = clip0.Levels(0, 1.000, 255, 0, 255, True)
clip1 = clip0.AutoFPS(afps, fpsn, fpsd).Cropping(cl, co, cr, cu)
Return (clip1.width == breite && clip1.height == hoehe) ? clip1.ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline16") : Clip1.Resize()
}
Function AutoFPS (Clip clip0, string afps, int fpsn, int fpsd) {
rate1 = (afps == "Auto") ? (Round(Float(clip0.framerate * 1000)) / 1000) / 2 : nop()
rate2 = (afps == "Auto") ? Round(clip0.framerate) / 2 : nop()
rate = (afps == "Auto") ? (rate1 == rate2) ? 1 : 1001 : (afps == "Igno.") ? clip0.frameratedenominator : fpsd
ratefaktor = (afps == "Auto") ? (rate == 1001) ? 1000 : 1 : nop()
clip0 = (afps == "Auto") ? (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate) : (afps == "Igno.") ? clip0.AssumeFPS(clip0.frameratenumerator, rate) : clip0.AssumeFPS(fpsn, rate)
Return clip0.ChangeFPS(60 * 1000, 1001)
}
Function Cropping (Clip clip0, int cl, int co, int cr, int cu) {
clip0 = (clip0.IsRGB32() == True) ? clip0.ConvertToRGB24() : clip0
Return (cl != 0co != 0
}
Function Resize (Clip clip1) {
clip1 = (AR == 1) ? ((float(Clip1.height * breite) / clip1.width) / 2 == round((float(Clip1.height * breite) / clip1.width) / 2)) ? ((float(Clip1.width * hoehe) / clip1.height) / 2 == round((float(Clip1.width * hoehe) / clip1.height) / 2)) ? clip1 : clip1.ConvertToRGB24(matrix = "Rec709") : clip1.ConvertToRGB24(matrix = "Rec709") : clip1
clip1 = (AR == 1) ? (((clip1.width * hoehe) / clip1.height > breite) ? Clip1.Spline16Resize(breite, ceil(float(Clip1.height * breite) / clip1.width)) : Clip1.Spline16Resize(ceil(float(clip1.width * hoehe) / clip1.height), hoehe)) : clip1.Spline16Resize(breite, hoehe).ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline16")
back = (AR == 1) ? (0 == 1) ? ImageReader("", 0, clip1.framecount - 1, clip1.framerate).ChangeFPS(Clip1.frameratenumerator, Clip1.frameratedenominator).Spline16Resize(breite, hoehe).ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline16") : BlankClip(clip1, width = breite, height = hoehe, pixel_type = "YV12").KillAudio() : clip1
Return (AR == 1) ? Overlay(back, clip1, (back.width - clip1.width) / 2, (back.height - clip1.height) / 2) : clip1
}
Wenn ihr noch etwas braucht, dann nur raus damit
Woran kann das liegen und was für Möglichkeiten hab ich das herunterzukürzen ohne zu große an Qualität einzubüßen?
Ich probier gerade aus den [lexicon]CRF[/lexicon] bei zu komplexem Material zu bremsen.
Mit --vbv-bufsize 10000 (Zahl kann ersetzt werden) wird der [lexicon]CRF[/lexicon] gebremst, falls er die maximale [lexicon]Bitrate[/lexicon] überschreitet. Was ein guter Kompromiss zwischen Dateigröße und Qualitätseinbuße ist, muss du dann selbst entscheiden und mit der [lexicon]Bitrate[/lexicon] etwas rumspielen.
Das widerspricht halt dem eigentlichen [lexicon]CRF[/lexicon]-Grundgedanken - dauerhaft gleichbleibende Qualität.
Und wenn du eben konstante Qualität haben willst, musst du auch mit eventuellen Peaks leben.
Generell wird das aber wohl funktionieren - ich finde 10000 je nach [lexicon]Auflösung[/lexicon] und Spiel etwas niedrig angesetzt. Ich denke 20000/30000 sollten es schon sein - wobei es natürlich fraglich ist, ob diese kurzen Peaks wirklich so viel [lexicon]Bitrate[/lexicon] fressen.
Wenn ich dadran denken das ich Spiele habe wo die Peaks bei 72.000 sind aber die durchschnittliche [lexicon]Bitrate[/lexicon] gerade mal bei 18.000 ist...
Kommt halt auch immer auf die Internetleitung an. Wenn ich [lexicon]Arma 3[/lexicon] nicht irgendwie [lexicon]Bitrate[/lexicon] abziehe kann ich für 15min 4 Tage hochladen xD Das das ganze dann schön matschig wird ist halt klar aber anders geht es sonst nicht
Und [lexicon]CRF[/lexicon] ist nunmal kein bitratefixed encoding, sondern qualityfixed encoding, und es ist nunmal nicht alles gleich gut komprimierbar.
Außerdem ist es unsinnig die threads auf 2 zu begrenzen wenn du eh nur 1920x1080 machst. Threadlimit beim Multithreading raus, damit du MT auch nutzt und nicht nur 2 Kerne.
Qualitativ wertvoller für youtube wäres wenn du auf 2048x1152 skalieren würdest via Spline100.
Für was brauchst du Tweak? Zumal du eh nix änderst damit gerad. Also warum dann erst ansprechen?
Qualitativ wertvoller wäres wenn du Vegas weglassen würdest. und würde auch weiter die encodespeed ansteigen.
Tweak? Keine Ahnung. Dann nehm ichs raus. Hab alles aus verschiedensten Tutorials (da die meisten viel zu veraltet sind) übernommen. Aber das mit dem MT macht Sinn. Was genau wird denn durch die [lexicon]Auflösung[/lexicon] beeinflusst? Wird dadurch die Datei nicht größer wenn ich auf einmal in 2048 resize?
Ich benutze kein Vegas, sondern Movie Studio den kleinen Bruder davon. Wenn ich das aber weglasse, wie bearbeite ich die Videos dann vor? Ich fürchte ich hab mich zu sehr an die Drag and Drop Timelines gewöhnt, in die man einfach alles reinziehen kann. Nochmal alles für [lexicon]MeGui[/lexicon] neu zu lernen wenn ich schon für Movie Studio Geld ausgegeben habe, erscheint mir unsinnig (das schaut irgendwie nicht benutzerfreundlich aus). Und wie gesagt ist mir der Encodespeed unwichtiger als die Dateigröße.
Stimmt bloß nicht.
Na gut. Aber eine Begrüdung wäre schon nett, da ich aus einem simplen Nein nichts lernen kann.
Danke für die Antwort jedenfalls.
Na gut. Aber eine Begrüdung wäre schon nett, da ich aus einem simplen Nein nichts lernen kann.
Dadurch das die Unterschiede der Frames geringer ist kann der [lexicon]Encoder[/lexicon] besser arbeiten.
Unterm Strich nimmt die Dateigröße von 30 auf 60 FPS um ca. 20-30% zu - mehr nicht. Weit entfernt von doppelt so groß bzw. explodierender Dateigröße.
Warum das so ist, hat GelberDrache ja schon erläutert. 
Ich hab jetzt die von Demon empfohlenen Umstellungen gemacht, aber jetzt ist die erwartete Dateigröße noch mehr als vorher. Und länger dauert es auch.
Ein einzelnes Video in einer Serie für 3 Stunden zu [lexicon]encodieren[/lexicon] und für 2 Stunden hochzuladen ist irgendwie nicht wirtschaftlich in meinen Augen.
Ich werde mal weiter mit [lexicon]SSM[/lexicon] herumprobieren.
Na gut. Aber eine Begrüdung wäre schon nett, da ich aus einem simplen Nein nichts lernen kann.
Danke für die Antwort jedenfalls.
Doppelte Framerate ist nicht gleich doppelte Dateigröße. Das ist Quatsch. Das stimmt nur bei Unkomprimierten Videos.
Aber alle Codecs die ihr nutzt, sei es zum Aufnehmen oder zum späteren [lexicon]Encodieren[/lexicon] wie mit [lexicon]x264[/lexicon] z.B. sind alle Kompressionsverfahren.
Bedeutet im Klartext mit dem Beipspiel 30 FPS vs 60 FPS:
Bei 30 FPS ist jeder [lexicon]Frame[/lexicon] genau 1/30 sek lang.
Bei 60 FPS genau 1/60 sek.
Komprimiert werden kann alles was z.B. identisch ist. Auch wenn sich Farbpixel zum nächsten [lexicon]Frame[/lexicon] gleichen, kann gespart werden.
Bedeutet das du bei einem Video gewiss Frames hast die über längere Zeiten von 1/60 oder 1/30 hinaus gehen. Und diese Bilder sind dann identisch. Da wo nix passiert großartig.
Daher wird bei der doppelten Menge an Frames bei Spiele die sowieso nur 120 FPS schaffen ungefähr 20% die Aufnahmedatei größer werden.
Man kann es nicht genau abschätzen. Es ist jedenfalls die Hälfte von der Hälfte was es anwachsen tut oft.
Bei Unkomprimierten Codecs würde sich das exakt um 50% steigern, aber gewiss nicht bei komprimierten Codecs.
Tweak? Keine Ahnung. Dann nehm ichs raus.
Tweak ist nur da, wenn du z.B. das Bild sättigen willst oder Helligkeit anpassen etc. Sprich mit den Farben etwas rumspielen willst. Wenn du es Original wie möglich haben willst, sollte es raus.
Wird dadurch die Datei nicht größer wenn ich auf einmal in 2048 resize?
Er meinte eigentlich das du deine Videos statt 1920x1080 lieber in 2048x1152 [lexicon]hochskalieren[/lexicon] sollst. Sprich 1080p zu 1152p im Verhältnis 16:9.
Das ist ein Sprung von 72p aufwärts.
Damit erreichst du das Youtube später dir mehr [lexicon]Bitrate[/lexicon] für das Video gibt und es damit dann auf Youtube qualitativ besser aussieht.
Die Dateigröße steigt bei so einen geringen Auflösungsanstieg nur gering an. Diese 72p mehr ist doch ein Witz. Die kannste ruhig nutzen um mehr Quali auf YT zu bekommen.
Und wie gesagt ist mir der Encodespeed unwichtiger als die Dateigröße.
Wenn du auf bestimmte Dateigrößen aus bist, dann darfste bei Qualität nicht viel erwarten.
Der [lexicon]CRF[/lexicon] Encode ist ein 1pass Encode der auf gleichbleibende Qualität der Frames basiert und mittels eines Faktors bestimmt werden kann.
Da aber jeder [lexicon]Frame[/lexicon] in einem Video unterschielich Komplex aufgebaut ist, ist kein [lexicon]Frame[/lexicon] immer gleich groß, sondern variiert. Somit lässt sich bei [lexicon]CRF[/lexicon] keine Fixe Dateigröße nennen bei Faktor x. Sprich, keiner wird es Vorhersagen können. Höstens vermuten oder gut Schätzen.
Bei einem 2pass Encode wo man via Bitraten encodiert kann man die Bitratenangaben nutzen um auf eine bestimmte Dateigröße zu kommen. Dies kann man dann auch ausrechnen für das jeweilige Video.
Ein 10Bit Encode spart auch wieder Dateigröße und kann zudem auch [lexicon]Banding[/lexicon] vermeiden im Video.
Wenn dich mehr solch theoretischer Kram interessiert, brauchste nur fragen. Werden dir gewiss einige was zu sagen können, da sie sich auch mit dieser Materie beschäftigen und nicht nur spielen ;D
aber jetzt ist die erwartete Dateigröße noch mehr als vorher
Wie schon gesagt: Um bei komplexen Videos an Dateigröße zu sparen, kannst du den [lexicon]CRF[/lexicon] bremsen. Oder du steigst auf 2pass Encode um.
Danke auch dir für die Erklärungen!
Ich hab jetzt die Skalierung auf 2048x1152 mit Spline100 gestellt.
Irgendwie fällt es mir schwer eine goldene Mitte zu finden. Das Spiel zeigt jede Menge Schriften (teilweise recht klein) auf dem Bildschirm, die auch sehr schnell wegen der Qualität verwischen und damit für den Zuschauer nicht mehr erkennbar oder unangenehm zu lesen sind.
Darum würde ich gern ein möglichst scharfes Bild liefern, aber gleichzeitig keine 5 Stunden für ein Video brauchen. 2 Stunden für die Videobearbeitung wären schon wieder ok, aber nicht 3 und nicht eine Größe, die nochmal soviel für den Upload braucht.
Muss ich selber wohl noch etwas herumwerkeln. Falls sich neue Probleme auftun, meld ich mich wieder!
Edit: Wie aussagekräftig sind eigentlich projected filesize + time remaining? Das hüpft bei mir immer wieder herum, sodass ich nicht weiß was am Ende für eine Größe rauskommt.
Darum würde ich gern ein möglichst scharfes Bild liefern, aber gleichzeitig keine 5 Stunden für ein Video brauchen.
Wie aussagekräftig sind eigentlich projected filesize + time remaining? Das hüpft bei mir immer wieder herum, sodass ich nicht weiß was am Ende für eine Größe rauskommt.
Das wiederspricht sich mit dem ersten Satz im ersten Zitat. Du willst ein Scharfes Bild, willst aber die [lexicon]Bitrate[/lexicon] manuell bestimmen um auf Dateigröße XY zu kommen. Die [lexicon]Bitrate[/lexicon] ist das Qualitätsangabe kann man sagen. Zu wenig und das Video wird zu Matsch oder bekommt massig Blöcke.
Du sagst du hast im Spiel kleine Schriften.
Optimal wäre es dann gewesen mit RGB oder YV24 aufzunehmen, da dort in der Aufnahme die Farben nicht verlaufen. Danach hätte man auch die Skalierung optimal für sowas nutzen können. Weil dann haste in Nachskalierungen in größeren Auflösungen bessere schärfere Schriftzüge und mit einem [lexicon]CRF[/lexicon] zwischen 18 bis 25 später für YT wenn du das Video hochladen tust keine verschmierte Schriften.
Encoding würde nicht lange dauern + Dateigröße könnte besser komprimiert werden, da es von einer RGB Quelle kommt.
Bei YV12 Aufnahmen ist z.B. die Farbqualität um 50% geringer. Daher zerlaufen Pixelbreite Schriften gerne bei solchen Videos. Schlecht ist wenn sie schon so aufgenommen wurden.
Bei YV12 hast du schon eine unreine Quelle und somit auch schon Defizite drin, die wie ein Rauschen wirken.
Optimal wäre es dann gewesen mit RGB oder YV24 aufzunehmen, da dort in der Aufnahme die Farben nicht verlaufen. Danach hätte man auch die Skalierung optimal für sowas nutzen können. Weil dann haste in Nachskalierungen in größeren Auflösungen bessere schärfere Schriftzüge und mit einem [lexicon]CRF[/lexicon] zwischen 18 bis 25 später für YT wenn du das Video hochladen tust keine verschmierte Schriften.
Aha! Gut zu wissen. [lexicon]Fraps[/lexicon] hat eine Einstellung "Force [lexicon]Lossless[/lexicon] RGB Capture". Wäre das damit zu erreichen?
Ja wäre es.
[lexicon]Fraps[/lexicon] ist nur ein schlechtes Programm für die Aufnahme.
Da wäre [lexicon]MSI Afterburner[/lexicon] besser geeignet mit [lexicon]MagicYUV[/lexicon].
Ja wäre es.
[lexicon]Fraps[/lexicon] ist nur ein schlechtes Programm für die Aufnahme.
Da wäre [lexicon]MSI Afterburner[/lexicon] besser geeignet mit [lexicon]MagicYUV[/lexicon].
Moment, Moment. [lexicon]Afterburner[/lexicon] sagt mir was aber was ist [lexicon]MagicYUV[/lexicon]? Ist jetzt [lexicon]x264[/lexicon] als [lexicon]Codec[/lexicon] nicht mehr empfohlen? Das ging mir etwas zu schnell.
@Demon:
Ok ich probiers mal aus. Gibts für [lexicon]Avisynth[/lexicon] ein halbwegs verständliches Video Tutorial? Das sieht ziemlich komplex aus.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!