JM Software - Output fehlerhaft

    Hallo Forum,

    ich teste zur Zeit die Referenzsoftware für H.264, die JM Software.
    Leider hat der Output merkwürdige "Effekte". das .264 kann ich in Playern (zB VLC) gar nicht erst öffnen, die Debug-Ausgabe (.yuv) sieht ganz merkwürdig aus.
    Verschiedene Configs, auch verschiedene Profile habe ich gestetet. es gibt unterschiedliche Fehler, jedoch klappt es nie richtig....

    Die Testsequenzen habe ich von http://media.xiph.org/video/derf/

    Ich hoffe, jemand von euch hat Erfahrung damit und kann mir sagen, wo das Problem liegt. Ich würde vermuten, dass der Input falsch eingelesen wird (Inkompatibles Subformat oder so?! gleitz.info/index.php?attachment/97640/)

    Al Beispiel habe ich den debug-Output von foreman_qcif_mono.y4m und foreman_qcif.y4m angehängt sowie den h264-output von foreman_qcif.y4m, alle über Main Profile in JM codiert

    Viele Player kommen mit "rohen" AVC-Videos (*.264) nicht gut klar, sie erkennen den Videostream nur in einem Kontainer, z.B. MP4 (mit MP4Box erzeugt) oder MKV (mit mkvmerge erzeugt).

    DGIndexNV konnte die Datei öffnen, zeigt aber verschobene Farben und falsche Dimensionen an, das Video läuft von Bild zu Bild seitwärts durch. Wahrscheinlich stimmt da etwas nicht mit den übergebenen Hinweisen auf Breite und Höhe der YUV-Quelle bei der Encodierung.

    1. Warum postet man über einen http://bugmenot.com/ Account in einem Forum welches weder Spam verschickt noch Webeeinblendungen hat?
    2. VLC ist nicht gerade ein guter Player um RAW zu betrachten.
    3. Kann das .264 file ohne Probleme öffnen (hab es Dir mal in einem mp4 container gekapselt angehängt, dann kommt auch der VLC damit klar) und ja es sieht so aus, als ob Du bei der Übergabe an den JM bzw. bei dessen Einstellungen bzgl. der Farbraumdarstellung oder der Auflösung etwas falsch gemacht hast. (ohne die Auflösung und das verwendete sampling der YUV files zu kennen ist ein dekodieren nur möglich wenn man erst mal ausprobiert um was es sich da handelt,..)
    -> vermute Du hast JM 4:2:2 Material gefüttert, im das aber nicht gesagt, weshalb dieser vermutlich von 4:2:0 Material ausgeht, mehr kann ich so aus dem Bauch heraus auch nicht sagen, da es schon einige Jahre (5+) her ist, dass ich mir den JM H.264 Referenzencoder angeguckt habe,...

    Cu Selur

    Bmn-accounts ersparen einem die Registrierung und zudem ist man "anonymer". Ich nutze die fast überall - das hat nichts mit der Vertrauenswürdigkeit des Forums zu tun.

    Das "ohne Container"-Problem hatte ich schon vermutet, danke für die Bestätigung.

    Danke auch für die Ratschläge. Breite & Höhe stimmen, Ein schneller Versuch, für das Mono auf 4:0:0 zu setzen änderte das Ergebnis nicht. Für das farbige bleibt das Ergebnis in 4:2:2 auch das selbe - abgesehen davon, dass ich auf high profile konfigurieren musste und der output daher größer ist.

    Ich weiß ja nicht, welches Video du dir da gerade anschaust, Goldi, aber sicher nicht die im ersten Beitrag verlinkte JM.7z mit dem Vorarbeiter.
    __

    Benutzerkonten sind wie Unterwäsche oder Lebenspartner: Man verborgt sie nicht, jemand anderes könnte sie "beschmutzen"...

    Ja, Bildanhänge kann man mitten in den Fließtext einfügen; sonstige Anhänge sollte man separat angehangen lassen, das ist auffälliger. Ich weiß aber nicht, ob der Anhang verloren geht, wenn man jetzt den ATTACH-Link aus dem Text entfernt, oder ob er wieder darunter erscheint, weil er dann nicht mehr im Text ist...

    Nun ja.

    Zwischen verschiedenen AviSynth-Versionen und ihren Plugins gab es auch mal so ähnliche Fehler, als sich das "skewing" geändert hatte. Keine Ahnung, was das im Einzelnen bedeutete, die ausgetauschten Frame-Daten waren da eventuell breiter als der sichtbare Bildanteil, was eben beide Beteiligten wissen müssen.

    Seit die technisch wirklich ausgereiften H.264-Encoder auch bessere Möglichkeiten zum Lesen von Videoquellen haben, dürfte Y4M hier nicht mehr besonders verbreitet sein, entsprechend wird sich die Erfahrung damit wahrscheinlich auf die wenigen beschränken, die auch unter Linux Videos konvertieren...

    Zitat

    Selur...Deine Version von Hybrid_2013.05.18...hast Du uns aber noch nicht zur Verfügung gestellt.


    Nope, aktuell ist bei mir auch 2013.05.21 :D warte noch auf Feedback von zwei Usern bzgl. fixes. Aktuelles Changelog gegenüber der letzten veröffentlichten Version findet man immer bei: http://forum.selur.de/topic22-infos-…xt-release.html

    -------
    Zum Thema des Threads:
    Denke was bei der anonymen Suzanne genau schief geht kann man wohl nur klären, wenn die Dame / der Herr / das Wesen genauer mitteilt wie seine Vorgehensweise ist.
    Sieht zumindest für mich nicht wie ein Bug im JM oder an sich inkompatible Formate sondern eher nach falschen/fehlenden Parametern aus.

    Cu Selur

    Nach diversen tests hat sich gezeigt, dass das Hauptproblem wohl die Bittiefe war (Standard 8Bit). Mit 14Bit schiebt sich nichts mehr durchs Bild. Ob 4:2:0 oder 4:2:2 macht keinen Unterschied soweit ich das sehe. jedoch gibts in allen Fällen noch Artefakte....

    gleitz.info/index.php?attachment/97650/
    gleitz.info/index.php?attachment/97651/
    gleitz.info/index.php?attachment/97652/

    Wie kann man die Farbtiefe und downsampling-rate (außer durch ausprobieren) herausfinden?

    Einmal editiert, zuletzt von Suzanne (21. Mai 2013 um 08:33)

    :grübeln: Wie kommt man auf 14 bit?

    Wenn man nur eine Luminanz-Ebene mit 8 bit pro Pixel-Helligkeit hat, sollte der Fall trivial sein.

    Bei RGB24 hat man drei Komponenten "gepackt" mit je 8 bit, also drei direkt aufeinander folgende Bytes für 24 bit pro Pixel; auch simpel.

    YUY2 oder UYVY sind Varianten für YUV 4:2:2 "gepackt", bei denen sich zwei benachbarte Pixel je einen Wert der beiden Farbdifferenzwerte teilen; (2Y + 1U + 1V) : 2 Pixel ergibt im Durchschnitt 16 bit pro Pixel.

    YUV 4:2:0 wird üblicherweise "planar" verwaltet, also alle Helligkeiten als ein Block und jeweils die beiden Farbdifferenzen mit halber Breite und Höhe als je ein Block; dabei ergibt sich durchschnittlich für je 2x2 Pixel als Quadrat eine Datenmenge von (4Y + 1U + 1V) : 4 Pixel = 12 bit pro Pixel.

    Bei 14 bit müsste dann noch eine Ebene mit ähnlicher Auflösung wie U und V hinzukommen, oder? Soll dass dann Transparenz sein, oder Verarbeitungshinweise, oder höhere Genauigkeit für die Helligkeit (10 bit je Y)?

    "Ausprobieren" ist da sicher nicht der sinnvollste Hinweis. Es sollte statt dessen eher gemeinsam mit dem Rohmaterial dokumentiert sein.

    Zwischen YUV 4:2:2 und YUV 4:2:0 muss es zwangsläufig Unterschiede geben. Schon allein wegen der unterschiedlichen Verwaltung: "packed pixel" vs. "planar".

    Ich kann dir nur sagen/zeige, wie der Output aussieht. Zwischen 4:2:0 und 4:2:2 (als Input-Setting) gibt es praktisch keine Unterschiede (im Output). Ich verstehe ehrlich gesagt auch die Bezeichnung 4:2:0 und 4:2:2 nicht so ganz. Wenn ich mir https://de.wikipedia.org/wiki/Farbunter…eichnungsschema anschaue, werden bei 4:2:2 die Werte "gemittelt" und bei 4:2:0 ausgelassen. Die Erklärung A:B:C führt bei mir aber zu Verwirrung, da die untereste Zeile genauso viele Pixel enthält wie die oberste (2 "halbe" Pixel)
    Aber zur Prxis:

    Mit 8 Bit (Luma+Chroma) rutscht das Bild durch und die Farbinformationen sorgen nur für Schlieren von Farbe, bei 14Bit sieht das reconstructed zumindest "normal aus". Die Ausgabe von

    Zitat


    mkvmerge -o test.mkv test.264

    kann wieder der VLC nicht abspielen und der MPC zeigt etwas, was nur sehr entfernt an den original-Input (und das test_rec) erinnert.

    Zitat

    Es sollte statt dessen eher gemeinsam mit dem Rohmaterial dokumentiert sein.

    Meiner bescheidenen Meinung nach sollte das aus der Datei selbst hervorgehen. Im Header steht ja zB die Auflösung drin - die Abtastraten aber offenbar nicht.
    Merkwürdig finde ich auch, dass wenn man die Farbvariante als 4:0:0 einspeist, das Bild nicht s/w wird, sondern lediglich Artefakte enthält

    Die Mono-Variante hat rechnerisch knapp über 8bit/pixel (wenn man sich die Datei binär anschaut und rechnet).

    Ich möchte das Ganze gerne verstehen, wälze aber seit Tagen Manuals und fühle mich nicht wirklich schlauer - besonders, wenn du mir jetzt sagst, dass die 14Bit-Einspeisung richtiger "aussieht", obwohl sie dMn nicht richtig ist?! Alle anderen Kombinationen von 8-14 und 8-14 (Luma bzw Chroma) sahen noch schlimmer aus.


    EDIT
    Im YUV Player Deluxe spielt der Input gar nicht vernünftig ab, sondern slided auch durchs Bild und sieht aus wie das Ergebnis mit 4:2:0 und 8 Bit.
    Vermutung: YUV hat die FRAME-Struktur nicht, die YUV4MPEG hat. Somit werden diese Stellen als Daten aufgefasst, die zu Artefakten führen.
    Das erklärt für mich noch immer nicht, wieso das 8Bit 4:2:0 YUV(4M) (was es ja scheinbar ist) als 14Bit YUV interpretiert besser aussieht als interpretiert als 8Bit YUV.
    Bleibt auch die Frage ob/wie man YUV und YUV4MPEG "konvertieren" kann...

    YUV ist tatsächlich etwas anderes als Y4M (YUV4MPEG2): In YUV-Dateien ist nur der reine Bildinhalt, ohne zusätzliche Informationen; ein Anzeigeprogramm kann also ohne zusätzliche Einstellungen oder Header-Dateien nicht wissen, welche Breite, Höhe oder Farbkonfiguration darin gespeichert ist. In einem Y4M-Datenstrom dagegen sind tatsächlich noch weitere Informationen über den Bildinhalt hinaus enthalten.

    MultimediaWiki: YUV4MPEG2

    Was die unterschiedliche Speicherung angeht, versuche ich das noch mal für dein Beispiel mit QCIF-Auflösung zu erklären:

    a) YUV 4:2:2 wird mit der Methode "packed pixel" gespeichert, also Helligkeit und Farbigkeit weitestgehend zusammenhängend, fast pixelweise von links nach rechts in jeder Zeile, und von oben nach unten zeilenweise, bei YUY2 in der folgenden Reihenfolge:

    • die Helligkeit Y des ersten Pixels links oben;
    • die Blau-Gelb-Abweichung U (Cb) der ersten beiden Pixel als Durchschnitt;
    • die Helligkeit des zweiten Pixels rechts neben dem obersten linken;
    • die Rot-Grün-Abweichung V (Cr) der ersten beiden Pixel als Durchschnitt


    und so weiter für die nächsten beiden Pixel, für 88 Pixelpaare je Zeile, für 144 Zeilen.

    b) YUV 4:2:0 wird mit der Methode "planar" gespeichert, also Helligkeit und Farbdifferenzen separat für das gesamte Bild und nacheinander, bei YV12 in der folgenden Reihenfolge:

    • 176x144 Helligkeitswerte Y
    • 88x72 Rot-Grün-Abweichungen V (Cr)
    • 88x72 Blau-Gelb-Abweichungen U (Cb)

    Die ersten vier Bytes enthalten also bei YUY2 Helligkeiten und Farbigkeiten für die ersten zwei Pixel, bei YV12 dagegen die Helligkeiten für die ersten vier Pixel, aber noch längst keine Farbigkeitswerte (die kommen erst nach 176x144 Bytes Helligkeit bzw. weiteren 88x72 Bytes der einen Farbdifferenzkomponente).

    nur mal so am Rande:
    Zumindest beim jm18.5 steht in der Readme:

    Zitat

    3. Input/Output file format
    ---------------------------

    The source video material is read from raw YUV 4:2:0 data files.
    For output the same format is used.


    -> was anderes als RAW YUV 4:2:0 an lencod zu füttern, ist also vermutlich ne dumme Idee,...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden