Beiträge von De-M-oN

Den ENcoder kriegste ganz sicher nicht von Beepa als VfW Codec installiert ;D

Nein mit einem DEcoder kannste schlecht aufnehmen

Versuchs doch mal. Wird schön nicht funktionieren. u.U. sogar crashen.

Außerdem warum willst du unbedingt mit dem Fraps Codec aufnehmen?

Der DXTory Codec ist da besser. Zumal der keine eigenen YUV Koeffizienten verwendet, was ebenfalls schon an Fraps nicht optimal ist.

Ist das Quellmaterial synchron?
Welchen Videoplayer verwendest du?

Queue brauchste nicht

Reicht Add, die FLV öffnen, Save as für speicherort und dann mux drücken.

Was für ein Error kommt denn?

Neu Encodieren kostet viel Zeit und killt Qualität.

Ummuxen ist sehr viel sinniger. Mache es lieber direkt jetzt schon mit MP4Box.

Zitat

Mein Fazit:
Bin ein bisschen enttäuscht von x264, MainConcept AAC scheint ziemlich nah an den x264 ran zu kommen, nicht das ich x264 jetzt schlecht finde, aber hatte einfach mehr erwartet.

Es ist auch bei weitem besser.

Zitat

MainConcept AAC scheint ziemlich nah an den x264 ran zu kommen

Nö. Hat ja auch nicht mal einen qualitätsbasierten Encodiermodus. Allein das macht ihn schon ineffizient.

Abgesehen davon fehlen deine Vegas settings noch immer und b) sind deine Testvideos viel zu kurz.

Downloade MeGUI mal neu und probier es nochmal.

Du kannst einen seperaten Ordner benutzen, falls du deine jetzigen MeGUI Einstellungen noch nicht verlieren willst nur wegen dem Test.

Die Settings von MeGUI speichert sich MeGUI bei sich selbst in dem Ordner. Das heißt du kannst ohne Probleme so viele MeGUIs wie du willst aufm PC haben.

Nicht in AVI muxen, da hat H.264 Video eh nichts drin verloren. (Ich vermute mal stark das es sich um ein H.264 Video handelt).

Lieber in einen MP4 Container ummuxen

http://my-mp4box-gui.zymichost.com/download.html

Achja: CRF 20 ist im Übrigen ein sehr enormer Qualitätsanspruch. Da musste dich über größere Dateien nicht wundern

Genauso wenig musste dich bei komplexen Encodiereinstellungen nicht über Zeiten wundern. Die anfallende Komplexität des Encodiervorgangs auf höheren Presets ist natürlich entsprechend enorm.^^

Einen der deiner Dateigrößensache eher nicht entgegenkommen wird

CRF 19.
Damit erhältste recht große Dateien. Aber ich hab auch kein schwaches Internet ^^.
Habs übersehen das es nur Zitat war, weil du es nicht als Zitat gepostet hast^^

Probiers mit CRF 23 oder sowas, wenns dir um Dateigröße geht.

Bei MeGUI ist das in der x264 Config der Quality Wert.

Und ein preset höher als Slow lohnt sich in den allermeisten Fällen nicht. Zumindest nicht mit dem schwer komprimierbarem Material wie wir es hier haben mit Spielen.

Zum Player:

MPC-HC + Haali Renderer

Nach Installation von Haali in den Optionen von MPC-HC. Dort dann nach Ausgabe gehen und den Renderer auf Haali Renderer anpunkten. Unter Formate kannste dann noch die ganzen Dateitypen mit MPC-HC verknüpfen.

Die niedrige Auslastung zeigt ja schon wie ineffizient MainConcept encodiert

Die Qualität ist von den Einstellungen abhängig. Und solang du da nix zu sagst ... Weder den CRF Wert, noch deine Vegas Einstellungen sagste ^^.
Außerdem ... VLC ...

MP4 ist kein Codec.

Du meinst vermutlich H.264 oder auch AVC genannt.

Vegas benutzt den MainConcept als H.264 Encoder.
x264 ist ein anderer H.264 Encoder. Wie du siehst geht es in den gleichen Codec: H.264.

Hier mal mainconcept vs x264:

Die Grafik ist grob. Je besser komprimierbarer das Material wird, desto größer wird die Differenz zu MainConcept. Allein schon durch dem CRF Encodiermodus ist die Differenz deutlich höher als hier noch zu sehen.

Und ja unterschiedliches Videomaterial kann durchaus eine Differenz von 50% und sogar mehr aus machen.

CRF = Constant Rate Factor.

Du legst statt eine Bitrate eine Qualität fest.
Und diese Qualität wird dann für jeden Frame eingehalten und es wird nur exakt so viel Bitrate je Frame verwendet wie für diesen auch nur Notwendig ist für deine gewählte Qualität & Encodingsettings.
Komplexeres Material (schwer komprimierbares) wird dann natürlich entsprechend größer, als inkomplexes (gut komprimierbares).

Und welchen CRF Faktor du bei x264 benutzt wäre halt auch mal interessant.

Zitat

habe den vlc palyer benutzt.

Das ist schonmal ein weiterer Fehler.
Langsame Decoder und der Renderer stellt den YUV Farbraum falsch dar.

Du musst Dateigrößen schon mit absolut identischem Video vergleichen. Sonst ist das absolut nichtig.

Welchen CRF bei x264?
Nicht den VLC Player benutzt? Das ist eine ernstgemeinte Frage^^

Zitat von Serra

ich glaube bei Vegas, steht der Frameserver immer auf 0%.

Definitiv nicht

Zitat

Bis jetzt rechnet er, dass ich insgesamt 40min renderzeit für die 2min clip brauchen werde, da kann doch was nicht stimmen

Encodierst du direkt mit MeGUI oder per Videoschnittprogramm + Frameserver?

Wenn letzteres klingt das nach Projekteinstellungen die nicht dem Quellmaterial zutreffen.

Zitat von Roger

EDIT: Sooo. Den nächsten Part mit Demons "slow-Preset" gerendert. Und immerhin 200Mb weniger Und es hat nur 40 Minuten länger gedauert. Sind mehr als 5 bframes noch zu empfehlen oder geht das zu stark auf die Qualität? (Natürlich wird es auch länger rendern, denke ich mal )

Qualität wird rein nur vom CRF Faktor bestimmt (bei TMPGEnc halt der % Wert bei Quality).

Der Encoder kann meist nicht mehr als 5 b-frames nutzen. Animes kann man noch 8 machen. Animes lassen sich besser b-frames einsetzen.
Aber Spielmaterial ist eh nicht so wirklich welches, was man als gut komprimierbar bezeichnen würde. Insbesondere solch Teile wie BF3 und co. Die sind ziemlich beschissen komprimierbar.

Die Einstellung bestimmt wieviel b-frames maximal hintereinander seien dürfen. Es ist kein Aufzwang immer 5 zu benutzen. Das muss schon der Encoder entscheiden ob das überhaupt geht.

Zitat von Serra

Der Frameserver, bleibt die ganze zeit bei 0%
Die anzeige in vegas will nicht so recht.

Bevor kein Programm die Daten vom Frameserver anfordert, findet logischerweise auch kein Fortschritt statt.
Der Frameserver encodiert ja nicht (was Vegas ja natürlich denkt). Der Frameserver sendet die von Vegas an ihm geschickten Frames an das Programm weiter, welches die Daten anfordert (MeGUI bzw x264).
__

Inkomplexe Stellen encodieren schneller (Menüs etc), komplexe Stellen langsamer.

Komplexe Stellen sind schlechter komprimierbar und brauchen somit mehr Datenrate um die von dir geforderte Qualität der Frames beizubehalten. Mit CRF hat jeder Frame eine möglichst identische Qualität.

b-frames enthalten nur Änderungsinformationen zu vorigen und nachfolgenden Frames. b-frames können sich auf i-frames (voll Frames), p-frames, und bei H.264 sogar auf andere b-frames referenzieren.

b-frames und p-frames sind natürlich sehr wichtig für die Kompression. Warum ein volles Frames speichern, wenn sich aufm nächsten Frame nichts großartig ändert^^

Hier auch eine Demo bezüglich b-frames.

Zur Verständnis hilft es die Videobeschreibung zu lesen.

http://www.youtube.com/watch?v=CV_8rR9LxGU

Kurzum : Mehr b-frames erlauben = besser.

Benutzt du aber auch Adaptive b-Frames ist ein höherer b-frame maximum langsamer. Sonst könnte man auch max 16 b-frames eintragen und es wäre nicht langsamer. Aber Adaptive b-frames sollte definitiv nicht deaktiviert werden.

Zitat von moe

Mit MeGui kannst du aber einen besseren Resize-Filter nutzen.

Alternativ ein Avisynth Script für das Video mit dem Lanczos4Resize erstellen und das AVS Script dann mit TMPGEnc öffnen.

Zitat

Ich nehme auch mit 1080p auf und rendere auch mit der Auflösung. Das Hochskalieren braucht mir
dann zu lange

Könntest ja auchn schnelleren Resizefilter benutzen. LanczosResize(2048,1152) ist schneller, ober BicubicResize(2048,1152,0,0.75) ist noch schneller. Skalierungsqualität natürlich weniger als Lanczos4Resize(2048,1152).

Und nicht so viel Angst vorm Resizen.

Wenn ihr ein Video in 720p guckt und habt zb einen 1920x1080 Monitor und guckt dann in Vollbild. Was meint ihr was dann passiert? Richtig. Auch eine Skalierung. Wie sonst wollt ihr Vollbild haben? Und da isses dann nicht gerade mit Lanczos4 skaliert (wobei sowas per Avisynth auch möglich wäre. Aber Lanczos4 Skalierung auf Echtzeit ist CPU intensiv. Könnte unflüssig laufen.^^

Wegen Encodierzeit:

Probiers ohne P4x4 Partitionen. Einfach bei P4x4 den Haken raus. Das dann mehrere Haken verschwinden ist normal.
b-frames auf 3 statt 5.

Sollte dann etwas schneller gehen.

Zitat

Neues Update wäre mal toll weil sich MeGui doch extrem weiterentwickelt hat, muss ja kein Video sein, Bilder reichen ja

Ja eventuell mal.

So viel anders ist aber eig. nicht. Statt DirectShowSource wählste halt nun AVISource. (ist ja noch immer der 3. button).
Aber man könnte das Tutorial vllt mal kürzer machen und jetzt hab ich ja win 7. Das Theme was ich in XP hatte macht der Farbraum YUV (@YV12) zu viel Verlust, weshalb manche wohl leider nicht so gut die Schriften lesen können. Empfehle auf jeden Fall das Video in Original zu schauen).

Zitat

Und wie ist das mit den FPS? Meine Hauppauge nimmt mit Double NTSC auf also 59,9, ich habe das bisher in Vegas immer so gelassen

Was auch richtig ist. Die Projekteinstellungen müssen in Vegas zu 100% dem Quellmaterial gleichen in jeder Hinsicht.

Zitat

und das Endprodukt ebenfalls mit 59,9 gerendet.

Das jedoch ist total unnötig.

Ich denke auch mal das dein Quellmaterial demnach Interlaced ist.
Ich würde da nicht einen der Deinterlace Filter von Vegas nehmen, sondern eher yadif. Sprich in den Projekteinstellungen den Deinterlace Filter auf "kein"

Und bei MeGUI im AVS Script Creator dann:

Hier auf Analyse klicken, danach deinterlace anhaken und yadif wählen. (Achte drauf das der auch Interlaced erkannt hat. Wenn nicht solltest du bei Vegas die Projekteinstellungen überprüfen ob du Interlaced eingestellt hast. Außerdem isses wichtig, das du weißt ob es obere Feldreihenfolge oder untere Feldreihenfolge ist. Das muss ebenfalls in Vegas korrekt gewählt sein).
Wenn du das nicht weißt, prüfe das alles mal mit > Mediainfo. < Quelldatei damit öffnen und ansicht auf text stellen und dann mal schauen.

Zitat

bei Very Slow und Placebo wird das fertige Video auch immer asynchron, das selbe Material auf Slow und höher aber nicht, wieso? Lösungen?

Mehr als Slow macht in den meisten Fällen kaum Kompressionsgewinn. Höher als Slow bringt noch nennenswert etwas, wenn du sehr gut komprimierbares Material hast, was Spiele in den meisten Fällen eher nicht sind.
Und Very Slow und erstrecht Placebo machen eig. nie Sinn Die Encodierzeit ist dann ENORM und der Dateigrößengewinn marginal. Kann man nehmen wenns echt aufs letzte Mbyte ankommt oder wenn man bitratenfixiert encodiert und man das absolute maximum rausholen will.
_

Wenn du komplexer komprimierst, isses natürlich auch für den Decoder höherer Aufwand das ganze zu decodieren. Die Asynchronität erhältst du bei den Presets also daher, das dein Decoder zu langsam decodiert (Zusammenspiel aus Effizienz des Decoders und CPU Leistung).
Du könntest dir FFDShow installieren, dann haste einen Mehrkernfähigen H.264 Decoder.
Und bitte kein VLC verwenden. Der ist sowieso nicht der beste mit Decodern und Renderqualität.

Aber ich rate die Nutzung von Placebo und very slow echt ab. Und eig. auch slower..
Du hast enorme Encodierzeit, die du lieber in besserer Qualität (uploadzeit) stecken kannst.

Zitat von _Fl4sHiii^

Naja ich hab nen Prozessor mit 4x2,6 GHz

Das sagt nix aus.

Meiner hat auch 2,66 Ghz , aber der encodiert schneller als deiner.
Zu 'nem Prozessor gehört bisschen mehr als nur die Ghz
Ergo wenn, dann auch das Modell sagen

Zitat

Außerdem hab ich nur ne 16000er Leitung. Ich brauch auch für ne 6Gb Upload gut und gerne 12 Stunden.

Und trotzdem willste CRF 18 fahren?

Respekt

Wenn du mal ein weniger schwerfällig komprimierbares Spiel hast, wirds aber schneller gehen.

Wobei 1,xx schon echt langsam ist. Vllt etwas betagte CPU?

Bei schwerfällig komprimierbarem Material kannstes auch mit Medium Preset versuchen. Geht deutlich schneller und bei schwerfällig komprimierbares Material bringt slow nicht unbedingt immer so viel, das es sich lohnt, außer man hat eben entsprechend langsames Internet wo jeder mbyte zählt.

hängt schwer vom Material ab, aber:

Wenn Doom 3 mit CRF 21 zwischen 900 und 1,1 GB wurde, wirds mit CRF 19 um die 1,5 bis 1,8 GB (Aber schon 30min Video oder so und 2048x1152. Doom 3 lässt sich aber auch recht gut komprimieren).

Das ist aber echt extrem GROB.^^

Das fällt immer komplett anders aus, da nunmal jedes Video anders ist.

Zitat von OverDev

Also niedriger als 21 würde ich echt nicht gehen.

Und warum nicht?

Wenn mans kann, wieso nicht?

Ich mache mit meiner Internetleitung auch CRF 19. Und ja das sieht besser aus als CRF 21. Man muss halt wissen wo man hinschauen muss

@_Fl4sHiii^:

Meinst du zufällig das Avisynth preset von mir?

Also zb "YT (2048x1152)" ?

Dann ja das ist das