Beiträge von GelberDrache92

P.s. Es ist kein Problem von Sony Vegas mit Shadowplay, sondern von Shadowplay mit Videobearbeitungsprogramme

Ffmpeg ist bereits in OBS enthalten

Oder man nutzt verschiedenen Szenen, anstatt verschiedene Quellen (was De-M-oN meinte) und diese kann man dann sogar per Hotkey wechseln

Unter CRF 18 sieht man lokal keinen Unterschied, alles was unter CRF 18 7st kommt nur dem Encoding von YouTube zugute.

Das ist ein Faktor den du wieder austesten musst, ob dir die hohere Geschwindigkeit was bringt oder ob es durch die größere Datei aufgefressen wird.
Das Encoding, was Geschwindigkeit und Dateigröße angeht, muss jeder für sich austesten.
Genau so kannst du auch du B-Frames auf 0 stellen und den CRF dann auf 18, durch den höheren CRF müssten die Dateien dann sogar kleiner als vorher werden, obwohl die B-Frames auf 0 sind.

Wie man lokal im Video hin und her springen kann ist von dem I-Frames abhängig und diese sind über den GOP geregelt.
Die B-Frames sind hauptsächlich wenn nicht sogar nur für die Kompression wichtig.

Zitat von Kayten

Das Auslassen der B-Frames würde die Dateigröße erhöhen, wenn ich mich nicht irre.

Jop, aber umso komplexer das Video ist umso geringer ist der Effekt der B-Frames auf die Dateigröße und der Geschwindigkeitsunterschied ist nicht gerade ohne, da sie doch einiges an Leistung brauchen.

Hast du schon die bframes auf 0 gestellt?

Dateigröße wird nicht wirklich gespart, ich glaub zwischen YV12 und YV24 sind es nur etwa 10% Unterschied, so war das also bisher bei mir.
Aber wenn ich schon in 444 aufnehme, würde ich auch in 444 hochladen, damit die Resizer von Youtube noch davon profitieren.

jop, aber warum willst du das machen? o.o

Schöner Bug, das ist dann natürlich kein Wunder das der Encoder nicht hinter kommt xD
Dann kann ich wohl noch mal alles mit der 0.15 Version jetzt testen xD

Zitat von Kayten

Für das interne x264 hat die Wahl des Farbformats quasi keine Bedeutung und lediglich NV12 und i420 sind von Belang. Wenn du nun aber genauere Informationen hierüber möchtest, müsstest du im Forum schauen, Sagaras hat das schon irgendwo niedergeschrieben.
Erst wenn über FFmpeg kodiert wird, wird dem jeweiligen Encoder das Material direkt übergeben, welcher es dann entsprechend verarbeitet.

Ähm nein...
Man kann auch in i444 aufnehmen...

So und jetzt denkst du mal genau darüber nach was wir geschrieben haben und gehst mal in den tools Ordner von MeGui und öffnest den x264 Ordner und was sieht man da... genau x264_64.exe

Und jetzt hör mit dem mimimi auf...

Die laufen aber in unabhängigen Prozessen und haben dann mit MeGui selber nichts mehr zu tun.

MeGui ist nur eine grafische Oberfläche, daher komplett unbedeutend.

Der x264 sollte eigentlich schon als 64 Bit laufen, wenn noch Avisynth in 64 Bit laufen würde, das wäre gut, aber die Resizer und so laufen bisher nur unter 32 Bit.

Zitat von WoBra

Zu 2.: Dann lasse ich das so wie du gesagt hattest, so wie du sagst ist der h.264 ja dann verlustbehaftet.

Der x264 kann auch Lossless, mit dem qp=0 Parameter, aber bestimmte Programme können das benötigte High 4:4:4 Profil nicht öffnen.

Zitat von WoBra

Zu 3.: Ich streame ja auch in 720p und nehme dann in 1080p auf. Denke mal das 720p für einen Stream reicht, oder?^^ Von daher reicht ja die Bitrate von 2500.

Man sollte sowieso in 720p streamen, auch wenn man eine höhere Bitrate nutzt, da man dann einfach pro Pixel mehr Bits zur Verfügung hat, was die Qualität verbessert.

Zitat von WoBra

Den Keyframeinterwall hab ich nicht auf 0 da es ja zb Twitch =2 und Hitbox = 1 verlangt. Hatte beim letzten mal auch 0 aber auch nur weil ich über Restream auf 3 Plattformen gestreamt habe und nicht wusste was ich sonst einstellen sollte^^

Wenn man den Keyframeinterwall auf 0 hat, bedeutet es unendlich, was nicht fürs streamen geeignet ist, zudem ist es auch eine höhere CPU Belastung als 1 oder 2.
2 ist ein sehr guter Wert, da man hier dann bei gut komprimierbaren Spielen noch mal ordentlich was rausholen kann an Qualität.

@Sagaras Nein das bleibt auf CBR, der Uploud passiert in Echtzeit und ist damit nicht schneller, zudem kann es dann auch passieren das er durch VBR über die Bitrate kommt die sein Uploud schafft oder das die Zuschauer andauernd puffern müssen.

Stream ≠ Aufnahme

@Sagaras ich glaub beim x264 konnte man Videos nicht mal zusammen muxen, wenn diese nicht den gleichen CRF haben.

Also...
1. In eine Datei kommen nur Video-/ Audiostreams mit der gleichen Einstellung.
2. Pro Job wird eine Datei angelegt.
Das heißt wenn man zwei verschieden Einstellungen haben möchte, muss man zwei verschiedene Dateien haben, also warum sollte der Encoder wärend eines Jobs die Einstellungen ändern, wenn man sowieso zwei Jobs braucht, damit zwei Dateien erzeugt werden?

Weil bei einem Encoding die Sachen in einer Datei landen und diese müssen die gleichen Einstellungen haben.
Wenn ich zwei Videos mit verschiedenen Einstellungen haben möchte, dann müssen diese in zwei verschiedene Dateien.
Dementsprechend macht es keinen Sinn.