Beiträge von Rafinoff

  • YouTube-Thread für kurze Fragen

    Zitat von De-M-oN

    Dailymotion kann mittlerweile 60fps Videos?

    Dailymotion scheint sich (welch Wunder) generell stark an YouTube zu orientieren, selbst 144p ist als Qualitätsstufe vorhanden. Und von der merkwürdigen Kanalgestaltung will ich gar nicht erst anfangen, dabei monieren sich alle immer über YouTubes (fragwürdige) Designentscheidungen.


    Nun stellt sich eben die Frage, ob es lohnenswert ist sein Material direkt auf 2160p zu skalieren (zumindest bei 16:9), um die maximale Bitrate herauszuholen. Durch die Limitierung der Bitrate wird Komplexes Material sowieso Defizite aufweisen. Bei meinen subjektiven vergleichen der Einzelbilder hat YouTubes 4K immerhin am "saubersten" abgeschnitten.

  • YouTube-Thread für kurze Fragen

    Um (mal wieder) auf die Bildqualität auf YouTube zurückzukommen:
    Ich habe in den letzten Tagen einige Ausschnitte aus "The Witcher 2" in verschiedenen Auflösungen auf YouTube hochgeladen, um die Qualität zu vergleichen, da ID 308 (1152p-1440p) und ID 315 (1728p-2160p) mutmaßlich leider qualitativ abgenommen haben.


    Aufgenommen wurde in 1440p@60 per MagicYUV im RGB Farbraum, transkodiert per x264 mit CRF 15 in YV24 (Rec.709). Falls skaliert wurde, wurde Spline16 verwendet. Die einzelnen Szenen sind verschieden komplex, und haben zum gleichen Resultat geführt. Für einen subjektiven Vergleich habe ich die Videos zudem per JDownloader heruntergeladen, und Einzelbilder verglichen.


    Alle nativ in 1440p@60 (ID 308) hochgeladenen Ausschnitte haben eine durchschnittliche Bitrate von ~13 Mbit/s erhalten. Die Ausschnitte in 3072x1728p@60 (Minimum im 16:9 Format für die ID 315 "4K") haben eine Bitrate von ~17 Mbit/s erhalten.


    Als ich ein paar Tage später einen Vergleich der Bildqualität zwischen YouTube und Dailymotion angestellt habe, habe ich Videos in nativem 1440p, als auch hochskaliertem 2160p hochgeladen. Hierbei hat Dailymotion bei 1440p@60 ~12,5 Mbit/s ausgegeben, bei 2160p@60 ~20 Mbit/s. Die gleichen Ausschnitte auf YouTube haben bei 1440p@60 abermals ~13 Mbit/s erhalten, die Ausschnitte welche auf 2160p@60 skaliert wurden jedoch ganze 26+ Mbit/s. Also 9 Mbit/s mehr, als die 1728p Videos, die ebenfalls ID 315 erhalten haben. Weitere Testvideos zwischen 1728p und 2160p haben sukzessive mehr Bitrate erhalten.


    Für den Test habe ich übrigens nur die VP9@HFR Kodierungen von YouTube beachtet. Dailymotions x264 Kodierungen sind YouTubes x264 Kodierungen selbstverständlich immer noch überlegen, im Vergleich zu den VP9 Kodierungen wird es jedoch schwierig. Wie zu erwarten war, ist die Kodierung von komplexerem Material auf allen Plattformen leider relativ enttäuschend, zumindest YouTubes native 4K Enkodierung gibt ziemlich hohe Bitraten aus. Trotzdem fehlt Beispielsweise 10 Bit Kodierung, welche einige Defizite kompensieren würde. Die Plattformen sind eben nicht auf komplexes Material, welches besonders bei Videospielen vorkommt, ausgelegt.


    Vimeo enkodiert übrigens per x264 auf CRF 20. Die Plattform ist jedoch für Videoproduzenten mit der massiven Ausgabe der meisten YouTuber (durch den limitierten Speicherplatz) uninteressant, und hat sowieso eine andere Zielgruppe (Cineasten etc.). Trotzdem wollte ich es angemerkt haben.


    Die Diskussion kann gerne im "Encoding-Talk" weiter ausgeführt werden, um den allgemeinen YouTube-Thread nicht vollzuspammen.


    Unten folgt die MediaInfo von zwei Videos, welche in verschiedenen Auflösungen hochgeladen wurden.


    MediaInfo:
    YouTube


    Video 1 - 1440p (YT ID 308)


    Video 1 - 1728p (YT ID 315)


    Video 2 - 1728p (YT ID 315)


    Video 2 - 2160p (YT ID 315)


    MediaInfo:
    Dailymotion

    Video 2 - 2160p


  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Ich kann auch bestätigen das alle Videos die ich seit dem 6. Juni hochgeladen habe in [lexicon]VP9[/lexicon], mit dem 308 Encode kodiert werden.
    Fragt sich eben immer noch wann die älteren Videos auch die 308/315 Encodes nachgereicht bekommen.
    Eventuell ist der Rollout auch noch nicht auf jedem Server angekommen, und daher kommt es noch vor das ein paar User die alten Encodes bekommen.


    Für Google Chrome wurde zudem auch ein neuer Video-Renderer entwickelt, mit dem die Videos auch in den hohen Auflösungen mit hoher Framerate flüssig laufen soll. Dieser ist bisher nur in der Dev Version enthalten, aber kommt später wahrscheinlich noch in die Stable Version.
    Wäre natürlich superb wenn die Videos generell auch auf schlechterer Hardware besser laufen würde!

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Ich habe schon länger das Problem, das in [lexicon]MeGUI[/lexicon] über den Auto Encode das Multiplexen fehlschlägt.
    Daher habe ich mich etwas erkundigt, und das ganze scheint wohl mit der Größe (?) des kodierten Videos und dem Speicher zusammenzuhängen. Und meine Videos sind gerne mal 10-20 GB groß.


    [lexicon]MeGUI[/lexicon] Log:


    Wichtig ist hierbei diese Fehlermeldung:
    --[Error] [03.06.2015 16:45:22] Error: memory.cpp/safemalloc() called from file src/common/mpeg4_p10.cpp, line 1074: malloc() returned nullptr for a size of 218543 bytes.


    Der Fehler scheint öfter bei einigen Nutzern aufzutreten, aber eine "Lösung" habe ich bisher noch nicht gefunden.
    Die Auto Encode Einstellungen sind auf "No splitting" & "No target Size" eingestellt, was soweit stimmen sollte. Zudem ist "Always mux [lexicon]mkv[/lexicon] encoding with mkvmerge" aktiviert.


    Den Audio- und Videostream muxe ich dann immer manuell in MKVMerge zusammen, was auch ohne Probleme funktioniert. Würde mich nur interessieren ob es ein "Workaround" gibt, oder ich mich bei den größeren Videos darauf einstellen sollte, das ich das Ganze hinterher manuell [lexicon]muxen[/lexicon] soll? Wäre natürlich nur halb so wild, aber doch ganz praktisch wenn das automatische [lexicon]Muxen[/lexicon] funktionieren würde.


    Wieder mal danke für eure Hilfe!

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Ich kodiere meine Videos nun schon länger im Farbraum YV24 bzw. YV16 (abhängig vom Material).
    Aufgenommen wird mit dem UtVideo [lexicon]Codec[/lexicon] 'YUV422', oder eben 'RGB'.
    Im [lexicon]SSM[/lexicon] habe ich für YUV 4:2:2 Aufnahmen Versuchen ohne Konvertierung als YV16 auszugeben, bei RGB YV24 Konvertierung der Videos eingestellt. avs4x264mod ist aktiviert, da ich in [lexicon]MeGUI[/lexicon] den 64 Bit [lexicon]Encoder[/lexicon] nutze.


    In der [lexicon]MeGUI[/lexicon] settings.xml habe ich <AskAboutYV12> und <AddConvertToYV12> auf "false" gestellt, damit der Input nicht zusätzlich zu YV12 konvertiert wird.
    Im [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] habe ich noch folgende Parameter angegeben:
    --output-csp i422 bzw. --output-csp i444
    Damit die Videos eben auch im 4:2:2 bzw. 4:4:4 Sampling kodiert werden.
    Sollte soweit hoffentlich stimmen. Im [lexicon]MeGUI[/lexicon] Log finden sich jedoch ominöse Warnungen.


    Hier der Log zum Encode:


    Das [lexicon]AviSynth[/lexicon] Skript ist auch im Log zu finden.


    Auffällig ist hierbei
    ---[Warning] [31.05.2015 02:00:20] resize [warning]: converting from yuv420p to yuv422p


    ---[Warning] [31.05.2015 03:35:34] avs [warning]: Converting input clip to YV12


    ---[Information] [31.05.2015 03:35:34] avs4x264 [info]: "D:\Programme\MeGUI_2418_x86\tools\x264_10b\x264-10b_64.exe" - --preset fast --crf 14.0 --keyint infinite --min-keyint 1 --output-csp i422 --sar 1:1 --output "D:\Videos\Codiert\GTA5 #041.264" --frames 60356 --fps 50/1 --input-res 2560x1440 --input-csp i420 (--input-csp i420)


    Soweit ich das richtig interpretiere heißt das, das mein Input in [lexicon]MeGUI[/lexicon] erst in YV12 (4:2:0) konvertiert wird, und danach in YUV422, da ich [lexicon]x264[/lexicon] durch den Parameter auf 4:2:2 Output gestellt habe. Mein Ziel ist es jedoch die YUV 4:2:2 Aufnahme auch im 4:2:2 Sampling zu kodieren, also habe ich entweder im [lexicon]SSM[/lexicon], oder [lexicon]MeGUi[/lexicon] etwas falsch eingestellt.


    Daher meine Frage: Liege ich mit meiner Interpretation soweit richtig, und was habe ich in meinem Workflow falsch eingestellt? Eventuell im [lexicon]SSM[/lexicon] YV16 Konvertierung der Videos einstellen?
    Soweit ich nachgelesen habe scheint das ganze eventuell auch mit der avs4x264mod zusammenzuhängen, welche ja nur YV12, YV16 und YV24 unterstützt, daher habe ich auch YV16 für meine aufgenommenen Videos im 4:2:2 Sampling eingestellt, das soweit auch stimmen sollte.


    Nach meiner Befürchtung wird das Video also erst in YUV420 konvertiert, und dann noch mal in YUV422, wie ich es dann auch als Output kriege.


    Und last but not least, die [lexicon]MediaInfo[/lexicon]:


    Die MKVMerge Version ist veraltet, da die Updates in [lexicon]MeGUI[/lexicon] dafür unbeabsichtigt bis eben deaktiviert waren.


    Ich denke damit dürfte ich genügend Informationen zu meinem Problem gestellt haben.


    Schon mal vielen Dank für eure Hilfe :)

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Ich hätte da mal wieder eine Frage um [lexicon]MeGUI[/lexicon] und [lexicon]Avisynth[/lexicon].
    Über 'AudioDub' kann man in das Skript direkt eine Audio-Spur einbinden und bearbeiten. Die wird auch direkt von [lexicon]MeGUI[/lexicon] ausgelesen, was ich sehr praktisch finde.
    In Zukunft würde ich gerne (unter anderem wegen Urheberrechts-Gründen, Stichwort "Ingame-Musik") noch zusätzlich meine Kommentar-Spur, und die Ingame-Spur im Video ablegen. Insgesamt also 3 Spuren: Einmal die abgemischte Kommentar + [lexicon]IGS[/lexicon]-Spur, dann zusätzlich die reine Kommentar-Spur, und die reine [lexicon]IGS[/lexicon]-Spur.
    Kann ich es irgendwie bewerkstelligen das ich alle 3 Spuren ins Skript schreibe, und diese auch direkt von [lexicon]MeGUI[/lexicon] ausgelesen und einzeln im Video abgelegt werden, oder sollte ich die Spuren einfach zusätzlich über "New Track" in [lexicon]MeGUI[/lexicon] einfügen? Wäre direkt über das Skript eben etwas komfortabler, aber wenn das nicht ohne weiteres möglich ist kann ich die Spuren auch einzeln in [lexicon]MeGUI[/lexicon] einfügen, würde wahrscheinlich nur unwesentlich mehr Zeit kosten.
    YouTube müsste ja die erste Audio-Spur aus dem Video auslesen, und die anderen beiden ignorieren. Wie gesagt würde ich die 2 anderen Audio-Spuren gerne für eventuelle spätere Nachbearbeitung direkt im Video ablege lassen.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von De-M-oN

    Hat mitm script nix zu tun. Der ändert einen Hex Wert in dem Header der [lexicon]Lagarith[/lexicon] Datei auf den gewollten Farbraum.


    @Sagaras
    Achso, jetzt ist mir auch klar was genau das Programm macht :)
    Werde ich später ausprobieren, klingt genau nach der Lösung meines Problems.
    Also nochmal danke, ich denke jetzt sollte auch alles wieder rund laufen, habe jetzt mehrere Möglichkeiten das Problem zu lösen ^^

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von De-M-oN

    Wenns deine [lexicon]HDD[/lexicon] verkraftet, kannstes gerne tun.


    Je nach dem welches Game ich aufnehme sollte das klappen :)

    Zitat von De-M-oN

    hat richtig eingestellt eh mehr performance bei einigen spielen.


    Stimmt wohl, [lexicon]Dxtory[/lexicon] soll leider in den neueren Versionen an Performance verloren haben (ob das irgendwie auch mit meinem Problem zusammen hängt weiß man nicht).
    Na gut, solange ich ohne Probleme aufnehmen und codieren kann bin ich froh.


    Zitat von Sagaras

    Warum wird dieser Vorschlag so außer acht gelassen? Ist das denn so zuwider?


    Natürlich nicht, ich hatte aber schon geschrieben das ich [lexicon]SSM[/lexicon] eben (noch) nicht benutze, zudem tritt der Fehler schon bei der Aufnahme auf da [lexicon]Dxtory[/lexicon] die Videos im falschen Farbraum anlegt.

    Zitat von Rafinoff

    Über [lexicon]SSM[/lexicon] könnte ich es auch probieren, ich denke darüber sollte es auch klappen die Skripte ordnungsgemäß zu erstellen.


    Vielleicht habe ich aber auch die Funktion deines '[lexicon]Lagarith[/lexicon] Set Colorspace' falsch verstanden? Ich habe gedacht dieser hilft erst bei der Skript Erstellung, tut mir leid falls ich da etwas falsch verstanden habe.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von De-M-oN

    Jap. Wobei das Video wahrscheinlich in YUV420 aufgenommen wurde (zumindest meine vermutung aus der [lexicon]bitrate[/lexicon] heraus, sofern du kein desktop aufgenommen hast)


    War eine 17 Sekündige Test-Aufnahme von Day of the Tentacle ^^

    Zitat von De-M-oN

    Sprich [lexicon]DXTory[/lexicon] geht bei dir davon aus das es einen RGB Header schreiben muss


    Ok, also sollte ich nun entweder
    1) mit dem '[lexicon]MSI Afterburner[/lexicon]' aufnehmen (sodass der Farbraum korrekt abgelegt wird)
    2) direkt in RGB aufnehmen (was sowieso für eine bessere Qualität sorgen würde)
    3) einfach mit dem Fehler leben und die Skripte weiterhin händisch anlegen (ist ja an sich egal ob ich sie selbst schnell tippe oder den Script Creator nehme)
    Über [lexicon]SSM[/lexicon] könnte ich es auch probieren, ich denke darüber sollte es auch klappen die Skripte ordnungsgemäß zu erstellen.
    Dann nochmals danke für die Hilfe. Jetzt ist mir wenigstens klar das es an [lexicon]Dxtory[/lexicon] liegt, und die Videos im falschen Farbraum angelegt werden. Wieso [lexicon]Dxtory[/lexicon] das macht sei mal dahingestellt.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Update: Ok, es wird noch kurioser. Habe [lexicon]Dxtory[/lexicon] eben nochmal neu installiert, und einen Aufnahme-Test mit '[lexicon]Lagarith[/lexicon]' gemacht. Das Video wird immer noch im falschen Farbraum angelegt, jedoch von [lexicon]MeGUI[/lexicon] normal geladen. Auch wenn ich mit '[lexicon]MagicYUV[/lexicon]' direkt in RGB aufnehme wird es von [lexicon]MeGUI[/lexicon] sofort angenommen.


    Wird langsam echt verwirrend. Nochmal in kurz: Wenn ich direkt in RGB aufnehme ([lexicon]MagicYUV[/lexicon], [lexicon]Lagarith[/lexicon]) wird es von [lexicon]MeGUI[/lexicon] ordnungsgemäß angenommen. Wähle ich zur Aufnahme YUV12 werden die Dateien im Falschen Farbraum angelegt (RGB). [lexicon]MeGUI[/lexicon] kann in dem Fall die [lexicon]Lagarith[/lexicon] Datei normal laden, die [lexicon]MagicYUV[/lexicon] jedoch nicht. Das verwirrt mich dann doch etwas.


    Zitat von GelberDrache92

    Bin ich gerade blöd oder stehen in der [lexicon]Mediainfo[/lexicon] im Videobereich keine Farbraumwert?


    Auch ich habe den Farbraumwert in der [lexicon]MediaInfo[/lexicon] nicht finden können.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von GelberDrache92

    Also wenn du selber eine Skript schreibst, lädt [lexicon]MeGui[/lexicon] die Datei?
    Wenn du ein Skript über denn Creator von [lexicon]MeGui[/lexicon] schreibst. lädt er die Datei nicht?


    Kurz gesagt ja. Wie Sagaras schon herausgefunden hat liegt es wohl daran das [lexicon]Dxtory[/lexicon] die Videos im falschen Farbraum ("Grey") anlegt, obwohl ich 'YV12' ausgewählt habe.


    Habe eben zum Test mit '[lexicon]MagicYUV[/lexicon]' und dem '[lexicon]Dxtory[/lexicon] [lexicon]Codec[/lexicon]' aufgenommen (über [lexicon]Dxtory[/lexicon]). Auch die mit '[lexicon]MagicYUV[/lexicon]' aufgenommene Datei kann nicht ohne weiteres in [lexicon]MeGUI[/lexicon] geladen werden, die mit dem '[lexicon]Dxtory[/lexicon] [lexicon]Codec[/lexicon]' schon. Wenn ich mit dem '[lexicon]MSI Afterburner[/lexicon]' aufnehme kann ich alle Aufnahmen ordnungsgemäß über den Script Creator öffnen. Auch '[lexicon]Lagarith[/lexicon]' wird im korrekten Farbraum angelegt.
    -> Daraus schließe ich das [lexicon]Dxtory[/lexicon] bei mir die Videos im Falschen Farbraum anlegt (warum sei mal dahingestellt), der [lexicon]Afterburner[/lexicon] legt die Videos korrekt an.


    [lexicon]MediaInfo[/lexicon] ([lexicon]Dxtory[/lexicon], [lexicon]MagicYUV[/lexicon] - wird nicht ohne weiteres von [lexicon]MeGUI[/lexicon] geladen)


    Zitat von GelberDrache92

    [lexicon]Mediainfo[/lexicon] und alle Skript (Selbst, [lexicon]MeGui[/lexicon] und [lexicon]SSM[/lexicon]) einmal bitte...


    Auch wenn das Problem wohl eindeutig bei [lexicon]Dxtory[/lexicon] liegt -
    Selbst angelegtes Script:

    AVISource("H:\Video.avi")


    Ganz simple, das ist das händische Skript welches von [lexicon]MeGUI[/lexicon] angenommen wird.



    Wie gesagt glaube ich das [lexicon]Dxtory[/lexicon] die Aufnahmen über die extern installierten Codecs ([lexicon]Lagarith[/lexicon], [lexicon]MagicYUV[/lexicon]) falsch anlegt. Der '[lexicon]Dxtory[/lexicon] [lexicon]Codec[/lexicon]' funktioniert ohne Probleme. Der [lexicon]Afterburner[/lexicon] legt alle Aufnahmen in allen [lexicon]Codec[/lexicon] korrekt an.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Ich frage mich nun mal des öfteren woran es liegt das etwas nicht funktioniert wie es soll. Die händisch geschriebenen Skripte funktionieren ordnungsgemäß aber der script creator funktioniert nicht, und die [lexicon]FrameServer[/lexicon] Datei wird gar nicht angenommen, das wundert mich eben. Das du hier nicht einfach die Lösung aus der Luft schnappen kannst ist mir klar, tut mir leid falls ich mit meiner Fragerei nervig rüber gekommen bin.
    Eine Glaskugel hast du nicht zufällig doch parat, oder? ^^
    Dann werde ich es eben mit '[lexicon]Lagarith[/lexicon]' gut sein lassen, bzw. einfach mal auf die anderen Codecs wechseln die sowieso performanter sein sollen.
    Damit hat sich mein Problem soweit erledigt.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von Sagaras

    Ja, RGB kann [lexicon]Lagarith[/lexicon] auch decodieren. Daher kann es [lexicon]AVISynth[/lexicon] auch verarbeiten.


    Die Sache ist eben die: Auch die 'RGB' Datei wird nicht ohne weiteres von [lexicon]MeGUI[/lexicon] angenommen...
    Erstelle ich selbst ein [lexicon]AVISynth[/lexicon]-Script manuell wird sowohl die "Grey-Datei" als auch die "RGB-Datei" von [lexicon]MeGUI[/lexicon] angenommen.


    Zitat von Sagaras

    RGB ist aber dann auch falsch dann, wenn du YV12 abgespeichert hast ;D Also hat dir wohl [lexicon]DXTory[/lexicon] das falsch angelegt die Datei.


    Dann wird es wohl daran liegen ^^
    Aber wieso [lexicon]Dxtory[/lexicon] das macht und scheinbar manchmal in 'RGB' anlegt, und manchmal in 'Grey' verstehe wer will.
    Ich werde später nochmal einen kurzen Test mit '[lexicon]MagicYUV[/lexicon]' und dem '[lexicon]Dxtory[/lexicon] [lexicon]Codec[/lexicon]' machen. Soweit ich mich erinnere wurde diese beiden im richtigen Farbraum angeleg


    Danke für deine Hilfe zu dieser späten Stunde, ich mache da später nochmal Tests um mich zu versichern das es an [lexicon]Lagarith[/lexicon] liegt.