Beiträge von De-M-oN

Zitat von Kazu

Deswegen hatte ich nur zwei Einträge im DropDown Menü, habe nun [lexicon]CRF[/lexicon] eingestellt.

Targeting Quality war bereits [lexicon]CRF[/lexicon], ist ohne advanced bloß anders benannt. Vllt denkt sich Zathor ja das es für ein Laie dann verständlicher klingt.

Zitat

Das mit der [lexicon]Bitrate[/lexicon] ist mir durchaus bewusst, war nur zu faul um die Zeit zu investieren eine ordentliche Wichtung zwischen Minimum und Maximum zu finden.

Normalerweise gibt man bloß eine Schnittbitrate ein und um den Rest kümmert sich der [lexicon]Encoder[/lexicon]. Um dem dabei zu helfen -> 2pass, beim 1. Durchgang guckt er sich das material an, beim 2. Durchgang verteilt er die [lexicon]Bitrate[/lexicon] dann nach diesem Wissen gewichtet sinnvoll.

Zitat

Ich habe nur VBR 1 Pass eingestellt, da ich mit 2 Pass in der Vergangenheit Probleme hatte. Diese könnten aber durch meine neue Hardware behoben worden sein.

Welche Probleme im Detail? Normal sollte das funktionieren.

Zitat

Warum habe ich "One Click [lexicon]Encoder[/lexicon]" "File Indexer" und "AVI Source" aber kein "DirectShowSource"?

Weil das Tutorial von 2011 ist und ein neues kommt, sowie ich dazu komme. Dann wird das ganze auch über die SSM Software laufen (Für das Erstellen der Scripte und dem Audio Export zur Weiterbearbeitung)

AVISource ist eine Unterklasse des DirectShowsystems. DirectShow beinhaltet auch noch DirectShowSource, WAVSource usw.

Zitat

Ich habe es jetzt noch einmal mit "Slow" "[lexicon]CRF[/lexicon] 21" "[lexicon]GOP[/lexicon] 0" und "AQ-Strenght 1.25" enkodiert.

Logisch. Mit CRF21 forderst du ja auch mehr Qualität.

Eine höhere AQ-Strength begünstigt auch eine höhere Dateigröße.
Max [lexicon]GOP[/lexicon] infinite wurde dir nicht mitgeteilt, das lange [lexicon]GOP[/lexicon] Längen fürs Spulen nachteilig ist. Siehe Lexikon: -> [lexicon]GOP[/lexicon] <- Wem das egal ist - wie zb mir - der kann das nutzen und damit Speicherplatz sparen. Natürlich gilt das Spulen nur lokal. Youtube codiert ja eh neu und benutzt sehr sehr kurze [lexicon]GOP[/lexicon] Längen.

@Kazu: Lies bitte mal den Artikel zu [lexicon]CRF[/lexicon]. Klick auf -> [lexicon]CRF[/lexicon] <- Das kannste u.a. mit [lexicon]x264[/lexicon] benutzen.

Das ist bei weitem sinnvoller als ein bitratenfixierter Encode.

Das mitm Audio kannst ja mit 'nem Audioprogramm regeln.

Zitat

Danach schaue ich mir die Qualität, Dateigröße und Dauer der Enkodierung an.

Dateigröße gibst du doch aufgrund deines bitratenfixiertem Encode (10000 kbit / sekunde) doch schon vor. Brauchst nur ausrechnen.

Bei x264's [lexicon]CRF[/lexicon] hängts davon dann ab welche Qualität du verlangst und was für ein Material du hast und welche [lexicon]Auflösung[/lexicon] etc.

Zum bitratenfixiertem Encode bei deinem Premiere: Warum konstante Bitrate? Das ist total suboptimal. VBR benutzen wenn man schon bitratenfixiert codiert. VBR mit 2 Durchgängen (2pass).

Wenn du 10000 kbit Zielbitrate vorgibst, haste am Ende ebenfalls eine Datei mit 10000 kbit. Jedoch kann der [lexicon]Encoder[/lexicon] die dann nach Komplexität gewichtet verteilen. Wenn du zb am Anfang eine Menüphase / viel Dunkelheit, wenig Bewegung oder sowas hast - eben Inkomplexität, so würde VBR dann hier weit weniger als 10000 kbit vergeben, so ist dann Luft für die komplexeren Stellen des Videos, so kann er also dann bei den komplexen Stellen mitunter deutlich über 10000 kbit gehen, ohne deine geforderte Durchschnittsbitrate zu überschreiten, da ja am Anfang der Inkomplexität entsprechend weniger genommen wurde.

Daher ist CBR ziemlich suboptimal. Du solltest bei bitratefixed immer VBR mit 2 Pässen machen. Ganz wichtig wenn man bitratefixed macht. Und da Premiere ein max [lexicon]Bitrate[/lexicon] haben will -> tippe eine 9999999999999 oder so ein. Warum den Peak beschränken? Wichtig ist doch nicht der peak, sondern die Schnittbitrate

Zitat

Versuchs mal mit [lexicon]CRF[/lexicon] 21 und 'Faster', sowie Max [lexicon]GOP[/lexicon] auf 0 und aq-strength auf 1.25.

Faster? neee. Empfehlt bitte nicht sowas.

@Kazu: Bedenke das [lexicon]x264[/lexicon] bei weitem schöner codiert als Premiere. Und bitte nicht mit [lexicon]VLC[/lexicon] abspielen, falls du [lexicon]VLC[/lexicon] benutzt.

Preset slow kann durchaus länger dauern als der encode von mainconcept. Medium geht schneller.

3200x1800 für die besten Ergebnisse.

Für 1440p werden 2080x1170 benötigt, wie jemand mal getestet hatte.

Die besten Ergebnisse wie gesagt mit 3200x1800.

Trellis ja, 10bit nein. Youtube codierts in YV12 8bit.

Trellis verbessert die Qualität bei bitratefixed und mindert die Dateigröße bei quantizerbasiert (CRF / CQ)

Aber auch bei [lexicon]CRF[/lexicon] kommt es der Qualität zugute, wenn man bessere Settings nutzt. Also verkehrt ist das nie. Verlängert halt bloß die Codierzeit.

Also auf 2160 siehts so aus wie sie eben auf youtube aussehen.

Zitat

Wie genau bekomme ich das hin?

Mit SSM [ Text-Tutorial ] SagaraS Scriptmaker (GUI)

oder

Loadplugin("c:\Program Files (x86)\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("video.avi", threads=1)

[lexicon]x264[/lexicon] ist ein verlustencode, lagarith verlustlos, abzüglich Farbraum.

Sagt doch schon der Name "Verlust" vs "Verlustfrei"

Zitat

Und was du mit Capturecard meintest?

Na das gedöhns für Konsolen. Elgato, Avermedia, Hauppauge HDPVR usw.

Achso.

Die Differenz oben trifft die Schuld ganz sicher nicht [lexicon]Lagarith[/lexicon].

[lexicon]Lagarith[/lexicon] YV12 ist sogar exakter als [lexicon]DXTory[/lexicon] [lexicon]Codec[/lexicon] YUV420.

Denn hier wäre der Weg -> YV12 -> YV12.

Optimal.

Vorrausgesetzt natürlich [lexicon]Lagarith[/lexicon] steht auf YV12 und wird auch als YV12 eingelesen.

AVISource neigt gern dazu [lexicon]Lagarith[/lexicon] YV12 als RGB32 zu erkennen. Eventuell hilft dagegen ja der Prevent Upsampling Haken.

Ansonsten [lexicon]Lagarith[/lexicon] via FFMS einlesen.

Barracuda 7200.14 schafft 196

aber was wollt ihr jetzt mit RGB?

Zitat von Vollkohrn

De-M-oN würde jetzt sagen:
Das liegt an Youtube die enkodieren scheiße.

Was ja auch der Fall ist

Zitat

Was meint ihr mit Verlustquellen? Mache ich irgendwas falsch?

Verlustkompression. z.B. Dateien einer Elgato oder HDPVR capturestation.

Solltest du bei PC Spielen verlustkompression benutzen, wäre das schon verkehrt, ja

Zitat von Magogan

Bin auch mal sehr gespannt, wie das dann auf YouTube aussehen wird.

Beschissen. Wie schon gesagt.

Hatte da eig. auch irgendwann mal dir 2 Beispielbilder gezeigt, wie "toll" yt 4k encodiert.
Ich sags schon nicht ohne Grund, das 3200x1800 das beste Ergebnis auf youtube erbringt

Zitat

Liest der eigentlich die Frames in der [lexicon]Auflösung[/lexicon] des Rohmaterials in den Speicher oder tatsächlich in 4K (also bereits hochskaliert)?

Naja natürlich die skalierten Frames. Die Filter kommen ja logischerweise zuerst, bevor der [lexicon]Frame[/lexicon] an den [lexicon]Encoder[/lexicon] geht.

Na siehste mal.

Ja das sollte doch logisch sein, das es weniger RAM verbraucht, wenn du weniger Frames in den RAM einlesen lässt

Wir haben dir bereits gesagt, das die [lexicon]GOP[/lexicon] wichtiger ist als noch der lookahead, zumindest wenn du beim gop so niedrige werte nehmen musst.

40er lookahead wäre das standard des medium presets, das könntest du locker noch machen. Lieber mehr GOP.

Definitiv ;D

Aber 4096x2304 / 3840x2160 - je nach dem was du jetzt machst - ich sag dir du wirst sehr enttäuscht sein was youtube daraus macht

3200x1800 ist schon Aufwand genug und darauf macht youtube die besten encodes. Höheres ist mehr Aufwand für sau wenig Qualität nach youtubes encode.

Aber mehr als 300x kann ich dir das auch langsam nicht mehr sagen

Lookahead ist eine rate-control option. Das kommt schon hin.

Zitat

als würde der sich da 60 Bilder angucken, um die Framerate zu überprüfen...

Das macht zudem doch überhaupt kein Sinn.

Die Framerate ist doch vorm Encode fest definiert durch Avisynth bzw von [lexicon]TMPGEnc[/lexicon] wenn ohne Avisynth.
__
Was ist an der Option seltsam^^ Sie gibt vor, wieviele Frames im Voraus in den RAM geladen werden. Aufgrund diesen Frames konstruiert [lexicon]x264[/lexicon] dann die b-frames etc. Lädst du weniger Frames, kann [lexicon]x264[/lexicon] halt auch weniger Frames da mit einbeziehen was die effizienz der kompression mindert.

lookahead mal auf 30 probieren.

Und auf youtube kriegste dann den Schock wie sie das codieren

Naja wie du meinst

Beides sind Möglichkeiten den Speicherverbrauch zu reduzieren.

60 ist aber auch schon recht hoher wert. Standard bei medium ist 40 und bei slow 50.

Beides hat nachteile für die Effizienz. [lexicon]GOP[/lexicon] als auch Lookahead.

Boah ich find das voll schlimm wenn [lexicon]x264[/lexicon] Optionen auf Teufel komm raus versucht wird in deutsch zu übersetzen und man dann echte schwierigkeiten hat zu erkennen welche es eig. mal war.

Aber letzteres ist das.

Damit liest er immer 60 Frames in den RAM. Da zb mal 40 oder 30 nehmen.

Nur mindert das ebenfalls die Effizienz. Das sollte klar sein.

Ja. Aber die Dateigröße wird bei einer [lexicon]GOP[/lexicon] von 15 schon recht beträchtlich ansteigen werden.

Da gibt es sinnvollere Methoden die dir schon genannt wurden.

Woran machst du aus, das es nicht funktioniert?

Für SetMemoryMax brauchst du das multithreadfähige Avisynth. Besitzt du das?

Und dann SetMemoryMax(512) würde es bei 4 Kernen auf 2 GB limitieren.

[lexicon]GOP[/lexicon] sollte nicht reduziert werden.

Wenn du es mit Avisynth nicht hinkriegen solltest, dann weniger [lexicon]CPU[/lexicon] Kerne benutzen für den Encode, und den lookahead niedriger, wie Zantos schon richtig sagt.

SetMemoryMax funktioniert beim avisynth

Und Avisynth erlaubt definitiv 4 GB bei 64bit [lexicon]OS[/lexicon].

Ist dann wohl eine weitere Schwäche vom [lexicon]TMPGEnc[/lexicon]

Mit Avisynth Script vllt beschränken, vllt hört [lexicon]TMPGEnc[/lexicon] ja dann auf dich. Aber 2 GB ist schon ziemlich ineffizient, wenn du ernsthaft 4096x2304 oder 3840x2160 machen willst.

Nur sei dir nochmalig gesagt, das youtube bei einer derartigen [lexicon]Auflösung[/lexicon] das Gegenteil produziert. Nämlich blöcke ohne Ende.