Manche Levels mussten massiv verkleinert werden, um dem Massenmarkt gerecht zu werden.
Wasn scheiß die Levels wurden gekürzt? ![]()
Warum denn sowas -.-
Gibts die auch in voller Länge irgendwo?
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 erstellenManche Levels mussten massiv verkleinert werden, um dem Massenmarkt gerecht zu werden.
Wasn scheiß die Levels wurden gekürzt? ![]()
Warum denn sowas -.-
Gibts die auch in voller Länge irgendwo?
Einfach im AVS Script Creator unterm Tabreiter "Filters".
Dort stellst du bei Source Type auf interlaced. Stellst die richtige Feldreihenfolge ein (Field order) (Falls du diese nicht weißt: Kannste mit [lexicon]Mediainfo[/lexicon] ermitteln, oder Analyse Button. [lexicon]Mediainfo[/lexicon] dürfte aber sicherer sein)
Dann Deinterlace anhaken und den Yadif wählen.
Falls du meine Presets benutzt, wähle zuerst mein Preset und hinterher das mitm Deinterlace. Sonst ist das Deinterlace evtl wieder weg wegen dem Preset.
Ja habe ich bekommen. Aber nicht mehr dran gedacht. Sorry.
Aber gut das du es hier schreibst, weil Konsolen ist jetzt nicht so mein Gebiet. Vllt kann jemand anders helfen.
Ansonsten, denke ich bleibt die Differenz eher klein.
Also bei Descent und Doom wird da auch eine nicht unauffällig größere Differenz sein. Erstrecht mit höherem Preset als Medium. Wenn du mehr als 3 b-frames erlaubst wird die Differenz noch größer ausfallen.
Sind Menüphasen dabei wird es noch größer ausfallen.
Es bleibt einfach nicht aus, das unnötig Mbytes aufgebläht werden. Mal mehr mal weniger.
ZitatNaja es ist nicht der Falsche weg, wenn man nachehr splitten möchte.
Das splitten nachher, ist natürlich suboptimal, was aber im Leitfaden auch gesagt wurde.
Wenn man splitten möchte und das framegenau sein soll, definiert man die Schnitte halt VORHER und machts nicht nachträglich..
eben weil es so suboptimal ist, wenn es auf framegenauigkeit ankommt.
Ich jedenfalls werde nie und nimmer empfehlen den Max GOP von 250 zu senken. Da gibts einfach bessere Wege.
Bei 1,2GB Quellmaterial, waren es bei mir 15 MB unterschied...
Glück gehabt. Bei besser komprimierbarem Material kann das ganz anders aussehen, dazu musses nicht gleich 'nen Point&Click sein.
Es ist jedenfalls der falsche Weg. Du nimmst unnötigerweise vorhandenes Kompressionspotential weg..
Und da braucht da nur 'nen Menü zwischen zu sein und schon machste die Datei größer als nötig.
Der Standardwert der Max GOP Länge von 250 sollte nicht tiefer gesetzt werden. Du bezahlst damit sonst zu sehr mit Dateigröße weil du dem Encoder einfach wenig Raum zum komprimieren gibst.
Vollgespeicherte Frames sind immer die größten Speicherverbraucher im Gegensatz zu b-frames und p-frames. Was ja auch irgendwo klar ist.
In [lexicon]TMPGEnc[/lexicon] mehrere Encodingjobs machen oder mehrere Avisynth Scripte anlegen mit dem Trim Filter und dann die Scripte in [lexicon]TMPGEnc[/lexicon] öffnen.
Eine GUI für Avisynth hättste sonst auch hier, wenn du nicht per Hand willst: http://www.avisynth.org/qwerpoi/AvsP_v2.0.2.zip Der hat dann auch eine GUI für den Trim Filter dabei.
[lexicon]MeGUI[/lexicon] -> Tools - AVS Cutter.
Serra meinte hier sicherlich eher [lexicon]MKVMergeGUI[/lexicon] und nicht den AVS Cutter.. Ansonsten isses natürlich falsch.
ZitatGuck einfach mal bei diesem Video. Ich bewege mein Mauszeiger und als ich ihn nicht mehr bewege, kommt daneben der Ladebalken. Dann bewege ich ihn nicht mehr und der Ladebalken bleibt da, in Echt war er aber nur ganz kurz da..
Das ist deine einzige Sorge?
Die möcht ich auch haben xD
Wo ist das jetzt schlimm?^^
Das sollte dann aber im Leitfaden überarbeitet werden.
Da sollte man dann echt lieber den AVS Cutter nehmen, statt son schrott wie Max GOP 30 einzustellen.
Wenn [lexicon]x264[/lexicon] aufgezwungen wird jeden 30. frame als vollen Frame zu speichern, dann kann [lexicon]x264[/lexicon] ja kaum sein geniales Kompressionspotential ausschöpfen..
ZitatIn einem Video ist der 1. Frame ein Lademauszeiger, den bewege ich erst nach xy Frames und erst nach 5 Sekunden, als ich die Maus bewege, geht der Ladekreis neben dem Mauszeiger weg. Hat das was mit 0 GOP zu tun?
Irgendwie schiebst du jedem erdenklichem Problem dem Max GOP in die Schuhe. Kann das sein?^^ Warum eig?^^
Irgendwie versteh ich aber auch dein Problem gerad nicht. Schreib mal mehr ins Detail.
ZitatMein Vorschlag wäre, dass du gleich in [lexicon]MeGUI[/lexicon] wirklich framegenau schneidest (walum geht das nicht?)
Geht doch.
Max GOP ist auf 30 gestellt
Auf 30? Warum stellste so ein suboptimalen Wert ein?
Wenn du dem Encoder aufzwingst jeden 30. Frame einen vollen Frame zu schreiben, tötest du ja jegliches Kompressionspotential weg..
Max GOP 0 heißt unendlich langer GOP. Verwechselt eine "Infinite" Einstellung nicht.
Wenn du nicht auf 0 fahren willst wegen Spulbarkeit oder sowas, dann nimm den Standardwert von 250, oder nimm 500 oder so. Aber auf keinen Fall niedriger als 250.
144 ist schon ziemlich schnell.
Damit kannste in 2048x1152 Auflösung aufnehmen ![]()
Ein gelbes Dreieck bedeutet eine Warnung im Log, ein rotes icon mit weißem X bedeutet das ein Fehler im Log gelistet ist.
Vllt haste Max GOP 0 gemacht, dann stellt [lexicon]MeGUI[/lexicon] den Min GOP auf 1 und das wird dann in der Log gelistet diese Änderung.
Und welche?
@ExplodingCore Kann dir dann leider gerad nicht helfen wegen dem Ton.
Aha.
Also brauchste doch gar nicht doppelt encodieren ![]()
Frameserver benutzen.
http://www.debugmode.com/frameserver/
Installieren für Adobe Premiere Pro
Als Exportformat nimmste nun [lexicon]Debugmode Frameserver[/lexicon], statt AVI.
Bei dem nun nachm Speichern der Signpost AVI aufkommenden Fenster wählst du YUY2 aus und klickst next
Nun läuft der Frameserver. Nun kannst du die gespeicherte Signpost AVI des Frameservers mit [lexicon]MeGUI[/lexicon] verwenden ![]()
Prinzip des Frameservers ist halt, das Premiere ganz normal denkt das wäre ein Encoder und schickt dementsprechend seine Frames zu ihm hin. Aber statt zu encodieren, tut der Frameserver die Frames weiterleiten wenn ein anderes Programm (MeGUI) die Datei anfordert.
Eig. schon, Samplerate 44.1Khz und 16 Bit...
Und dein Quellmaterial ist auch in 44.1 khz, 16bit? Und Codec des Quellaudios ist [lexicon]PCM[/lexicon] WAV?
ich splitte ja nicht nur ich bearbeite auch noch anders (musik drunter legen Ein- und Ausblendeffekte usw) ... also das is schon so gewünscht
Mit welchem Programm machst du dies? Das frag ich nicht ohne Grund ![]()
PS: Avisynth würde sowas auch alles können, aber das würde ein wenig Scripting Skill mit Avisynth erfordern ![]()
Wobei Fading Effekte nun einfach zu realisieren sind
(bzw ist eig. ziemlich viel relativ einfach zu machen.
Aber das nur als Randanmerkung ![]()
Projekteinstellungen in Vegas entsprechen zu 100% dem Quellmaterial? Dazu gehört auch Audio. (zu nennen wäre u.a. Samplerate, Bittiefe)
Wenn das nicht hilft, hake beim Frameserver an, das er [lexicon]PCM[/lexicon] Samples in die Signpost AVI schreiben soll.
De-M-oN
ja mit dem AAC Nero Codec wollte ich mich an youtube vorgaben halten, habe aber die beiden Videos auch mit den Vorbis und dir genannten Einstellungen gemacht.
Allerdings gibt Youtube vor bei HD mono wie stereo 384Kbit/s. Mit dem Vorbis bei 8.0 habe ich 256kbit/s bei einer sampling Rate von 44.1 KHz und lt. Media Info ist Kompression = lossy (also Verlustfrei?)
Muss mal schauen wie ich das hinbekomme, den youtube verlangt 96KHz bzw. 48KHz bei aac, aber ich kann nur bis maximal 48 auswählen :-/
Halte dich nicht an dieser Liste. Die ist der absolute Bullshit. Da frag ich mich schon ein wenig, wen sie da beauftragt hatten diese zu verfassen ![]()
Wenn du mehr Qualität als 256 kbit willst, mach den Q Faktor höher als 8. 9 entspräche 320 kbit, 10 entspricht 500 kbit/s. Mach die Bitrate dir so, wie sie dir Dateigrößenmäßig noch in Ordnung geht.
lossy heißt verlustbehaftet. Lossless wäre verlustfrei.
Youtube encodiert ebenfalls in 44.1 khz Ton.
Würdest du eine andere Samplerate benutzen, würde sie Youtube also auf 44.1 runterkonvertieren. Die Umrechnung ist nicht verlustfrei. Totaler Bullshit das Youtube hier so ein Schwachfug da hinschreibt.
Bleibe von Aufnahme bis Endencode bei 44.1 khz, 16bit.
______
Das andere Video hat schwarze Ränder trotz 1280x720 - und allgemein ist das Videomaterial besser komprimierbar als ingame Action wohlmöglich noch mit bewegendem Gras etc.
Youtube benutzt kein [lexicon]CRF[/lexicon], sonst wäre die Qualität auf jedem Frame identisch. Youtube benutzt jeweils einen FESTEN Quantizer Wert pro Encoding. Und dadurch ist aufwändiges Material schlechter aussehend, als ein Tutorial.
ZitatDas mit der schlechteren Qualität ist sogar größer geworden..
Vermutlich weil du nun sichtbare Makroblöcke im Bild hast, die nun für Bestandteil des Bildes gehalten werden und daher für den Encoder als "Detail" gehalten werden (kann der Encoder ja hinterher nicht wissen, die Makroblöcke sind ja nun Bestandteil des Videos)
Achtet nicht auf die Dateigrößen sondern was sich innerhalb abspielt.
Es sollte klar sein, das mehr Qualität bei einem Re-encode über bleibt, wenn man auch besseres Material hochlädt.
Wenn AAC, dann den Nero AAC. F-AAC ist nicht so dolle.
Ansonsten nimm eher [lexicon]OGG[/lexicon] Vorbis.
Auch bei Audio isses natürlich von Vorteil so hohe Qualität wie möglich hochzuladen. Am besten sogar verlustfrei. Nur im verlustfreien Format ist das Audio dann manchen Leuten zu groß mit schwächerem Internet.
Aber eine [lexicon]OGG[/lexicon] Vorbis mit Q 8.0 oder höher hätte schon was ![]()
Auf jeden Fall immer drauf achten das in der Audio Config der Normalize Peaks Haken nicht drin ist.