[MeGUI]The colorspace of you clip is not YV12...

  • Ich kann dein Bild leider nicht sehen. Keine Ahnung, wie du versucht hast, das einzufügen, aber Inline-Base64 wird offenbar nicht zuverlässig unterstützt. Entweder verwende Anhänge im erweiterten Bearbeitungsmodus, oder lade ein Bild auf einen Internet-Bildhoster hoch, der sich nicht durch massenhaft Werbung finanziert und Direktlinks erlaubt (z.B. imgur oder frupic), und verlinke es von da.


    Ansonsten: MeGUI erzeugt recht ausführliche Logdateien, die man im Verzeichnis MeGUI\logs finden kann, die kannst du hier als CODE-Block einfügen oder in einem "pastebin"-Dienst hochladen oder als Textdatei anhängen. Wir müssten zur Problemlösung auf jeden Fall mindestens wissen, woraus die Quelldatei besteht und wie das Skript im Detail aussieht, das von MeGUI generiert wurde. DirectShowSource empfehlen wir übrigens grundsätzlich nur in Notfällen, wenn alle anderen Methoden zum Laden eines Films nicht funktionieren. Falls es eine AVI-Datei ist, kann AviSource sinnvoll sein, dann aber kann es nötig sein, eine explizite Konvertierung in YV12 einzufügen (ich nehme mal an, das würde mit "Yes" passieren, aber leider passiert das nicht in jedem Fall an der richtigen Stelle).

  • Nun ja, du kannst versuchen, den Befehl einfügen zu lassen. Interessant wäre aber die Ursachen zu finden. Das ginge nur mit dem Skript und Details zur Quelle. Wenn du z.B. ein AVI öffnest, das bevorzugt zu YUY2 oder gar RGB24 decodiert wird, dann wäre dieser Befehl möglicherweise schon vor dem Ende des Skriptes sinnvoll, nämlich kurz nach AviSource().

  • Reicht für Details nicht aus, erhärtet aber den Verdacht, dass bei der Decodierung in AviSynth ohne zusätzliche Parameter zunächst nicht YV12 aus AviSource() herauskommt, sondern etwas mit höherem Chroma-Subsampling. Wahrscheinlich also nicht ganz falsch, da auf "Yes" zu klicken.

  • Ja, müsste ich dann auch, den hab ich aktuell nicht installiert; ich weiß also selber nicht, wie er sich konfigurieren lässt, bzw. wie er bei dir für die Bildschirmaufnahmen konfiguriert ist. Wahrscheinlich lässt sich das relativ leicht mit einem AviSynth-Skript dieser Art feststellen:


    Code
    1. AviSource("Aufnahme.avi", audio=true) # ein existierender DateinameInfo()


    Dann sollte man an Text, der ins Bild eingeblendet wird, ablesen können, in welches Farb-Format ohne zusätzliche Parameter-Angabe bevorzugt decodiert wird (z.B. RGB24 / YUY2 / YV12). Und auch, welche Eigenschaften die Tonspur nach dem Decodieren hat. Die meisten effizient komprimierenden Videocodecs bevorzugen das Chroma-Subsampling 4:2:0 (Farbigkeiten U und V haben im Vergleich zur Helligkeit Y senkrecht und waagerecht jeweils nur halbe Auflösung), dem entspricht für unkomprimiertes Video der VfW-FourCC "YV12".


    Bei manchen VfW-Codecs kann man versuchen, direkt eine Decodierung in ein bestimmtes Pixelformat zu erzwingen, z.B.:


    Code
    1. AviSource("Aufnahme.avi", pixel_type="YV12", audio=true)


    Wenn der Codec das so decodieren kann, erhält man einen YV12-Clip. Wenn nicht, eine Fehlermeldung; dann muss man eben nachträglich in YV12 konvertieren lassen. Unter bestimmten Umständen kann das ohnehin vorteilhaft sein (z.B. bei Interlaced-Video).

  • Danke, LigH. Das script funktioniert leider nicht - ich erhalte folgende Fehlermeldung:

    So sieht das Script aus:

    Code
    1. AviSource("Aufnahme.avi", audio=true) # "C:\MSVideo\Urlaubfulli.avi"Info()


    Oder wahlweise:

    Code
    1. AviSource("C:\MSVideo\Urlaubfulli.avi", audio=true)
    2. Info()


    Ich habe aber in MSIAfterburner die config öffnen können für den Codec:

  • Also ein wenig in die Syntax von AviSynth einlesen hilft schon...


    Im ersten Fall hast du nur den Kommentar geändert, hast du gemerkt (Windows-Fehler 2 = "Datei nicht gefunden", weil es keine "Aufnahme.avi" gibt, dort hättest du einen existierenden Dateinamen verwenden sollen).


    Dein zweites Skript sieht besser aus. Bis auf eine Kleinigkeit: Windows-Fehler 3 = "Pfad nicht gefunden", weil in "C:\MSVideo\Urlaubfulli.avi" ein I fehlt: "C:\MSIVideo\Urlaubfulli.avi"


    Der Screenshot vom MagicYUV-Codec hilft weiter. Dort wird "Mode: YUV 4:2:2" angegeben, das entspricht YUY2. Für Aufnahmen aus der echten Welt ist das vernünftig. Für Mitschnitte von Computerspielen müsste man aber mit flacheren Farben rechnen, die auch an Kanten leicht ausgewaschen sein können.


    Vielleicht sollten wir nochmal das "warum" besprechen: Warum ist es nötig, etwas vom Bildschirm über Afterburner aufzuzeichnen, das im Original eigentlich ein "Urlaubsvideo" sein soll? Ich könnte ja verstehen, wenn man Computerspiele mit Afterburner mitschneidet. Aber wenn etwas schon ein Video ist, dann gibt es doch bestimmt direktere Wege der Umwandlung als über den Umweg einer Bildschirmaufzeichnung?

  • oh, ich Depp:


    Also ich habe das Video erstellt mit einem Tool. Dort sind hauptsächlich Urlaubsbilder, Übergänge, Animationen, und ganz wenig echter Film verwendet worden. Das Tool kann aber kein Video speichern, wie Powerpoint. Ich gebe das Video dann mit dem Tool wieder um es per Bildschirmaufzeichnung(MSIAfterburner) aufzuzeichnen. Vielleicht hätte ich ein passenderes Tool verwenden sollen. Aber selbst dort können ja viele gar nicht die Videodaten an einen Frameserver weitergeben, damit ich diese iin MeGUI encodieren könnte. Ich habe auch noch von keinem Videoschnittprogramm gehört, welches auch so gut encodiert wie MeGUI.



    Dort wird "Mode: YUV 4:2:2" angegeben, das entspricht YUY2. Für Aufnahmen aus der echten Welt ist das vernünftig.


    ..also kann man die Eingangsfrage mit "Ja" beantworten? Es handelt sich ja um kein Computerspiel, sondern um echte Bilder.

  • Warum ist der Interpolate when downsampling Haken nicht drin? ._.


    Glaub mir: Du möchtest den Chroma nicht via Nearest Neighbor konvertieren ... :x Dann ist nämlich jeder 2. Pixel farblos. Und bei PC Aufnahmen haste einen RGB32 Input. Also wird hier jeder 2. Pixel dir farblos gemacht, wenn auf YUV 4:2:2 gehst ohne interpolation.


    Der Haken ist standardmäßig drin und daher wunder ich mich, warum du den entfernt hast?


    Wenn du in YUY2 aufgenommen hast, würd ich diese auch behalten.


    Demnach würd ich in MeGUI auf NO drücken und bei x264 config in custom commandline:


    --output-csp i422


    eintragen. Dann behältste die Chroma Qualität von 4:2:2 bei. Wenn auch mit jedem 2. Pixel farblos. Würde ich vllt erneut aufnehmen..

  • So habe ich es eingestellt:


    wenn ich die Frage mit Nein beantworte kommt folgender Hinweis(welchen ich mit "Yes" beantworte):


    Das Video hat dann aber krasse Bildfehler, man kann nahezu nix erkennen(Bild aus Mediaplayer HC 1.7.10 64bit):

  • Erst mal unabhängig von den Bildfehlern...


    a) Preset "placebo" ist unvernünftig. Verschwendet viel mehr Zeit, als man noch Qualität gewinnen könnte. Langsamer als "slow" ist selten nützlich, und "very slow" sollte das Maximum sein, das man in Erwägung zieht.


    b) Tuning "animation" ist für Zeichentrick.
    _


    Wenn du nicht zu YV12 konvertieren lässt, dann ist der Hinweis von MeGUI richtig, dass du auf den Farbraum und zusätzliche Parameter selber achten musst; die entsprechende x264-Konfiguration scheint dafür richtig zu sein, wenn ich mich nicht irre. Die Art senkrechter Streifen, die du dann bekommst, ist aber ein Hinweis darauf, dass das Ausgabeformat nicht korrekt erkannt bzw. verarbeitet wurde. Um das nachzuvollziehen, fehlt mir aber im Moment die Zeit...

  • Ähm, nein. Mit "Zeichentrick" meint man vor allem, dass es größere Flächen mit wenig Details, dafür eher sanften Farbverläufen gibt, die aber durch deutliche Kanten begrenzt sind. In diesem Tuning kann es dir passieren, dass Bereiche mit wenig Details kräftiger weichgezeichnet werden, als dir lieb ist.



    Wenn es um eine Foto-Präsentation geht (wobei "einblenden" meist lediglich das Erhöhen der Helligkeit von schwarz bis normal bedeutet, du hast aber wahrscheinlich Transitionen, also "hineinschieben" oder noch verspielter), dann würde ich wohl eher auf den Grain-Modus setzen, der die Filterung eher verringert und dadurch feine Details besser erhält (wenn auch mit höherer Bitrate). Aber du testest ja noch...