Beiträge von De-M-oN

    Das kann ich mal machen. Ich hab heute früh zum [lexicon]Rendern[/lexicon] AVI -> benutzerdefiniert "ohne Komprimierung" aus Vegas rausgeholt (kamen 230GB raus)


    Und da wo momentan "ohne Komprimierung" steht, wählst du dann entsprechend den [lexicon]Lagarith[/lexicon] [lexicon]Codec[/lexicon]. Daneben sollte auch dann ein konfigurieren button sein. Da kannst du dann YV12 als Mode einstellen und MT anhaken.


    Vorteil: Dein Material wird nicht zu RGB24 konvertiert. Du hast nämlich sicherlich nicht in RGB aufgenommen. Und eine Konvertierung von YUV nach RGB ist nicht verlustfrei aufgrund von Rundungsfehlern.
    Außerdem geht die Speicherung von [lexicon]Lagarith[/lexicon] erheblich! schneller als unkomprimiert und die Dateigröße bewegt sich mehr im Rahmen deines Aufnahmematerials, als die 3 bis 4-fache größe.
    Denn auch aufnehmen tust du ja nicht unkomprimiert, sondern ebenfalls in verlustfreier Kompression. Sonst würde eine einzelne Platte das auch bei entsprechenden Auflösungen gar nicht stemmen können diese Datenmenge schnell genug zu schreiben.


    Ach da fällt mir ein: Kann [lexicon]Handbrake[/lexicon] überhaupt mittlerweile Lagarith??
    Vllt sonst mal erstmal nur eine kurze Testdatei nehmen. Bin da jetzt gar nicht sicher. Damals konnte [lexicon]Handbrake[/lexicon] mit [lexicon]Lagarith[/lexicon] nicht umgehen.

    Meins war auch nicht böse gemeint, aber es ist halt sehr blöd wenn alles von ihm abhängig ist und so kann man dann dir ja auch schlecht helfen.


    Was halt doch recht schade ist. [lexicon]MeGUI[/lexicon] würde halt noch bissl mehr rausholen.


    Aber ein guter Schritt wäres doch mal wenn du [lexicon]Lagarith[/lexicon] YV12 exportierst, so das schonmal die doppelte Verlustcodierung wegfällt.


    [lexicon]Lagarith[/lexicon] gibt es hier:


    http://lags.leetcode.net/codec.html


    Der ist dann bei AVI zur Auswahl. Ihn einstellen auf YV12 und MT anhaken.


    Sicherstellen das die Projekteinstellungen zu 100% dem Quellmaterial entsprechen. (Datei - Eigenschaften)


    Audio auf [lexicon]PCM[/lexicon] 44100hz, 16bit, Stereo.
    __


    Die 32bit Version von MPC-HC hat viel mehr [lexicon]Decoder[/lexicon] und auch bessere.


    http://sourceforge.net/project…0200ac1d1d1a&source=accel


    Und das [lexicon]VLC[/lexicon] die Farben falsch darstellt, ist schon wieder ein Thread zu da ^^


    ^meGUI vs AVC warum untersschiede?


    Daher würde ich den [lexicon]VLC[/lexicon] meiden und von nun an MPC-HC benutzen^^

    Aber, Aber, ich dachte [lexicon]Camtasia[/lexicon] ist dein Lieblingsprogramm?^^


    Das Programm ist totaler Müll, aber idiotensichere Bedienung hatts ja ^^ Darum nehmens wohl auch so viele.


    http://sourceforge.net/project…0200ac1d1d9c&source=accel


    Zitat

    Nutz als Player am besten MPC


    Den. ja.


    Nicht 64bit nehmen.


    Ist aber auch extrem blöd, das das alles von dem Kerl abhängig ist. Denn dann wird der für [lexicon]MeGUI[/lexicon] als auch MPC-HC 32bit Argumente haben wollen. Aber man erreicht ihn ja aus der Ferne nicht.
    Und wenn ihr alleine euch an [lexicon]MeGUI[/lexicon] ransetzt wird das nichts. Gibt zudem auch Dinge die man beachten sollte, die ihr gar nicht wissen könnt. Wie zb den [lexicon]SSM[/lexicon] für die Scripterstellung, oder das ResampleHQ besser resized etc. Multithreading usw.


    Wenn das alles so sehr davon abhängig ist, was der Typ will, dann kommt man mit der Hilfe schlecht weiter.

    Dann kannste dem ja mal sagen das [lexicon]MeGUI[/lexicon] keinerlei Installation braucht :P


    Aber wenn man sich nicht so toll mit den Sachen auskennt und gerade wenn er nicht weiß wie man mit Avisynth umgeht, wäre es wirklich ziemlich sinnvoll, wenn ich dir das Programm erkläre, statt er. Denn wenn man nicht weiß was man tut, kann man auch ziemlich viel Mist machen und dann seid ihr wieder nicht zufrieden. [lexicon]MeGUI[/lexicon] ist kein [lexicon]Camtasia[/lexicon]. Es wäre sinnvoll wenn ihr da Hilfe von mir erhalten würdet.


    Die Farbdarstellung mit [lexicon]VLC[/lexicon] ist inkorrekt. Solltet ihr den benutzen, ist das ebenfalls schonmal ein riesen Fehler.


    Außerdem ist [lexicon]Lagarith[/lexicon] etc nicht unkomprimiert, sondern verlustfrei komprimiert.


    Ihr solltet [lexicon]Lagarith[/lexicon] mit YV12 und [x] Multithreading eingestellt nehmen.


    Keine Konvertierung auf RGB ! Das so toll klingende unkomprimiert avi dauert ewig, nimmt das 3-fache an speicher als deine rohaufnahme und macht eine Farbraumkonvertierung auf RGB. Also sogar mit Verlust verbunden.
    Daher verlustfreie Kompression mit Farbraum YV12 benutzen.
    Wenn er das bereits schon nicht weiß zu beachten, dann kanns ja mit [lexicon]MeGUI[/lexicon] mit ihm 'nen abenteuer werden^^
    Daher wäre wirklich mein dringender Rat, das ich dir [lexicon]MeGUI[/lexicon] stattdessen erkläre^^

    Das ist so lang weil du auf Insane spielst und 300x übern Spawner Trigger fliegst :P


    Aber hast schon recht das es 'nen längeres Spiel ist.


    [lexicon]Doom[/lexicon] ist auch nicht das kürzeste, aber normale Spiellänge.
    [lexicon]Doom[/lexicon] geht auch gut von der Hand, da es ja ein normaler Shooter ist und kein Raumschiff

    Wenn du Vegas weglassen würdest, hättest du noch viel bessere Ergebnisse^^


    Dann frag halt mich, statt ihn. Zumal ich vermutlich eh mehr Ahnung davon habe als er. Oder ist er eingefleischter [lexicon]MeGUI[/lexicon] Nutzer?


    Am einfachsten wäre es über Skype, da mein Video Tutorial recht betagt ist und ich in kürze ein neues machen werde.


    Zitat

    De-M-oN: Kleine Frage ab Rande: Warum ist der [lexicon]x264[/lexicon] eigentlich in kommernzieller Software so wenig verbreitet? Gibt's da nen Grund?


    Je teurer die Software wird, desto schlechter der Encode. Premiere Pro kostet noch mehr und bietet noch weniger Einstellungen an.


    Wenn sie wenigstens mal die Einstellungen die mainconcept ebenso ermöglich anbieten würden, statt 3 Sachen, wäres ja auch schonmal besser.


    Während ein magix als [lexicon]NLE[/lexicon] bereits vollständige [lexicon]H.264[/lexicon] Konfig anbietet, schafft Premiere Pro nur noch 3 Einstellungen. Das ist echt traurig für die NLEs.

    Mach das mal. Es sieht bei annehmbarer Dateigröße einfach scheisse aus.


    Weil du mit Vegas codierst. [lexicon]Handbrake[/lexicon] zeigt dir nur so gerade auf wie schlecht die [lexicon]Encoder[/lexicon] der ganzen NLEs einfach sind ^^


    Vllt doch mal ein Umstieg auf [lexicon]MeGUI[/lexicon] wert? ;)


    Zitat

    Kann die Screens meinetwegen nochmal machen, wobei ich gerade nicht weiß, wo ich ein so großes Bild hochladen soll ohne dass es automatisch ge-resize-d wird.


    http://www.abload.de

    Die Qualität ändert sich bei gkeichbleibendem [lexicon]CRF[/lexicon] ja auch nicht :)


    Dennoch muss [lexicon]x264[/lexicon] wie gesagt gegen kompensieren gegen die ganzen schlechten Settings.


    Ungenauere Bewegungssuche etc führt alles zu ungenaueren Ergebnissen. Dann wird die Datei vllt kleiner, aber es wurde auch unsauberer gearbeitet.


    Daher ist für ein schnelles preset locker eine [lexicon]CRF[/lexicon] Stufe besser nötig, als bei slow um die gleiche Qualität zu erzielen.


    Etwas schnelleres als Medium sollte man für einen hochwertigen Encode nicht nehmen.


    Die Presets können von der Qualität her können am besten via bitratenmodus und niedriger [lexicon]Bitrate[/lexicon] verglichen werden.
    Ansonsten: Beim [lexicon]CRF[/lexicon] 30 oder so nehmen.

    Das ist kein Gerücht, das ist Fakt und auch von [lexicon]x264[/lexicon] Entwicklern bestätigt, das schnellere Presets schlechter für die Qualität sind und man bei nem schnellen Preset ein [lexicon]CRF[/lexicon] besser benötigt als bei slow.


    Zitat

    Ich starte eh bald ein paar technische Umfragen und da wird es einen direkten Vergleich (auf Youtube) zu allen Presets geben, ohne dass man vor der Abstimmung weiß, was was ist.


    Wozu? Um die Aussage von [lexicon]x264[/lexicon] Entwicklern und der technischen Logik in Frage zu stellen?


    Und wenn, dann solltest du schon hohe CRFs nehmen. Wenn du natürlich mit [lexicon]CRF[/lexicon] 15 ankommst, wird man wohl nich viel sehen.


    Man sollte alleine sich mal Gedanken drüber machen warum eine weniger intensiv codierte Datei trotzdem kleiner wird. Das sollte einem doch schon zu denken geben, das da wohl weniger Qualität dann drinsteckt. Das sagt einem schon die Logik.
    _
    Die Encodierzeit hängt vom Material ab. Wenn du das gleiche Material codiert hättest, wäre slow langsamer gewesen.

    Avisynth MT beim [lexicon]SSM[/lexicon] Setup mit installieren. Sonst kanns schlecht gehen. Und sicherstellen das [lexicon]MeGUI[/lexicon] nicht sein internes ding nimmt (Options -> settings und sicherstellen das kein haken bei internal avisynth drin ist)


    Shadowplay nimmt verlustkomprimiert auf und das mit dem arg ineffizienten [lexicon]CUDA[/lexicon]. Das solltest du überdenken und eher versuchen deine synchronisationsprobleme zu lösen. Mit Shadowplay wirst du nicht glücklich.

    Einfach mal überlegen was passieren würde, wenn du eine größere Dateigröße nicht erlauben würdest.


    zb bei 1080p ist max bitrate 4000 kbit. Egal ob du mit Spline16 oder Lanczos4 ankommst. Ergo bleibt weniger Qualität über. Mehr Schärfe = schlechtere Komprimierbarkeit. Ringingbildung = schlechtere Komprimierbarkeit.
    Mehr schärfe = Die Blöcke müssen feinere Übergänge haben, damit der Block nicht vom Auge erfasst wird. Bei schlechterer Komprimierbarkeit wächst die Blocksichtbarkeit an.
    Und Ringing wie gesagt, kannste die Vergleichsbilder nicht als Referenz nehmen, da müssten andere her.

    Ok habe das im [lexicon]SSM[/lexicon] auf Spline16 mit ResampleHQ gestellt und gesagt er soll ohne konvertierung YV12 ausgeben. Steht nun im Script unten wie du gesagt hast.


    Ne wenn du mit [lexicon]SSM[/lexicon] machst, dann musste Konvertierung zu YV12 machen, sonst setzt [lexicon]MeGUI[/lexicon] dir das ConvertToYV12() ein^^


    Das soll ja gerade nicht geschehen.


    [lexicon]SSM[/lexicon] benutzt nur dann ConvertToYV12() bei der YV12 Konvertierung wenn ResampleHQ entsprechend nicht genutzt wird.

    Ja aber Lanczos4 hat Ringing Probleme (was durch scharfe Skalierung entsteht). Und es ist besser wenn es etwas unschärfer ist. Schärfe verschlechtert die Komprimierbarkeit.
    Ringing ist ebenfalls eine Begünstigung für schlechtere Komprimierbarkeit.


    Dann bei ResampleHQ in jedem Fall mit dstcolorspace="YV12" und dafür eben ConvertToYV12() weglassen, weil das brauchts dann nicht mehr.