Beiträge von Sagaras

Zitat von Twonehat

Was hat es mit der GOP Struktur auf sich und ist Automatisch da am besten?

Die GOP ist die Group of Picture. Also auf Deutsch die Gruppe von Bildern.
Diese untergliedern sich in I-Frames (also Keyframes / dt.: Schlüsselframes), P-Frames und B-Frames.
Letztere sind Referenzbezogene Frames.

Als Faust Regel für die Einstellung der GOP gilt:
minimale GOP Länge = FPS
maximale GOP Länge = FPS * 10

Wenn die Einstellung bei dir auf Automatisch ist kümmert sich dein Programm darum welche Werte genommen werden. Die meisten richten sich aber oft nach der Faust Regel.

Zitat von Twonehat

CPB hab ich ja null, muss da was rein?

Die CPB ist der Coded Picture Buffer. Auf blöd Deutsch also der kodierte Bild Speicher.
Ist nix anderes als der VBV (Video Buffer Verifier).

Steht dieser bei H264 auf 0 so wird er automatisch bezogen.
Beschreibt halt die Speichernutzung wieviel Bits als Zwischengelagert werden können.

Im Falle von x264 gibt es 3 verschiedene Angaben des VBV's
Die VBV-maxrate in kbit/s sollte da auf 0 stehen. Diese stellt die maximalen Datenraten des Videos ein. Für Hardware Player eher interessant, da diese oftmals Limitierungen haben.
Die VBV-bufsize in kbit sollte ebenfalls auf 0 stehen. Diese legt die Größe des VBV Speichers an. Auch wieder eher was für Hardware Player, aufgrund von Limitierungen.
Und die VBV-init. Dieser Wert ist ein Prozentualer Wert zwischen 0.0 und 1.0 und gibt an wie viel der VBV Speicher gefüllt sein muss bis er die Wiedergabe startet. Standardmäßig ist diese Einstellung auf 0.9 sprich 90% eingestellt. Dies sollte für den PC recht uninteressant sein und eher was wieder für Hardware Player.

Hardware Player sind z.B.: Fernseher mit eingebauter USB Videowiedergabe oder Konsolen mit eingebauten Video Playern oder Handys oder oder oder. Sprich alle Geräte die feste vorgegebene Limitierungen setzen. Sind diese Limitierungen nicht vorhanden, werden die Videos auf diesen Geräten nicht unterstützt.

Zitat von Twonehat

Kodiequalität sollte auch Ausgeglichen sein?

Sofern du mit dem Ergebnis zufrieden bist. Das ist deine Entscheidung. ;D

Das hängt aber dann nicht mit Magix zusammen, sondern eher an deiner Leitung

Zitat von BlackLion768

- Youtubefestplatte ist bereits 2 Tage nach der Defragmentierung wieder zu fast 65% fragmentiert.

Solange du immer wieder da Dateien drauf schreiben tust ist das klar das die fragmentiert ist.

Zitat von BlackLion768

UtVideo: Aufnahme lief gut, Renderzeit solala (49 Min. = 2 Std. Renderzeit) und braucht bei YT fast 2 Std. zum hochladen

Wie lange das bei YT hochladen tut, hängt doch von dem ab wie groß die Datei nach deinem Encode ist.

VBR bei unterschiedlichen Material = unterschiedliche Dateigröße = unterschiedliche Uploadzeit.
Ganz einfache Logik Formel ;D

Und zwecks UtVideo und MagicYUV... wie hast du diese eingestellt zwecks Farbraum, Kodierungsart, usw.

Zitat von BlackLion768

- Magix scheint, wenn es rendert immer langsamer zu werden.

Magix lagert eine temporäre Datei gewiss irgendwo an. Vllt. auf C:\
Je größer sich diese temporäre Datei vollsaugen tut, desto langsamer werden die Prozesse.

Dazu müsstest du dann mal entweder hier oder in einem neuen Thread beschreiben wie dein jetziger Workflow genau aussieht.

Dein Haupt-Rendering findet in Premiere statt. Das ist nur die Bildberechnung, weil die fertigen Bilder lässt du ja via einer Pipeline weiterleiten an AVISynth und AVISynth leitet es weiter an avs4x264mod und der leitet es weiter an x264.

Ist irgendwo in der Kette ein Problem, hat auch der Rest ein Problem. Sei es Geschwindigkeit oder sonst irgendwas.

Die Frage die sich mir aber stellt ist eher warum du nicht zu x264vfw greifst? Wäre für deine Zwecke schneller, da dir somit der ganze Rattenschwanz zu MeGUI weg fällt und somit auch AVISynth.

Ich meine... statt 10Bit Encoding hast du mit x264vfw nur 8Bit Encoding, aber das sollte eigentlich reichen. Zumal das dann auch schneller wäre.

Ich sag es dir bloß, weil du ja schon auf Geschwindigkeit irgendwie aus bist wie mir scheint.

Du nutzt doch im AVISynth Script schon Multithreading. Und so gut wie keine Effekte oder Filter, bis auf die Skalierung vllt.

Was du suchst ist findest du bei Premiere. Deine ganzen Effekte und Filter in Premiere musst du über die GPU laufen lassen, sonst machst du das ja nur über die CPU und das dauert dann.

Da gibt es kein Skript was dir helfen kann, sondern dein Premiere muss deine Grafikkarte supporten und zum anderen musst du es in Premiere auch einstellen das er alle Berechnungen via der GPU machen soll.

Wird deine Karte nicht supportet oder du hast nur CPU Berechnung angeschaltet in Premiere, dann ist es klar das du dich somit selbst ausbremsen tust.

Zitat von Vouk

Wieviel Monate/Jahre braucht es eigentlich um den für sich selbst optimalen und qualitativ hochwertigsten Workflow herauszufinden?

Die Qualität die du fabrizierst muss dir selbst genügen. Wenn du damit selbst nicht einverstanden bist, gibt es in diesem Forum genug Leute um dir die Qualität zu liefern mit der du einverstanden bist. Da gibt es Workflows bis zum Abwinken.

Aber die ultimative Qualität will niemand haben, weil das Workflows sind die entweder viel Zeit fressen oder den meisten schon zu umständlich sind oder halt auch schon zu überzogen.

Ein gesunder Menschenverstand und ein geeignetes Maß sind schon mal gute Voraussetzungen. Wer weiß wie YT arbeitet, kann seinen Workflow drauf anpassen.

Es gibt zig Leute hier die dir Sachen zwecks Einstellungen und und und erklären und empfehlen können. Du kannst sie dann gerne annehmen oder hinterfragen oder halt auch sein lassen.
Immerhin sind es deine Videos und du musst damit leben und kein anderer

Zitat von GelberDrache92

Wir reden weder von Text Dateien, noch von irgendwelchen Bilder, sondern vom Encode mit MeGui...

Korrekt. Sprich von mehreren Bildern in Folge Und selbst da will ich nicht zwangsweise meine CPU komplett auslasten. Dann wäre ich ja vollkommen bescheuert

Zitat von GelberDrache92

Naja wenn die CPU zu 100% ausgelastet ist, dann ist man am Maximum der Möglichen Geschwindigkeit und sollte das so nicht sein, dann bremst da irgendwas aus, was die Dauer erhöht, das ist wieder blöd.

Jein.
Ich kann dir gern ein Tool schreiben was nur ne Text Datei öffnet, aber trotzdem deine gesamte CPU auslastet.

Will damit sagen das die Geschwindigkeit nicht unbedingt damit gemessen wird wie hoch der CPU Verbrauch ist.
Die CPU Auslastung erhöht sich nur wenn mehrere Rechnungen stattfinden. Sprich nur dann wenn auch wirklich was passiert.
Und es wird nur soviel verbraucht wie nötig.

Ein Beispiel:
Ist es nötig ein Bitmap Bild mit einer CPU Auslastung von 100% abzuspeichern?
Nein, es ist sogar der Gegenteil der Fall.

Ist es nötig die CPU komplett aus zu nutzen beim Video Encoding?
Nein, wäre sogar Kontraproduktiv.

Eine CPU die ausgelastet ist verlangsamt sämtlichen anderen Dienst am PC. Und das will man in der Regel gar nicht.
Spiele wollen das im Prinzip auch nicht. Wäre auch Fatal bei einem Spiel die komplette CPU aus zu lasten Weil dann kannste dem Spielvergnügen gute Nacht sagen, weil die Eingabegeräte gar nicht mehr reagieren und dir dein OS langsam absäuft

Ein Encoder will auch nicht unbedingt die ganze CPU nutzen. Aber ein Encoder ist ohnehin CPU Mäßig limitiert. Zum einen muss er das Input Material verarbeiten und zum anderen muss er oft auch warten auf diese.

Darum ist der Encoder sowas wie ein Trichter. Er kann nicht mehr verarbeiten als das was grad ankommt und dem was er grad schafft.

Für das was beim Encoder ankommt sind im Falle von MeGUI 3 Sachen wichtig.
Festplatte des Quellmaterials
Quellmaterial an sich
und AVISynth

Die Geschwindigkeit der Festplatte muss halt ausreichen, was sie in den meisten Fällen ja meist tut. Das Quellmaterial muss schnell genug decodiert werden und verarbeitet werden von AVISynth, dazu sind schon mal Einlesefilter wichtig wie z.B. FFMS2, L-Smash, AVISource, etc.
Und dann wird der Quark ja noch gewiss durch einige Filter laufen, wobei AVISynth ohne MT nur mit einem Kern läuft in der Regel.

Heißt auf Deutsch: Der Encoder langweilt sich, weil nix ankommt womöglich.
Oder der Encoder ist recht stark eingestellt das er lange braucht um zu kodieren. In diesem Falle muss man an den Einstellungen schrauben.

Aber du kannst mir glauben das kein vernünftiger Entwickler der Welt die CPU mit absicht auslasten will. Das wäre einfach nur Fail dann.

Kann man im Falle MeGUI und x264 sogar beeinflussen den CPU Verbrauch.
Die Presets sind ja nicht umsonst nach Geschwindigkeiten benannt. Je schneller, desto weniger CPU ist von nöten.

Zitat von Karmaalp

PS. Liegt aber nicht am Material sondern an was anderem, denn wenn ich das Video ohen Effekte Render dann ist es wie gewohnt bei 100% CPU Auslastung.

Effekte brauchen Berechnungs Zeit. Die lässt du aber wie ich es sehe nicht mit AVISynth machen, oder? Weil wenn du diese Effekte in deiner Schnittsoftware machst sollten die am Besten über die GPU weites gehend laufen und nicht via CPU. Sonst bremst du dein System bewusst selbst aus.

Immer dran denken: Rendern und Encodieren sind 2 unterschiedliche Sachen. Das eine schreit förmlich danach mit GPU zu arbeiten. Das andere möchte CPU ;D

Zitat von Karmaalp

Besser die CPU auf 10% lassen und dann ist 1 Video ca. nach 12 Stunden fertig hört sich gut an xD

Das ist ein bisschen Mau mit 10%
Aber 100% ist etwas arg viel. Solange es aber nicht alle Kerne machen ist das auch ok.
Immer dran denken: Eine CPU will niemand zu 100% auslasten. Aber im Low Modus ist es auch nicht grad prickelnd für etwas was schneller kann laufen.

Lass mal das mit MP4Box GUI. Die GUI Anwendung ist für die Füße. Die taugt einfach nix. Egal in welcher Hinsicht.
Zudem ist die GUI Version einfach zu alt. Letztes Release war 2013.

Die aktuelle CLI Version ist um längen besser und zudem könnte er es in seiner Batch Datei verwursten. Da wurde erst am 8.12.2016 das letzte mal released.
Da ist GPAC recht schnell was das angeht ;D

Eigentlich bin ich froh wenn die CPU nicht ausgelastet wird. Warum sollte man dies also absichtlich wollen?

Prüf lieber nach was vor dem Encoder stattfindet, statt die Schuld beim Encoder zu suchen.

MeGUI nutzt AVISynth. Also wäre es schon mal von Vorteil zu wissen was die Mediainfo zu deinem Quellvideo sagt das du in MeGUI lädst und was du im AVISynth Skript alles verwendest. Nicht das du es absichtlich ausbremsen tust.

Zitat von Peacemaker666

der DxTory-Decoder war da deutlich schneller. Allerdings funktioniert der nicht bei OBS-Aufnahmen.

Der DxTory Audio Demuxer versteht nur PCM Audio. Wenn du mit OBS in AVI aufnehmen solltest und PCM als Audio, dann klappt der dort genauso gut.

Zitat von Peacemaker666

der DxTory-Decoder war da deutlich schneller. Allerdings funktioniert der nicht bei OBS-Aufnahmen.

VDub ist Speicherbegrenzt und auch das Ausleseverfahren ist etwas eigensinnig was die Speichernutzung angeht.
Daher wäre da vllt. VDDubMod vllt. interessanter.

FFmpeg kopiert via Bitstream. Das ist recht genau aber auch langsamer als wenn man den gesamten Stream nimmt und einfach nur alles in den Speicher zwischenlagert wie geht und diesen Inhalt kopiert.

Das sind zwei unterschiedliche Methoden.

Demuxer wie bei MKVExtract oder XMediaRecode machen die übliche Kopiermethode die ihr als Schnell bezeichnet.

• Nacheinander splitten lassen und nicht simultan, lastet sonst nur Schreibaufwand auf der Festplatte aus, nicht die CPU, die macht sonst Pause
• Warum werden nur 4 Threads genutzt? Sehe da keinen Sinn dies limitieren zu wollen.

Bremst halt aus sowas.

Und ja, die CPU braucht nicht viel. Was soll sie denn machen beim Kopieren? Auf 100% gehen? xD Das wäre mal richtig Fail. xD

Was du nicht angegeben hast ist das er das Video weglassen soll. Da fehlt bei dir also noch der Parameter -vn
Dann wird Video ignoriert. So wie es jetzt bei dir aussieht schleußt er das Video mit durch. Und das bremst dann natürlich auch.

VAC tritt nur ein wenn Werte geändert werden. Das hat er dir auch geschrieben. MSI AB ändert aber keine Werte während des Hookens, sondern greift Werte ab.

Das Lesen und Schreiben sind zwei unterschiedliche Sachen ;D

VAC soll jeglichen Missbrauch durch Cheats/Hacking etc. verhindern.

Bedeutet:
Das Spiel kannst und darfst du auslesen lassen, sofern du damit was anfangen kannst und es dir Spaß macht. Sollte aber festgestellt werden das du Daten veränderst/manipulierst, dann tritt VAC in Kraft.

Sprich Auslesen kannst du soviel du willst, weil du die Daten nicht veränderst. Nur jegliche Manipulation dieser Daten ist untersagt.

Das Hooking des MSI AB löst also an sich keinen VAC aus, da es nur die Daten ausließt. Und das auch noch nur in dem Speicherbereich wo die Frames sind. Es ist daher recht unwahrscheinlich das VAC ausgelöst wird.

Da sich MSI AB sich aber keine Schuld zukommen lassen möchte aufgrund das jemand bei Drittsoftware unerlaubte Sachen macht oder die AGB nicht richtig gelesen hat wird sich MSI AB da sowieso raus halten. Das würde jeder Entwickler tun.
Dies wird dir auch bei OBS, Fraps, DxTory und anderen Aufnahmetools vom Support oder Entwickler so gesagt. Keiner wird sich für ihre Programme bei Drittsoftware verantworten. Das musst du schon selbst dann.

Nimm am besten AVSPmod als Editor. Das wird dir dann ungemein helfen, vor allem auch wegen der Vorschau schon und den Zoom den du dort nutzen kannst.

Und dann musst du dein Testvideo dort reinziehen und ebenfalls auf das 4x fache skalieren.
http://avisynth.nl/index.php/Resize

Wenn du den passenden Skalierer gefunden hast wird das Bild identisch aussehen.

Aber Vorsicht wie gesagt: Du musst dann schon eine genaue Pixel Analyse vornehmen. Ein Bild wo jeder Pixel unterschiedlich ist, weil es sich um ein neutrales Bild handelt, kannst du keine Analyse nachvollziehen, weil du jeglichen Bezug somit zerstört hättest.

Am besten ist immer ein TestBild mit einem schwarzen Hintergrund und darauf 4 senkrechte und waagerechte 1 pixel breite Streifen mit den Farben Rot, Grün, Blau und Weiß und zwischen jeden Streifen min. 6 pixel frei lassen. Damit kann die Schärfe später besser abgeschätzt werden.

Weil du siehst auf Schwarz sehr gut die Ringbildung dann auch

Auch solltest du Kreise mit diesen Farben einbauen. Damit testest du die Treppenbildung. Kreise dann auch wieder 1px breit.

Und die Farben sind dann halt auch so gewählt dann das du ein Farbverlust sogar wahrnehmen kannst, wenn das Video z.B. eine YV12 Konvertierung hinter sich hatte.

Damit hast du alle Test in einem Testbild drin und kannst es wunderbar vergleichen.

Soviel zum Testvideo.

Und nun zum AVISynth Part:

TestVideo = ImageSource("Testvideo.png") # Bei Bildern wird in RGB24 geladen


faktor = 4


TestVideo.BilinearResize(TestVideo.width * faktor, TestVideo.height * faktor) # Skalierung des TestVideos auf das 4fache

Hast du das in AVSPmod, kannst du mit einer Zoom Einstellung von 100% den aktuellen Frame als PNG Bild speichern.

Bei deinem Schnittprogramm holst du dir auch ein Frame raus. Das kannst du, wenn du es mit MagicYUV oder sonsteinen Lossless Codec abgespeichert hast ebenfalls mit AVISynth wieder raus holen:

AVISource("Testvideo.avi")

Reicht absolut, da du nur ein Frame haben willst. Stellst den Zoom auf 100% ein und speicherst dann ebenfalls das Frame als PNG Bild.

AVSPmod bietet dir das dann auch an das mit der Bildspeicherung. Zoom und Bildspeicherung kannst du mit Rechtsklick im Vorschaufenster von AVSPmod erreichen.

Beachte: Dies ist ein reiner RGB Test. Da du ja nur die Skalierer ausfindig machen möchtest.

Bei YUV hast du Farbverluste mit drin, daher nicht nutzen, da du somit zur Analyse auch die Farbverluste zwecks dem Verschmieren der Interpolation der Farbunterabtastung fälschlicherweise mit berücksichtigen wirst.
Was aber nicht Ziel deiner Fragestellung ist.

RGB bietet sich deshalb an, weil du zum einen nicht mit Farbranges zu tun hast und zum anderen auch nix mit Farbmatrizen oder wie schon genannt den Farbunterabtastungen. Daher ist RGB ideal als Testquelle und Ausgabe.

Darauf halt immer achten.
Darum hast du auch die Regulär Farben drin im Testbild um das gleich ausschließen zu können. Weil das sieht man dann ;D

Wieso nicht zufriedenstellend? Steht doch die Erklärung drin.
Wo ist das Problem?

Oder anders gefragt, weil du ja sagtest das es dich nicht zufrieden gestellt hat: Was ist denn passiert?

Zitat von GrandFiredust

Kann man eigentlich irgendwie herausfinden welcher Skalierer von einem Schnittprogramm verwendet wird?

Schwerlich, wenn es nirgendwo konkret steht.

Wenn man es nicht irgendwo raus bekommen kann vom Entwickler z.B., dann bleibt nur eine mühsame Vergleichsanalyse der Videos.

Für so eine Analyse nehme man am besten ein Pixel Testbild mit feinen Pixellinien auf schwarzen Grund.
MSPaint sollte dir für sowas reichen.

Aus diesem Testbild lässt du ein Roh RGB Video erstellen. Achte darauf das du kein YUV nutzt um spätere Verwischeffekte aufgrund des YUV Farbraumes zu verfälschen.
Das RGB Video wird dann als TestVideo verwendet in den jeweiligen Programmen. In den Programmen selbst sollte man dann am besten um das 4fache oder höher der Videoauflösung skalieren um die Muster dann zu erkennen. Das Video sollte dann wieder mit RGB Verlustfrei abgespeichert werden.

AVISynth ist dann dein Freund und Helfer. Denn dort machst du das gleiche mit dem TestVideo. Dann lädst du das andere Video was du mit der Schnittsoftware erstellt hast auch hinein und lässt beide nebeneinander darstellen. Und dann vergleichst du die Kanten, ob es Ringing aufweisen tut usw.

Die Testvideos sehen dann identisch aus, solltest du in AVISynth den passenden Skalierer genutzt haben.

Wie gesagt... sehr Mühsam. Aber ich denke das man das sonst ohne weiteres nicht herausbekommt, wenn es nicht irgendwo schon steht.

Im Normalfall wird bei Schnittsoftware sehr beliebt Bicubic oder Bilinear verwendet.
Bei TMPGenc und Shotcut kannst du aber auch schon auf Lanczos, Spline und Point antreffen.

Zitat von GelberDrache92

Es geht ja nicht um die Menge der Information, sondern was sich besser komprimieren lässt *hust*
Aber, who cares....

Zitat von Sagaras

Da aber gleicher Informationsgehalt unterschiedlicher Größe mit Kompression auf gleiche Größe komprimiert wird ersieht man den Vorteil nicht.

Hast du gut nachgewiesen das der Informationsgehalt gleich bleibt zwischen YV12 und NV12. Den Rest lassen wir einfach mal unter den Tisch fallen. Reicht ja wenn du dich da vollkommen auskennst

Zitat von Kayten

"Das musst du so nutzen weil Grafikkarte" ist nun mal keine Begründung mit der ich mich begnüge. Das hat für mich die Aussagekraft des Wahrheitsgehalts eines Perpetuum Mobiles auf YouTube.
Ich hätte gerne einen praxisnahen Test der zeigt, dass die Nutzung von NV12 tatsächlich einen spürbaren oder zumindest messbaren Vorteil bietet. Wüsste ich, wie sich das am besten umsetzen ließe, würde ich mich selbst daran setzen.
Wer sich bei x264 aus Performancegründen bereits mit i420 und NV12 befassen muss, dem wird der (falls überhaupt existente) Performancevorteil nicht weiterhelfen und hat aus meiner Sicht gänzlich andere Probleme. Gehört bisher aus meiner Sicht in die Kategorie "nett zu wissen, aber in der Praxis unwichtig".

Performanter im Sinne wie es gespeichert wird.

Schließlich wird der Informationsgehalt ja nicht anders nur weil man von einem 4:2:0 auf ein anders 4:2:0 wechselt.

Kurze Erklärung:
NV12 ist besser performanter gegliedert und baut sich daher schneller auf und lässt sich besser auch wieder abspeichern.
Reihenfolge der Speicherung:
Y Register
gefolgt von den UV Registern (Bund)
Sprich Y1 Y2 Y3 Y4 Y5 Y6 U1 V1 U2 V2 U3 V3 U4 V4 ...

Bei YV12 hast du die typische MPEG Basis noch die wesentlich langsamer ist.
Erst erfolgen die Y Register
gefolgt vom U Register
und erst zum Schluss kommt der V Register
Sprich Y1 Y2 Y3 Y4 Y5 Y6 U1 U2 U3 U4 U5 U6 V1 V2 V3 V4 V5 V6 ...

So bauen sich dann die Matrizen auch auf.
Daher hast du mittels NV12 das Bild nicht nur schneller, sondern es wird dir die Ebene gleich komplett mitgeliefert beim UV Durchgang. Bei YV12 nicht.

Bei NV12 wird der U Bit als least significant bit und der V Bit als most significant bit gehandhabt. So teilen sich beide ein Byte.
Und YV12 nutzt für U und V jeweils ein Byte separat.

Während also NV12 Sparsam ist und 2 Byte verwendet, verwendet YV12 schon 3 Byte. Und das für den gleichen Pixel.

Den Unterschied zwischen beiden kann man so nicht gleich ersehen, weil gerade NV12 meist in Kompressions Codecs verwendet wird.
Ansonsten würde man zwischen NV12 und YV12 einen Dateigrößen Unterschied feststellen.

Da aber gleicher Informationsgehalt unterschiedlicher Größe mit Kompression auf gleiche Größe komprimiert wird ersieht man den Vorteil nicht.

Wie gesagt: NV12 muss mit weniger auskommen Daten auskommen, weil U und V sich ein Byte teilen. Somit reduziert sich natürlich auch die Datenmenge die durchgejagt werden muss.

Ich hoffe ich konnte dich damit wenigstens etwas weiter helfen.

In der Praxis ist man mit NV12 weit schneller fertig als mit YV12, es sei denn man dekodiert es wieder in RGB um, dann verfällt natürlich der ganze Schmarrn.
NV12 ist aber vor allem beim Streaming sehr gefragt aufgrund dessen was ich dir versucht habe zu erklären. Daher wird es in OBS ja auch verwendet. Theoretisch wird es eigentlich schon in jedem Streaming Tool verwendet. Selten das es mal bei einem Streaming Tool fehlt.