Beiträge von Sagaras

Zitat von NessaElessar

Wenn Dein Monitor kein 16:9-Format hat, würde ich Dir deshalb empfehlen, im Fenstermodus aufzunehmen.

Was hat der Monitor mit der Spielauflösung am Hut?

Du kannst ein 4:3 Monitor zuhause haben und das Spiel trotzdem im Vollbild mit einer 16:9 Auflösung einstellen. Entweder wird das Seitenverhältnis dann gezerrt, bleibt unverändert oder entspricht der tatsächlichen Auflösung der Anwendung.
Gibt nur diese 3 Varianten die man bei der Grafikkarte einstellen kann. Also das was Julien schon gesagt hat.

Wenn man ein 16:9 Monitor hat und hat ein Spiel was nur 4:3 Auflösungen anbietet, kann man entweder A) nach einem Widescreen Patch suchen im Netz oder B) man lebt damit das man das Spiel nur in 4:3 aufnehmen kann.

Der Monitor ist total irrelevant. Weil wenn deine Aussage zutreffend sein sollte, müsste es sich noch um einen sehr sehr alten Röhrenmonitor handeln der zu DOS und Win95 Zeiten gängig war. Und das bezweifle ich schon stark das jemand soetwas noch nutzen sollte, außer Liebhaber.

Sein Hauptproblem ist zwischen den Auflösungsmodi zwecks Desktop und Spiel zu unterscheiden und auch zu wissen das das Aufnahmeprogramm sich in das Spiel hooken muss um die Bilder aus dem Spiel abzugreifen.

Was meint ihr bekommt er bei der Aufnahme Auflösungen von 1280x962 raus?
Würde er tatsächlich das Spiel in 4:3 aufnehmen wären die gängigen Auflösungen für 4:3 entweder 1024x768 oder 1152x864
Eine einstellbare 4:3 Auflösung mit 1280x960 ist mir so noch bei keinem Spiel untergekommen. Und dann weicht seine auch noch ab.

Und genau in dem Punkto komm ich nicht ganz mit was er da grad treibt.

Ich würde ihn ja auch von Shadowplay abraten. Weil das bringt früher oder später wieder das nächste Problem bei ihm mit zwecks Synchronität zwischen Video und Audio wegen der VFR.

Eventuell nutz er vllt. in irgendeinem Schnittprogramm auch noch Autocrop wo dann schwarze Flächen einfach aus dem Bild geschnitten werden und die komischen Auflösungen daher rühren mit 1280x962, weil er dann mit 1280x1024 aufgenommen hat. Würde auch einiges erklären.

Ich kann aber wie gesagt sein Workflow nicht komplett nachvollziehen, und daher nur Mutmaßen was der Fehler sein könnte.

Zitat von Goodcat

Genau. Also vorher habe ich in 1280x1024 aufgenommen und nachdem der Fehler erkannt wurde in 1280x720 (lt. Einstellungen, Mediainfo sagt ja 1280x962 / 4:3).

1280x962 ist aber nicht exakt 4:3, sondern nur Annährend. Für 4:3 müssten 2 Pixel der im Y Bereich, also 2 Zeilen im Bild, weggestrichen werden. Weil 1280x960 ist eine 4:3

Fangen wir mal von vorne an:
Mit was nimmst du denn auf?

Zitat von Goodcat

Overwatch wird bei mir gar nicht in 1920x1080 angeboten, aber für das 16:9 nahm ich ein Spiel mit 1280:720 auf.

1280x720 sind aber nicht 1280x1024 Das erste ist eine 16:9 Auflösung das andere eine 5:4

Du musst halt drauf achten das das durchgehend auch so bleibt.

Wenn dein Spiel mit 1280x720 läuft und du auch deine Aufnahme 1280x720 hast (Kannst dafür ja Mediainfo nutzen um nachzusehen), dann musst du deine Bearbeitung im Schnittprogramm auch das 16:9 Seitenverhältnis der Aufnahme beibehalten und nicht in 5:4, 4:3 oder 16:10 oder was auch immer abdriften. Weil sonst hast du diese Videos wie du sie verlinkt hast oben.

Sprich bei der Ausgabe muss drauf geachtet werden, genauso wie auf die Projekteinstellungen. Die müssen die Einstellungen auf das Video angepasst werden und nicht umgekehrt das das Schnittprogramm die Videos anpasst auf Preset 'Schieß mich tot'

Zitat von Goodcat

Bei den Einstellungen gab ich einfach 16:9 und 1280x1024 ein.

16:9 bei 1280x1024 (5:4) ergibt das Bild was du auf YT hast.
Das Video an sich ist dann 16:9 mit einem Bildinhalt was auf 5:4 ist und das ist nun mal kleiner als 16:9. Weil die 5:4 Auflösung schon fast 4:3 entspricht. Und das sieht man auch als Ergebnis in deinem verlinkten Video.

Frage ist jetzt wie du aufgenommen hast? Ist die Aufnahmeauflösung schon eine 5:4 Auflösung mit 1280x1024 oder hast du in einer 16:9 Auflösung aufgenommen wie zum Beispiel 1920x1080?

In beiden Fällen würdest du in der Bearbeiung was falschen einstellen zwecks Projektauflösung bzw. Encode Auflösung.

Du musst das aufgenommene Video immer als Basis nehmen und nicht die Schnittprogramme entscheiden lassen was das beste wäre. Die sind nämlich weder für Let's Plays, noch Youtube Videos generell ausgelegt. Da muss man also schon etwas selbst dran rumfummeln ;D

Zitat von Peacemaker666

Ist jetzt der Unterschied zwischen den Windows-Eigenschaften und der Media-Info. Der Wert von der Media-Info würde dann stimmen, der von Windows ausnahmsweise nicht.

Die Funktion der Windows Eigenschaften lesen lediglich den im AVI Header befindlichen Wert aus. Nicht den aus dem Stream.

Der AVI Header ist so aufgebaut:

RIFF
 └ HDRL
    ├ AVIH
    │  ├ MicroSecPerFrame
    │  ├ MaxBytesPerSec
    │  ...
    └ STRL
       └ STRH
          ├ FourCC_Type    : vids
          ├ FourCC_Handler : ULH0
          ├ Flags
          ...




Die AVIH ist der AVIHeader
Die STRH unter STRL sind die Stream Header.


Und die sind dann unterschiedlich. Der Header aus der AVIH ist irrelevant und wird in den meisten Fällen ignoriert.


Der AVIH und der STRH können die selben Informationen beinhalten zwecks Auflösung, FPS und Bitrate. Jedoch ist nur der STRH interessant. Der AVIH Header wird meist nie ausgelesen. Außer von Windows selbst xD

Die MaxBytesPerSec beinhalten dann die Bitrate die du unter Windows Eigenschaften siehst.
z.B. wird dort gespeichert: 488900 Bytes/sec (4Bytes - 0xC4750700) = 2500 kbit/s

Unter STRH wird dann noch mal der Codec Header von UTVideo seperat angegeben.

Die Struktur sieht aber so in jedem AVI Header gleich aus. Erst die Codec spezifischen Header geben die genauen Angaben zwecks Bitrate an. Das kann z.B. der Decoder dann auswerten oder Programme die die Codecs kennen. z.B. Mediainfo.

Kurz und gut: Der unter AVIH angegebene Wert muss nicht korrekt sein. Da kann auch 1 kbit/s stehen und trotzdem ist ein Lossless MagicYUV darin gespeichert der ohne Probleme angezeigt werden kann.

Dann würde dir Windows über die Windows Eigenschaften sagen das das Video nur 1Kbit/s hat.
Das ist halt etwas Fail dann.

@Spieluin
Die Bilder in JPG hier zu posten ist etwas Fail, da JPG schon Verlustbehaftet ist und somit der Vergleich hinkt da von UTVideo die Kompressionsverluste zu ersehen.

Die letzten zwei Bilder jedoch sehen für mich nach einem PC vs TV Range Problem aus. Sprich Begrenzter Bereich vs Vollbereich.

Bei VFW UTVideo kann man das nicht einstellen, das obliegt der Aufnahmesoftware was sie hergibt.
Sprich MSI AB würde im Vollbereich aufnehmen, wenn man UTVideo YUV420 BT.720 VCM nutzt. Da MSI AB die Bilder als RGB abgreift.
Sofern MSI AB das auch so mach ;D

Die MSI AB Aufnahmen müssen also nachträglich in TV Range umgeändert werden. Das kann man z.B. mit SSM machen.

Wenn man mit OBS nun gleich in TV Bereich aufnimmt, dann muss auch im SSM das so angegeben werden das sich da nix ändert, sonst wird TV auf TV aufgewertet und das ergibt eine Doppel Limitierung des Farbbereiches. Und das muss nicht sein.

MagicYUV bietet z.B. von Haus aus an in welchen Farbbereich man es nutzen will für die Konvertierung.

Jetzt hab ich auch mal 25000 eingetragen. Aber OBS nimmt bei mir mit UTVideo mit über 120Mbit auf bei einer Auflösung von 1600x900 und 60 FPS bei YV12.

Also ich kann es nicht reproduzieren das die eingegebene Bitrate genommen wird.

Und das Bild ist sauber. Keine Artefakte oder sonstwas was als Verlust gilt. Außer halt der Subsampling Verlust von YV12. Aber der würde auch wenn man den VFW nutzen würde zu ein identischen Bild führen.

@De-M-oN
Anscheinend trifft bei ihr beides zu. Einmal unterschiedliche Farben zwischen MSI AB und OBS und einmal das OBS bei UTVideo angeblich mit einer individuellen Bitrate aufnimmt und Kompressionsverluste somit auftreten.

So lese ich es bei ihr raus wenn ich richtig gelesen habe.

Kann ich aber halt nicht reproduzieren, solange ich nicht 100% weiß wie und was sie bei MSI AB eingestellt hat und bei OBS.
Denn wenn beide gleich moderat eingestellt wurden sehen die Bilder zwischen MSI AB und OBS identisch aus ohne Unterschiede. So jedenfalls bei mir hier.

Bei mir steht, wenn ich es umgestellt habe, UTVideo als Standard-Codierer.

Habe auch OBS Studio v18.0.1

UTVideo nimmt auch nur mit I-Frames auf (Keyframes). Daher ist die Keyframeeinstellung auch total Nutzlos bei UTVideo.

Das hier ist dann noch wichtig, damit es nicht Verschmieren tut:

Basis Auflösung = Ausgabe Auflösung

Und das hier ist halt wichtig:

I420 = YV12 = YUV420
I444 = YV24 = YUV444
RGB = RGB24

Matrix: BT.709
PC Range: Begrenzt
Gilt nur für I420 und I444, da RGB keine Matrix hat und nur im Vollbereich läuft.
Für weitere Infos siehe hier: Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge

UTVideo akzeptiert keine benutzerdefinierten Bitraten, da es sonst kein Lossless Codec wäre. Selbst bei FFmpeg nicht.
Sobald es benutzerdefinierte Bitraten akzeptieren würde, wäre der Codec ein Lossy Codec.

Es muss jedoch bei OBS drauf geachtet werden das OBS die für den Codec passenden Einstellungen bekommt.

UTVideo akzeptiert z.B. kein NV12 Farbraum.
Auch sollten Auflösungsfilter zwecks Resizer deaktiviert werden, indem sie identisch eingestellt werden. Halt um Resize Verlust zu vermeiden.

Weil ich kann hier mit OBS die Bitrate bei UTVideo gern auf 2500 stellen und er nimmt mir trotzdem mit 104MB/s auf.
Wird also nix limitiert. So wie es sich auch gehört.

Daher weiß ich nicht was ihr damit angestellt habt.

UTVideo nimmt zur Aufnahme soviel Bitrate wie es braucht.
Das heißt: Wenn es ein Standbild ist kann gut komprimiert werden und die Bitrate kann ziemlich niedrig werden.
Bei komplexen Material wird die Bitrate halt größer. Aber ist immer kleiner als wenn es unkomprimiert wäre. Die Unkomprimierte Größe wäre dann das maximum was es geben könnte. Die Bitrate wäre dann Auflösung mal FPS mal BBP des Farbraums. Und bei UTVideo wäre das immer kleiner, da es ein Kompressions Codec ist.

Wie gesagt, ich kann bei OBS machen was ich will, UTVideo akzeptiert dort keine individuellen Bitraten. Und sieht beim Ergebnis halt identisch aus wie der gleichnamige VFW Codec.

Drauf achten sollte man wie gesagt beim Resizer und beim Farbraum.

Wird NV12 als Farbraum genommen, wird UTVideo automatisch das Ganze als RGB32 aufnehmen.
Und die Resizer lassen meist die Aufnahme verwaschen die bei OBS genutzt werden. Unbedingt abschalten, indem sie identisch eingestellt werden.

PS:
Basisauflösung sollte die Auflösung der Software haben.
Heißt: Wenn man Desktop aufnehmen will, sollte da die Auflösung des Desktops stehen
Läuft ein Game in 800x600, dann sollte dort 800x600 stehen.

Die Ausgabe Auflösung sollte genauso dann eingestellt werden.

Wenn das nicht so gemacht wird, verwischt das Video oder wird sogar abgeschnitten.
Wenn es aber so gemacht wird wie eben beschrieben, dann ist Basis Auflösung = Ausgabe Auflösung und somit muss kein Skalierer arbeiten. Ergebnis ist dann ein sauberes ungeänderte Bild.

Würde man dann noch den Farbraum auf RGB32 einstellen, so nimmt UTVideo 1:1 auf. So wie man die Anwendungen auch sieht. Ohne Verluste von Subsampling oder Skalierer.

Zitat von De-M-oN

Biste dir da sicher? H.264 4:2:0 würde in MKV ja auch nicht auf gehen. Die Programme scheitern ja bereits am Container

Habe das von Schauerlands Text so das er glaubt das Vegas in der Lage ist MKV zu öffnen. Da ich das nicht weiß ob die aktuelle Version von Vegas dies kann, kann man trotzdem darauf hinweisen das es ein Unterschied ist was im MKV Kontainer ist. Kommt nämlich auf den Inhalt an. Man kann in einer MKV ja auch nur Audio rein packen und dann würde das Schnittprogramm vllt. die Datei verweigern aufgrund das der Video Stream fehlt.

Kann, muss nicht.

Die Vielfalt was man damit anstellen kann und dessen Folgen sind eine Menge. Müsste man mal so ziemlich jede Konstellation prüfen. Ersparen wir uns aber denk ich, weil die meisten hier im Forum eh immer Video und Audio am liebsten in einen Kontainer haben wollen und halt auch haben.

Zitat von Schauerland

Grund: mp4 schreibt seine header ans ende der Datei

Kann auch am Anfang stehen. Kommt auf das Programm schlussendlich an wie es verwaltet wird.

Zitat von Schauerland

Mit OBS solltest du am besten im MKV format aufnehmen.
Falls du mp4 benötigst ist der remuxer direkt in OBS eingebaut (File Remux oder so...)
Adobe zB kann kein mkv - vegas kann es glaube ich (aber kein lossless)

MKV ist ein universal Kontainer in dem man so gut wie alles hineinpacken kann. Ob das nun verschiedene Video oder Audiostreams sind, Font Dateien, Untertiteldateien, Kapitel Einträge usw.

Gibt Anwendungen die möchten das nur bestimmte Dateien genutzt werden können, um z.B. Markt-Technisch Profit damit zu machen andere Dateiformate mithilfe von z.B. Plugins zu erweitern. Und die Kosten dann halt.
x264pro für Adobe was nix anderes ist als x264 8bit, kostet somit als Erweiterung für Adobe 300$. Obwohl der nix anderes macht als der normale x264 der kostenlos ist.

Und die Adobe Junkies kaufen den dann halt.

Alles eine Frage wie man Geld abschöpfen kann.

Und wenn du in einen MKV File ein UTVideo Stream stecken würdest, würde selbst Vegas via MKV ein Lossless File öffnen. Es kommt auf den Inhalt schlussendlich an.
Das Problem was man bei den Schnittprogrammen hat ist das sie bei AVC Streams jeglicher Art immer bestimmten Profilbeschränkungen ausgesetzt sind.
So wird z.B. mitunter Verhindert das man bestimmte High Profile nicht laden kann, darunter das Profil High 4:4:4, das zum anderen für Lossless benötigt wird bei AVC Streams. Siehe dafür x264 Lossless.

Auch kann es vorkommen das einige Decoder des Schnittprogrammes Probleme beim Entschlüsseln des Videos machen.
z.B. hat man dann ein Wirrwarr Muster, weil 10Bit nicht decodiert werden kann, da das Schnittprogramm nur 8bit versteht.
Oder der Farbraum ist in 4:4:4 oder 4:2:2. Wenn das Schnittprogramm nur 4:2:0 decodieren kann bei AVC Material, dann entstehen oft grüne Flächen im Video, da die Luma und Chroma Auflösung nicht passen.

Das sind alles so Kinderkrankheiten die manche Schnittprogramme (und darunter sogar angeblich Professionelle) haben.

Die Masse der Leute nimmt aber eh in 4:2:0 auf, das passt schon mal mit jedem Schnittprogramm.
Bei OBS nutzen viele Leute auch das High Profil das bis Level 10 geht, weil Standard. Auch das passt dann mit jedem Schnittprogramm.
Und wenn die meisten Lossless aufnehmen wollen, greifen eh viele nach DxTory, MSI AB, Fraps, und Konsorten.

Die Masse möchte halt die Dateigröße bei der Aufnahme so gering wie möglich halten. Oftmals das sie damit sogar noch zufrieden sind, auch wenn es Qualität einbüßt.

Aber wie gesagt, man kann auch in ein MKV Kontainer ein Lossless Stream ala UtVideo oder FFV1 oder was auch immer einfügenn und jedes Schnittprogramm was zum einen mit MKV und zum anderen mit dem Codec was anfangen kann wird das auch schlucken. Was bei AVC halt nicht der Fall ist, da es sich bei AVC nicht um Lossless handelt, sondern um eine Verlustkodierung.

Das heißt das selbst x264 Lossless an sich eine Verluststrucktur alias AVC Stream in den Datei Kontainer packt. Und darauf achten die Schnittprogramme sehr penibel drauf.

Ihr müsst euch mal merken (an die die schon länger hier im Forum Support für Audio und Video geben), DXTory, MSI AB und auch Fraps können kein VFR.

Das Kernproblem wenn Audio abdriftet zur Mikrofonspur ist das Timing von Windows, unterschiedliche Hertz Angaben (Wohl eher unwahrscheinlich bei der Aufnahme das da was Asynchron wird bei) ODER das verwendete Aufnahmegerät spielt nicht ganz mit (WASAPI vs. DirectSound).

Zwecks Timing sollte überprüft werden ob HPET (High Precision Event Timer) aktiv ist im BIOS, als auch in Windows.
Standardmäßig ist es meist so das es im BIOS an ist, aber in Windows aus.
Überprüfen kann man das z.B. mit WinTimerTester (http://www.mediafire.com/file/…cyfg88c/WinTimerTester.7z)

Steht dort irgendwas mit 3.xxx MHz, dann ist HPET inaktiv
Wenn dort steht 14.xxx MHz, dann ist HPET aktiv

Sollte es nicht aktiv sein, kann man es via der CMD und dem Befehl bcdedit /set useplatformclock true aktivieren.
Der Rechner sollte nach dieser Aktion neu gestartet werden.
Zum Deaktivieren den gleichen Eintrag nur mit false.

Bei unterschiedlichen Hertz Frequenzen bei der Aufnahme zwischen Systemsound und Mikrofon, kommt es meist im Schnittprogramm zur Asyncronität, da meist versucht wird beide Spuren auf eine Frequenz anzupassen. Meist wird dann die eine damit beschleunigt oder verlangsamt.
(Ist hier in dem Thread laut der Mediainfo nicht der Fall)

Und es gibt einige Rechner die Probleme mit WASAPI haben. Falls dies der Fall ist, einfach mal DirectSound dann probieren. Oftmals das gerade Onboard Soundkarten damit oft Schwierigkeiten machen.

Und was viele oftmals übersehen ist das es beim Abspielen von Lossless Material oftmals zu Nachladeproblemen kommt im Videoplayer. Daher kann es gut sein das es eine Folge von Ladeschwierigkeiten war. Wenn man sich da unsicher ist, hilft es meist die beiden Audiospuren heraus zu extrahieren und sich das ganze in Audacity oder was weiß ich zu überprüfen. So Audio only.

Das sind so Kernprobleme oftmals. Die sollte man selbst dann prüfen und ausprobieren.

Und wieso sollte man mit einem GPU Encoder aufnehmen wollen? Die bringen nicht sonderlich viel. Eher das man bei denen noch Qualität einbüßen tut.
Vllt. noch was für Streaming auf Twitch und Co. zu gebrauchen. Aber so sehe ich kaum Vorteile an GPU Encoder. In der Beziehung sind CPU Encoder schneller.
Beim Rendern sind GPUs gut. Aber nicht bei Encodern.

Und vor allem wenn du mit MP4 Material hantierst und gerade diese H264 Files, die bremsen doch nur die Bearbeitungszeit im Schnittprogramm aus. Das ist als ob du dir selbst ein Trichter baust

Das Verschicken per Post dürfte das unkomplizierteste sein.
Daher USB, BluRay oder so eine Mini Festplatte einfach verschicken.

Eventuell sind diese BluRay-RE Disc noch interessant als Möglichkeit. 25GB bei SL und 50GB bei DL.
Dann braucht man solche Sachen wie USB nicht vergeben oder diese Mini Festplatten.

Und die BluRay-RE kann man dann auch wieder beschreiben.
Die Dinger können gut 1000mal wieder beschrieben werden.

Aber die sind recht teuer. Glaube so ein 5er Pack 50GB DL BluRay-RE kostet so im Schnitt 30 bis 40 €

Zitat von nhatlam96

Was für ne Bitrate sollte man nehmen?
Laut google support.google.com/youtube/answer/1722171?hl=de
für 1440p bzw. 1152p 60fps sind 30 Mbit/s empfohlen.
Wird die Qualität besser wenn ich stattdessen 50 Mbit/s nehme? Oder sind die 30 Mbit/s maximal?

Vergiss den Müll da.
Wenn du fixe Bitraten eingibst, bist du für jedes Video am Raten. Weil ein Rennspiel zB. mehr Bitrate benötigen tut als so ein SNES RPG Spiel.

Du solltest Qualitativ Encodieren mit einer konstanten Qualität. Dafür hat x264 auch den CRF drin. Der kümmert sich dann anhand eines Qualitätsfaktors den du angibst um die ausreichende Bitrate.
Dafür sollte ein CRF zwischen 18 und 26 für jeden passend sein.

Je kleiner der Wert desto mehr Qualität und je größer desto schlechter.

Für fixe Bitratenangaben sollte man in der Regel eher ein 2pass machen lassen, damit die Bitraten optimal verteilt werden können. Da haste also nicht viel gekonnt. Und schon gar nicht bei Spielevideos. Das nennt man dann Ineffizient.

Effizient ist bei x264 mit CRF (Constant Rate Faktor) zu encodieren. Damit fährst du besser für jedes deiner Videos für YT. Damit musste dir 0 Gedanken mehr über Bitraten machen. Weil wie gesagt werden sie via dem CRF Verfahren optimal bestimmt.
Mal hat das eine Video dann 1000kbit, weil unkomplexes Material und das nächste hat 60mbit, weil recht komplexes Material.

Bitraten selbst anzugeben und gerade bei Videos wo Spiele abgefilmt wurden enden meist in übertriebende oder untertriebende Angaben.

Ein SNES RPG Spiel benötigt z.B. keine 30mbit. Und bei nem Spiel wie Fallout 4 oder was weiß ich, ist die Frage ob 30mbit überhaupt ausreichen.

Denn eins solltest du bedenken: Dein lokales Video was du später auf YT hochladen tust wird als Quellvideo genutzt womit Youtube dann encodieren tut. Je besser das also ist, desto besser werden die Ergebnisse.

Daher muss man schon lokal drauf achten. ;D

Zitat von RealLiVe

VfW ist eine alte, eingeschränkte Technologie, die lediglich für AVI-Container ausgelegt ist. Und dieser Container unterstützt viele Features von modernen Codecs nicht oder nicht problemlos. Deshalb ist es eine gängige Empfehlung, Video und Audio dort getrennt zu behandeln und bei x264vfw den Workaround zu verwenden, dass er das Video separat speichert. Das ist aber bei Batch Rendering wieder problematisch.

Einfach in nen AVI Container schreiben lassen. Der Videostream ändert sich ja dadurch nicht. Nur der Container supportet einige Features des Streams nicht.
Das ist aber relativ irrelevant, da dem Stream nix passiert.
Und ummuxen muss er es so oder so. Denn in der AVI selbst ist ja dann immernoch der PCM Audio Stream.
Aber das kann man ja dann auch via Batch Prozess automatisieren lassen für alle Videos dieser Art.

Lokal gesehen kommt ein h264 nicht in ein AVI Container rein. Aber solange es Mittel zum Zweck ist und am Ende durchs Muxen eh wieder MP4 oder MKV oder was weiß ich wird, ist das egal. Solange die Streams nicht geändert werden ist das mit den Containern.

Zitat von Knackfrisch

So wie es aussieht, habe ich dann wohl alle Programme durch.

Sofern ich das hier mitbekommen habe, stellst du dir zu hohe Ansprüche und das mit einer recht kleinen Geduldsfaden.

Ich finde du regst dich zu schnell über die GUI auf, weil du zu viel von ihr erwarten tust. Auch das zwecks Effekte und Co das diese zB. keine Vorschau haben.
Da fehlt die Auseinandersetzung mit den Programmen.

Auch der Punkt mit der Encodierung und wie viel Zeit das ganze braucht bis es fertig ist. Hier fehlt die Geduld einfach oder das Verständnis einfach warum bestimmte Sachen so lange brauchen.

Eventuell kommen wir da weiter wenn du zwecks Encoding uns einfach mal deinen Workflow beschreibst und welche Einstellungen du triffst. Sonst kann dir keiner so recht helfen bei der Optimierung. Eventuell kann man bei dem ein oder anderen Schnittprogramm Geschwindigkeitsbremsen nehmen.

Und gerade für Youtube die deine Videos noch mal encodieren hängt vieles von der Auflösung und FPS ab welche Qualität du im Endeffekt für deine Videos bekommst. Dafür sollten sie aber lokal auf deinem Rechner schon recht sauber sein.
1080p60 bei einem Rennspiel mit viel Details würde dir auf Youtube buchstäblich zerlaufen.

Zitat von Decane

1. In der Command Line hatte ich bisher immer "--keyint infinite --min-keyint 1 --fps 60.000 --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --bframes 5 --partitions all" stehen. Kann ich das weiterhin verwenden oder muss ich deine Command Line benutzen? Und wo ist der Unterschied (klar lesen kann ich auch, aber was bedeutet das konkret).

Wird bei x264vfw genauso verwendet wie in MeGUI auch.

--keyint
Der maximale Keyframe Punkt für die GOP
infinite - Ein Keyframe (Schlüsselframe oder I-Frame) wird erst dann gesetzt wenn ein Frameübergang sich in exakt 40% (Standard) im Bild ändert. zB. sprunghaft von einer recht dunklen Szene in eine recht helle Szene geändert wird.
Ansonsten gilt für diesen Eintrag die Faustregel: FPS * 10
Sprich an sich müsste dann da stehen --keyint 600 bei einem Video für 60 FPS
Bei Infinite werden Keyframes gespart, was die Dateigröße reduziert. Dann existieren im Video relativ viele Referenz Frames noch.

--min-keyint
Der minimale Keyframe Punkt für die GOP
Steht er auf 1, so kann jeder Frame ein Keyframe sein, unmittelbar nacheinander.
Aber in der Regel nutzt man folgende Faustregel: FPS
Sprich an sich müsste dann da stehen --min-keyint 60 bei einem Video für 60 FPS
Wenn dort also eine 1 steht, dann sollte der maximale Keyframe Wert am besten auf Unendlich stehen

Für weiteres für diese beiden Argumente kannst du dich auch gern auf Wikipedia in Punkto GOP (Group of Pictures) auseinandersetzen.

--fps
Hier legst du die FPS fest die das Video haben soll.
Dies gibt man bei x264vfw mit an, da die Schnittprogramme oftmals die Eigenart haben die Videos in 30fps oder 25fps an die VFW zu senden und das Video somit langsamer werden. Dieser Eintrag ist sozusagen ein FIX dafür um das Video wieder zu beschleunigen, damit später auch alles Synchron bleibt.
Die Angaben kannst du machen wie du möchtest. Ob nun als reelle oder rationale Zahl oder als irrationale Zahl bleibt dir überlassen.

Beispiele für Eingaben:
60 FPS
--fps 60
--fps 60.000
--fps 60/1

29,97 FPS
--fps 29.970
--fps 30000/1001

Zum Thema Range und Colormatrix kannst du im Tutorial Bereich unter Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge dich anlesen.

--bframes
Legt fest wie viele B-Frames maximal hintereinander stehen dürfen. Bei 0 werden B-Frames deaktiviert.
Für gewöhnlich müsste man für diese Einstellung den Wert des Parameters für --b-adapt wissen, da sich das danach eigentlich richtet.
Kommt also drauf an was für ein Preset man mit x264 fährt. Ob Medium oder Slow, etc.
Der Standard ist meist auf 3 gelegt.
Ist b-adapt auf 2 (Optimal) eingestellt empfiehlt es sich den bframe Wert auf 4 bis 5 einzustellen.
Ist b-adapt auf 1 (Standard) eingestellt kann man den bframe Wert auch auf 16 einstellen.

--partitions
Legt fest welche Partitionsgrößen für Macroblöcke erlaubt sein dürfen.
Für Gewöhnlich braucht man diesen Parameter nicht mit angeben, da alle Partitionsgrößen bis auf p4x4 aktiv sind.
p4x4 wirkt recht selten auf positive Ergebnisse aus. Solange es deaktiviert ist, steigt die Encodiergeschwindigkeit.
Man kann aber auch mit --partitions all alle Größen nutzen. Ob das aber Sinnvoll ist steht im Raum. Limitiert in der Regel nur die Encodiergeschwindigkeit ohne sichtbare Unterschiede am späteren Video.

An und für sich würde ich dir folgenden Parameter empfehlen der passend für das Preset Medium und Slow sein sollte:
--keyint 600 --min-keyint 60 --fps 60/1 --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --bframes 5 --b-adapt 2
ODER
--keyint infinite --min-keyint 1 --fps 60/1 --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --bframes 5 --b-adapt 2

ODER du machst es ganz simple:
--keyint 600 --min-keyint 60 --fps 60/1 --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709

Die Kombination kannst du dir halt aussuchen. Der Kern des Parameters sollte aber soweit klar sein das fps, range und die Colormatizen Einträge mit BT709 so erhalten bleiben.
Denn BT709 wird von Youtube verwendet, genauso wie eine TV Range.

Was du mit den Bildern nun machst zwecks I und B Frames, ist dir überlassen. Sie wirken sich dann halt auf Dateigröße aus. Der Qualitative Unterschied sollte am Ende relativ schwer zu erkennen sein.
Gerade bei HD Auflösungen.

Zitat von BlueSky

Momentan gibt es auf YouTube ja H.264 und VP9, dass wird sich aber sehr schnell ändern, sobald der neue AV1 Codec draußen ist. Der sollte diesen Monat veröffentlicht werden, nach meinem Stand der Dinge.

Der ist schon seit 05.01.2017 draußen und kann verwendet werden.

AOMedia Video 1 von Alliance for Open Media
https://nwgat.ninja/test-driving-aomedias-av1-codec/

Für das Decoding entweder die LAV Filter patchen lassen. z.B. für den Player MPC-HC. Oder den beiliegenden CLI Decoder verwenden.

Das Ganze ist noch in Entwicklung, aber den Encoder dazu kann man schon nutzen. Der ist CLI Anwendung voll Einsatzfähig.

Die Frage ist aber... Kann YT H265 und AV1 auch verarbeiten? Weil wenn YT das nicht kann ist es zwecks dieser Plattform ungeeignet.
Für den allgemeinen Heimgebrauch kann man die beiden aber gerne verwenden.

Müsste mich auch mal mit diesen AV1 Codec auseinander setzen. Aber ich glaub kaum das YT diesen verarbeitet. YT hängt ja noch hinterher was H265 angeht.

@Unikat73
Der x265 wurde entwickelt um Videos bei weniger Bildverlust noch weiter zu komprimieren.
Das wird durch verschiedene Faktoren erreicht. Fakt ist aber das dieser Codec mehr Leistung und Zeit braucht gegenüber seinen x264 Kollegen.
Außerdem wird meines Wissens H265 Material nicht von YT erkannt und verarbeitet.
Also nicht nur die erhöhte Verarbeitungszeit allein die bei so ziemlich jeden Youtuber ein Dorn im Auge ist, sondern auch das Manko das YT es nicht schluckt.

Der passende äquivalente Codec zu x265 wäre VP9. VP9 hat auch sehr hohe Verarbeitungszeiten, weil er genauso wie x265 mit CRF arbeitet und auf Kompression und Qualität ausgelegt ist.
Und da VP9 von Google kommt, wer hätte es gedacht ^^, wird VP9 auch von YT erkannt und kann verarbeitet werden.
Naja, wenn selbst Youtube die Videos in VP9 sogar anbietet.

Aber bitte bedenken: VP9 hochzuladen auf YT ist keine Garantie für mehr Qualität. Man könnte ein x264 encodiertes Video und ein VP9 codiertes Video hochladen und beide sähen identisch aus. Mit dem Unterschied das x264 schneller lokal encodiert hat.

Wie gesagt: Für den lokalen Gebrauch zu Hause sind das gute Archiv Codecs für Videos. Für Let's Player die ohnehin oft unter Zeitmangel stehen sind das eher Zeitbremsen.

@De-M-oN
Kannst du diese Datei auf den Start Post verlinken: http://www.mediafire.com/file/…0g9nm/MeGUI_09_03_2017.7z

Das ist MeGUI auf den Stand vom 09.03.2017 mit allen Updates die MeGUI anbietet + NeroAAC 1.5.4 + FDK AAC 0.6.2
Auch die Plugins für DGindexNV und DGindexIM sind auf aktuellen Stand, nur ohne Lizenz Datei, da diese ja Kostenpflichtig noch sind.

Zudem sind NeroAAC und FDK AAC portable zu MeGUI eingestellt. Also keine Pfadangabe mehr notwendig.
Auch ist es komplett eingestellt was AVISynth Portable angeht und x264, sowie NeroAAC und FLAC.

Ich denke das würde einigen Neueinsteigern helfen die Probleme den Updates haben oder es nicht schaffen es auf den Development Server einzustellen.

Und zum anderen schlage ich es dir vor, weil auf deinem Startpost der NeroAAC Link nicht mehr geht, da dein Server down ist.

Bei der Größe müsste eigentlich so ziemlich jedes Plugin dabei sein. ö.Ö Naja, egal.

An sich fordert MeGUI aber auch die Plugins an, sofern du mit MeGUI schon gearbeitet hast richtig. Dann hätte er dir schon gesagt das er z.B. bestimmte Encoder haben möchte oder andere Sachen und hätte die Plugins für MeGUI automatisch gedownloadet.

Da du das nicht gemacht hast, hattest du noch die Basis Version wo nix ist.

Gleiches passiert wenn du eine Weile ein bestimmtes Plugin von MeGUI nicht nutzen solltest. Dann deaktiviert sich die Update Funktion dafür wieder.

Und dann muss man oftmals manuell da rumfuchteln um es upzudaten.

Besser ist aber alles upzudaten. Dann hat man wenigstens den vollen Umfang von MeGUI.

Außer für NeroAAC, FAAC, DGIndexNV und DGIndexIM.
Die muss man sich selbst besorgen wenn man da was machen will.

Aber da dürfte wenn überhaupt nur NeroAAC interessant noch sein.

Ist sowieso komisch. Dein MeGUI hatte noch nicht mal den x264 dabei gehabt. Da waren laut deinem Bild nur die Grundlegensten MeGUI Basis Sachen dabei, damit MeGUI überhaupt starten kann. Ansonsten war ja gar nix da.
Wo hast du dieses MeGUI überhaupt her gehabt? Aus dem Forum hier? Im Start Thread?