Beiträge von Kayten

    Was ich gefunden habe ist "Our high-end lossless 24-bit RGB captures occupy anything from 60MB/s to 200MB/s"


    Dann hast du eindeutig was falsch verstanden. Wenn man kurz sucht, findet man auch die Quelle dieses Satzes, welcher eigentlich nur besagt, dass die Bildqualität einer Elgato Capture Card verglichen wurde mit "high-end lossless 24-bit RGB captures". ^^
    Hier mal der ganze Ausschnitt:

    As you can see from the video and the comparison zoomers below, there is clearly a degradation of quality compared to the raw video output, but quality still holds up rather well overall and isn't really noticeable in motion. Our high-end lossless 24-bit RGB captures occupy anything from 60MB/s to 200MB/s (480mbps to 1.6gbps) that's depending on how well they compress from frame to frame. The HD60's outputs are locked at just 40mbps at its best setting - that's 5MB/s.

    Wahrscheinlich komme ich immer so unverständlich rüber, aber ich hoffe das ihr damit ja schon umzugehen wisst.

    Du liest nicht richtig, das ist alles. Du denkst, dass du missverstanden wurdest, obwohl das nicht der Fall ist.


    Für jeden der unterhalb von 4K aufnimmt und hochlädt wäre es allgemein sinnvoller Auflösung oder FPS zu erhöhen

    Den hervorgehobenen Teil hast du ignoriert. Ich weiß, sind nur zwei Wörter, allerdings lassen diese darauf schließen, dass ich sehr wohl an die Skalierung gedacht habe.


    Was meinste wäre aus meinem 320x200 Video geworden wenn ich es in YV12 aufgenommen hätte? Richtig, es wäre total verwischt ohne Ende.
    Schon bei einer Faktorenskalierung von 2x macht sich der höhere Farbraum Bemerkbar. Ersichtlich.

    Und zum Schluss: Ja, es gibt Ausnahmen, die hast du sowohl gezeigt als auch erwähnt, dessen bin ich mir bewusst.

    Schade, dass du diesen Teil zwar zitiert, aber nicht richtig interpretiert hast. Ja, ich sehe Videos, bei denen Skalierung dringend notwendig ist, als Ausnahme an. Als Ausnahme wo ein besserer Farbraum wie YUV444 oder RGB eigentlich zwangsweise notwendig ist.
    Ich habe niemandem geraten ein 320x200 Video in YUV420 aufzunehmen.

    Es ist sinnvoller die maximale Qualität des Videos auszureizen (1152p bis 1800p+) als die minimale (1080p und darunter) zu versuchen zu verbessern, denn die unteren Qualitätsstufen werden nicht plötzlich gut aussehen, nur weil man es nun gut meint und YUV444 Material hochlädt.

    Wozu ich stattdessen geraten habe, ist den Farbraum als unwichtigstes Element eines fertigen Videos für YouTube(!) anzusehen.
    Ob man letztlich sein wunderbar hochskaliertes Video nun auf YUV444 belässt oder nach der Skalierung nach YUV420 konvertieren lässt, ist für die Qualität auf YT nebensächlich. Auflösung und FPS haben Vorrang für die Qualität, nicht der Farbraum.
    Oder denkst du, dass >einem der beiden Videos< die zusätzlichen Informationen durch YUV444 einen nennenswerten Vorteil verschafft haben? Nein. Ist beides 720p-Pampe.
    Vielleicht ja in der >nativen Auflösung, 1440p<? Nein, auch da nicht. Technisch mag der Vorteil zwar vorhanden, aber in über 99% der Fälle nicht sichtbar sein.
    Wenn jemand sparen möchte beim fertigen Video, ist der Farbraum das Erste wo der Rotstift angesetzt werden sollte. Sei es nun aufgrund der längeren Kodierzeit oder der vermeintlich höheren Dateigröße, welche die Internetleitung zum Glühen bringt.
    Umgekehrt ist der Farbraum das Letzte, was für ein fertiges Video verbessert werden sollte. Wenn überhaupt.


    Bedenke nochmals, dass der vorherige Abschnitt sich auf das Endprodukt bezieht, nicht auf Rohvideos, welche skaliert werden. Die wurden schließlich schon weiter oben angesprochen.


    Edit: Wenn du nun denkst, dass ich dazu raten würde YUV411, YUV410 oder Y8 zu nutzen, muss ich persönlich bei dir vorbeikommen und dich schlagen. Ganz kräftig.

    Fazit ist aber das du weitaus mehr Bitrate rauskitzeln kannst, da ein I444 Video einfach besser und sauberer verarbeitet werden kann als ein I420 Video.

    Und genau das versuche ich eigentlich euch die ganze Zeit auch zu vermitteln.

    Du scheinst zu denken, dass man sich nicht für den technischen Hintergrund interessiert und das ist zumindest in meinem Fall schlicht falsch. Ich habe auch nie bestritten, dass der Qualitätsvorteil vorhanden ist. Im Gegenteil, sonst würde ich nicht die - für mich vernachlässigbaren - +7% extra Dateigröße für einen YUV444 Encode mitnehmen.


    Allerdings:

    Der Qualitätsunterschied ist vorhanden, aber ist er auch sichtbar im durchschnittlich komplexen Gameplay Material?

    bei einem richtigen Video geht dir das unter, weil du darauf keinen Bezug mehr nimmst mit dem Auge. Du würdest dann beide Bilder als absolut identisch empfinden, obwohl der Unterschied da ist.

    Da steht die Antwort auf meine Frage.
    Und bevor du nun wieder darauf plädierst, dass der Unterschied doch ein technischer Fakt ist, der von allen wieder ignoriert wird: Direkt in meiner Frage steht geschrieben, dass der Unterschied vorhanden ist, ich bin mir dessen also bewusst.
    Es geht um das Verhältnis von Kosten und Nutzen. Oder auch: Ist es das wert?
    Ich schaffe mir nun beispielsweise keine dritte Festplatte für mein RAID0 an, nur um dann "endlich" in 1800p 60FPS YUV444 aufnehmen zu können. Da stimm ich mit @Julien überein, nur würde ich es nicht indirekt abwertend als Qualitätswahn bezeichnen, sondern dass der Nutzen den Kosten nicht gerecht wird.
    Für jeden der unterhalb von 4K aufnimmt und hochlädt wäre es allgemein sinnvoller Auflösung oder FPS zu erhöhen, statt einen besseren Farbraum zu wählen. Es ist sinnvoller die maximale Qualität des Videos auszureizen (1152p bis 1800p+) als die minimale (1080p und darunter) zu versuchen zu verbessern, denn die unteren Qualitätsstufen werden nicht plötzlich gut aussehen, nur weil man es nun gut meint und YUV444 Material hochlädt.
    Und zum Schluss: Ja, es gibt Ausnahmen, die hast du sowohl gezeigt als auch erwähnt, dessen bin ich mir bewusst.

    Und dann... ist das auch klar: Ein YUV 4:2:0 -> YUV 4:4:4 ist das gleiche wie YUV 4:2:0
    Somit sind YUV 4:4:4 und YUV 4:2:0 identisch. Man hat dann halt den geringeren Farbraum in ein hören gesteckt ohne jeglichen Nutzen davon. Fazit: Die Dateigröße wird ähnlich, da der Inhalt sich schon gleicht. Und erreicht wird das dann durch die Kompression. Gleicher Informationsgehalt = gleiche Dateigröße. Egal in welchen Farbraum du es stecken tust ;D


    Schön und gut, aber warum erzählst du mir das?
    Meine Beispiele wurden nicht unnötig von YUV420 auf YUV444 aufgeblasen. Das Rohmaterial lag in YUV444 vor und wurde einmal mit x264 in YUV444 kodiert und einmal in YUV420. Dass ich mit diesen Beispielen bisher scheinbar ziemliches Glück hatte, möchte ich gar nicht abstreiten, da eine gerade getätigte Testaufnahme von mir in YUV444 kodiert tatsächlich mal in einer ~7% größeren Datei resultierte gegenüber dem YUV420 Gegenstück.
    Der Unterschied ist allerdings immer noch im einstelligen Prozentbereich und daher aus meiner Sicht... vernachlässigbar. Sobald Skalierung zusätzlich mit ins Spiel kommt (z.B. von 1440p auf 1728p via Spline36) wird der Unterschied logischerweise nochmals geringer.


    Der direkte Bildvergleich zeigt schon mal das bei einer niedrig eingestellten Auflösung von 720p schon Farbunterschiede auf.
    Erklärung: Beim Upload des I444 alias YUV 4:4:4 Farbraums sind mehr Infos erhalten geblieben, bei I420 alias YUV 4:2:0 nicht.


    Danke für den Vergleich, danach hatte ich schließlich auch mal gefragt.
    Einziger Einwand: Übliche Let's Plays sind keine Blackscreens mit feinen farbigen Kreisen oder Stresstests. Du zeigst den Worst-Case, zumindest ich interessiere mich allerdings eher für den Average-Case. Der Qualitätsunterschied ist vorhanden, aber ist er auch sichtbar im durchschnittlich komplexen Gameplay Material?
    Versteh mich nicht falsch, ich kodiere schließlich selbst fast immer in YUV444, es geht mir nicht ums "wollen" sondern eher ums "können" bzw. die Auswirkung. Mein RAID0 macht bpsw. kein 1800p 60FPS YUV444 Material mit, 1440p in YUV444 oder 1800p in YUV420 dagegen problemlos.


    Wie kann ich das verstehen ?


    Gemeint war damit lediglich, dass du - wenn dir die Geschwindigkeit der Kodierung wichtig ist - ein Video direkt in dem Farbraum aufnehmen solltest, in dem du es auch kodieren willst.
    Beispiel: Du nimmst in RGB auf und kodierst in YUV444. Diese Kombination wird (zumindest in AviSynth und MeGUI) deutlich langsamer sein, als wenn du bereits in YUV444 aufnimmst und auch in YUV444 kodierst.

    Zitat

    Warning: The OpenGL renderer is currently in use. On windows, the OpenGL renderer can decrease capture performance due to the lack of specific features used to maximize capture performance. The Direct3D 11 renderer is recommended instead.

    Den Renderer unter Erweitert so umstellen wie in der Warnung vorgegeben. Dort OpenGL zu wählen ist sinnloser Performanceverlust.


    Zitat

    Output 'adv_stream': Total encoded frames: 74532
    Output 'adv_stream': Total drawn frames: 74532
    Output 'adv_stream': Number of skipped frames due to encoding lag: 26 (0.0%)
    Output 'adv_stream': Number of lagged frames due to rendering lag/stalls: 14 (0.0%)

    Rest sieht ordentlich aus.


    Mehr Qualität als das dürfte bei gleicher Bitrate nahezu unmöglich sein, außer mir ist etwas Wichtiges nicht aufgefallen.

    Und da setzt der technische Hintergrund an.


    YUV 4:4:4 -> YUV 4:2:0 von YT ist besser als YUV 4:2:0 -> YUV 4:2:0
    Sofern man bei YT an die restlichen Auflösungen seines Videos denkt die gewiss skaliert werden müssen vom hochgeladenen Quellvideo.


    So viel zur technischen Sicht. Bleibt da letztlich auch visuell etwas von übrig? Ich hoffe immer noch auf einen Nachweis - gerne auch mit Einzelbildern - die zeigen, dass ein in 4:4:4 hochgeladenes Video auf YT irgendwie besser aussieht als das selbe Video in 4:2:0.


    Ich kann dir höstens soviel sagen das viele A nicht bevorzugen aufgrund des großen Speicherplatzverbrauchs der Videos.

    Die Aufnahme betreffend stimme ich da zu, bei der nachfolgenden Kodierung allerdings nicht, siehe Encoding-Talk. Und das war kein Einzelfall, sondern ließ sich problemlos mit anderen Videos reproduzieren. Der Dateigrößenunterschied zwischen einem YUV420 und einem YUV444 Encode ist lächerlich gering.
    Eine genaue Begründung dafür habe ich bisher nirgends gelesen. Die einzige Vermutung, die ich hätte, wäre folgende:
    Man habe "konstante Qualität" und das gleiche Video in 4:4:4 und 4:2:0. Nun wird beim ersten Video die konstante Qualität auf mehr Informationen "verteilt" als beim zweiten, wodurch die Qualität eben identisch ist, genau wie die ungefähre Dateigröße. Analog zum Prinzip von konstanter Bitrate, nur ist es hier eben keine konstante Bitrate, die auf eine unterschiedliche Informationsmenge verteilt wird, sondern eben konstante Qualität. Hierbei würde das erste Video allerdings nach einer Konvertierung in 4:2:0 (YouTube) qualitativ schlechter dastehen als das zweite.
    Ob das auch nur ansatzweise der Realität entspricht, wird bestimmt jemand mit mehr Erfahrung ( @Sagaras oder jemand anderes) beantworten können.


    @Karmaalp
    Vielleicht noch als Zusatz die Geschwindigkeit betreffend:
    Konvertierungen sind Geschwindigkeitskiller beim Kodieren, zumindest meiner Erfahrung nach bzgl. AviSynth und MeGUI. Siehe >hier<.


    Ich persönlich würde, wenn ich nicht skalieren täte, zu Variante C tendieren, ansonsten zu A. Variante B wäre mir zu ineffizient was die Nutzung von Ressourcen betrifft. Begründung wurde verlinkt.

    Es sollte dir klar sein, dass du zusätzlich zur Aufnahme des Spiels noch eine zweite Aufnahme laufen lässt, welche eben auch Last erzeugt. Letztlich hast du nun zwei Aufnahmen (Spiel und Webcam separat) im Gegensatz zu vorher, wo es nur eine war. Dass so der eigentliche Performancevorteil durch Dxtory wieder teils verloren geht, sollte nachvollziehbar sein.

    Ich kenne nur das OBS Tutorial mit der verlustfreien Aufnahme, welches meinst du?

    Genau das.

    Ich habe es jetzt mal mit 480p getestet, ich bekomme eine CPU Auslastung von ca 25% bei einem I7 4790K
    Hab ich da etwas falsch verstanden?

    Möglich? Wenn du OBS komplett auf 480p und 30FPS einstellst - also Webcam und Leinwand - und die Kodierung über UtVideo via FFmpeg laufen lässt, kommst du definitiv nicht auf 25% CPU Auslastung. Wie im oben angesprochenen Tutorial auch erwähnt ist die CPU-Lastanzeige in OBS Studio absolut unzuverlässig.


    Führt das immer noch nicht zum gewünschten Ergebnis, hast du aus meiner Sicht zwei Möglichkeiten:

    • Aufnahme der Webcam via AmaRecTV und MagicYUV.
    • Verlustfreie Kodierung der Webcamaufnahme via GPU über OBS Studio, da du eine GTX1060 besitzt.

    Ansonsten würde ich ganz einfach zu OBS Studio greifen und ausschließlich die Webcam dort aufnehmen lassen mit Einstellungen so gewählt wie im OBS Studio Tutorial. Mehr als 480p sollten für die Webcam eigentlich unnötig sein, außer du möchtest dich gerne mal flächendeckend als Hauptattraktion im Video haben.

    Ouh sry habs überlesen
    http://pastebin.com/Bb0RfpjR

    Ich seh da keinen Aufnahme- oder Streamversuch drin. Ohne das können wir nicht genau sagen woran es liegt, außer dass du das CPU-Preset auf medium oder höher stellen solltest. Kein Hexacore schafft slow in Echtzeit bei Twitch-üblichen Auflösungen. Die Bildqualität ist hauptsächlich von der Bitrate abhängig und wenn du diese aus diversen Gründen nicht erhöhen kannst sowie die Leistung deines PCs bereits ausgereizt ist, lässt sich da nicht mehr rausholen.


    endgültig von x264 (encoding auf der CPU) weg und hin zum Encoding direkt auf der GPU.

    Er möchte seine Bildqualität verbessern, nicht verschlechtern. GPU Encoding bei fester Bitrate sieht immer schlechter aus als CPU Encoding. Abgesehen davon ist seine CPU mehr als leistungsstark genug.

    Die Konvertierung von YV12 zu RGB - also einen niedrigeren in einen ... höheren Farbraum - kann deshalb verlustfrei ablaufen.

    Wenn man ganz genau sein möchte, ist auch dieser Vorgang nicht verlustfrei. Jede Konvertierung von RGB nach YUV und umgekehrt beinhaltet Rundungsfehler, auch wenn diese bei geringer Anzahl für das Auge nicht sichtbar sind.


    Was ich nur nicht ganz verstehe, wieso liest man dann überall, unteranderem auch hier in diesem Forum, dass der beste Encoder UTVideo ist und YV12 die beste Einstellung zum Aufnehmen? Kann es sein das unter brücksichtigung dieser Daten etwas 'Lüge' in diesem YV12 Mythos steckt?

    Das hat nichts mit "Lüge" oder Mythos zu tun. Zumindest ich würde UtVideo nicht in YV12 aufnehmen lassen, da UtVideo nach meinem letzten Wissensstand hierbei deutlich CPU lastiger ist als in YUY2, aber das nur am Rande erwähnt.
    Für die meisten wäre der Mehraufwand einer Aufnahme in YUV422, YUV444 oder gar RGB einfach unverhältnismäßig hoch. Warum in einem höheren Farbraum aufnehmen, wenn es von YouTube sowieso auf YUV420 (YV12) runtergerechnet wird? Die einzig sinnvolle Begründung: Du möchtest hoch skalieren. Je mehr Informationen vorhanden sind, desto besser schaut die Skalierung aus. Ganz allgemein formuliert: Du möchtest das letzte bisschen Qualität herausholen. Und das letzte bisschen Qualität ist nun mal unverhältnismäßig teuer zu haben - höhere Dateigröße, höhere CPU-Last, höhere Kodierzeit.


    Meine Videos habe ich früher erst in RGB aufgenommen, skaliert und anschließend in YUV444 kodieren lassen. Inzwischen nehme ich direkt in dem Farbraum auf, in welchem ich auch kodieren möchte, aufgrund von Geschwindigkeitsvorteilen dank wegfallender Farbraumkonvertierung bei der Verarbeitung. Heißt: Aufnahme in YUV444 > Skalierung > Kodierung in YUV444. Würde ich nicht skalieren - beispielsweise bei einer direkten Aufnahme in 1800p -, würde ich auch direkt in YUV420 aufnehmen. Einerseits weil mein RAID0 zu langsam ist für mehr, andererseits weil der Mehraufwand sich für mich da nicht lohnt. Eine 27-minütige Testaufnahme (1800p, 60FPS, YUV420) nimmt satte 282 Gigabyte ein. Mit YUV444 oder gar RGB wären es noch mal bedeutend mehr.

    Vor dieser Entscheidung stand ich auch, allerdings vor über einem Jahr, da war der 6700K noch deutlich teurer. ^^
    Wenn ich meine damalige >Entscheidungshilfe< betrachte liegt der 5820K bei Standardtakt knapp 6% vor dem 6700K, was sich - nach einiger Rechnerei, da nur 6700 ohne K - auch ungefähr mit dem deckt, was >hier< zu lesen ist.
    Übertakten lassen sie sich beide, der 5820K aber prozentual gesehen besser. Gegen die zwei extra Kerne des 5820K kommt der höhere Takt und die bessere IPC des 6700K nicht an. Erst recht nicht, wenn Übertaktung mit ins Spiel kommt.
    Wenn du den meisten Wert auf Rechenleistung legst: 5820K.

    Ich würde schätzen 20% + schneller beim Rendern.

    Schätzungen bringen gar nichts. Entweder Ergebnisse aus erster Hand oder Vergleiche anderer.

    Als Kühler will ich den Noctua NH D15.

    Zusammen mit einem 5820K wäre das genau die Kombination, welche ich selbst verwende. ^^

    Ob mein 600Watt Netzteil da reich...

    Genaue Bezeichnung und Daten des Netzteils posten, mein 480W Straight Power E9-CM von bequiet macht das scheinbar mit. ^^
    Was mir noch einfällt: Mein Netzteil bietet nur zwei 4Pin Anschlüsse für die Stromversorgung der CPU, X99 (2011-3) möchte generell aber insgesamt drei davon (1x 8-Pin EPS12V, 1x 4-Pin ATX12V). Funktionieren tut's bei mir bisher trotzdem.

    Ist das denn wirklich verlustfreies Material? Und ab welcher GPU Generation ist verlustfreies Material möglich? Bei AMD sind Informationen dazu scheinbar recht spärlich. Würde die Einstellungen des Screenshots sonst mit in das OBS Tutorial übernehmen.


    greift AMF vor DX ein

    Weder AMF noch NVEnc in OBS können vor DirectX etwas abgreifen. Bei AMF besteht zumindest die Möglichkeit, dass es noch implementiert und zugänglich gemacht wird, siehe >Github<. Hoffentlich entscheiden sie sich nicht die Display Duplication API von Windows zu nutzen, dann wäre es nämlich recht nutzlos. Macht OBS bereits um den Bildschirm aufzunehmen.

    ShotCut nutzt doch ausschließlich FFmpeg oder? Dann kannst du meines Wissens nach lediglich probieren die interne FFmpeg Version durch eine neuere zu ersetzen, falls das möglich ist, denn erst in einer neuen wurde ein MagicYUV Decoder hinzugefügt. Vielleicht reicht es ja auch ShotCut selbst zu aktualisieren.

    In dem Tutorial Video weiter oben wird gesagt das eine 1000er Bitrate ohne Puffer reichen würde!?


    Ist jetzt beides in dem Sinne richtig oder eins falsch!?

    Beides falsch, bzw. falsch verstanden.


    Laut YouTube brauche ich für das Format ja eine Bitrate von 16000 oder?

    Du "brauchst" keine Bitrate von 16000 um überhaupt Videos mit dieser Auflösung hochladen zu dürfen, das ist nur eine "Empfehlung" seitens YouTube, damit unbedarfte und unwissende Nutzer nicht YouTube ständig mit der Frage bombardieren in welchem Format und welcher Bitrate sie denn hochladen sollen. Wer Wert auf Qualität legt, sollte das aber getrost ignorieren und weitaus bessere Einstellungen nutzen.
    Die 1000er Angabe aus dem Video ist irrelevant, da dort letztlich ein anderes Verfahren greift, nämlich CRF. Ist der Puffer auf 0 gestellt und CRF eingetragen, wird die Bitrate ignoriert. Bei OBS Studio lässt sich das übersichtlicher einstellen.


    Evtl auch daran das ich es nicht Verlustfrei aufgenommen habe?

    Sicher, es kann schon, muss aber nicht. Verlustbehaftete Aufnahme kostet mehr CPU Leistung als verlustfreie. Wie gesagt: Log-Datei mit Aufnahme von OBS posten.

    Wenn man genau hinsieht mekrt man das es an manchen Stellen in dem Lets Play ruckelt bzw nicht flüssig ist.
    Wie kann ich das abstellen, auf meine OBS Einstellungen bezogen?

    OBS selbst bietet kaum bis keine Einstellungsmöglichkeiten an, die das beeinflussen. Daher: Programme zur Auslastungsüberwachung der GPU und CPU nebenbei laufen lassen (bspw. MSI Afterburner, GPU-Z, Open Hardware Monitor, Task Manager, etc.) und herausfinden woran es liegt.
    Abgesehen davon wäre die Log-Datei von OBS mit der letzten Aufnahme sehr hilfreich.

    @BlackLion768
    Die Methode klappt genau so wie vorher auch. Wenn es bei dir nicht geht, hast du dich nicht an das Tutorial gehalten. In der Container-Liste kann man herunterscrollen.


    @TheKarvon
    Mir wurde keine neue Nachricht angezeigt, da du die letzte lediglich editiert hattest. Bei den Einstellungen wundert es mich aber irgendwie nicht, dass du Probleme hast.

    • 1080p Auflösung, sowohl in der Aufnahme, als auch im Stream
    • veryfast-Preset, sowohl in der Aufnahme, als auch im Stream

    Der PC kodiert quasi 2 Streams gleichzeitig während gespielt wird, das kann mit einem Quadcore i7 nicht wirklich gut gehen.
    Was ich ändern würde:

    • 720p Auflösung im Stream
    • Entweder verlustfreie Aufnahme mit x264 wie im Tutorial (Variante 2) oder UtVideo (Variante 1)