Suche Entwickler für die Entwicklung eines Smush Video Dekoders

  • Da ich großer LucasArts Fan bin und mich die älteren Games durchs Leben begleitet haben, bin ich jetzt als Hobby Informatiker an dem Punkt wo ich gerne die Videos auslesen würde.

    Die Rede ist von Smush Animation oder auch kurz SAN bzw. SNM. Wenn sie verzippt sind werden sie von LucasArts auch ZNM genannt.

    Ich habe das Internet auch schon durchforstet und die brauchbare Links gefunden:
    https://wiki.multimedia.cx/index.php?title=SAN
    https://github.com/clone2727/smushplay
    https://www.ffmpeg.org/doxygen/2.3/smush_8c.html
    https://www.ffmpeg.org/doxygen/2.3/smush_8c_source.html

    Auch eine DLL Variation die es eventuell auslesen lassen kann habe ich gefunden:
    http://jsg.id.au/scumm/smush.txt

    Jetzt kommt aber das Problem was ich habe. Einige Lucas Arts Smush Files werden nicht richtig dekodiert. Audio sei jetzt mal dahingestellt, weil mir geht es erst mal nur um die Frames an sich.

    Als nächstes habe ich solch eine SAN Datei zerlegt mit HxD
    Was auch ganz einfach ist bei einer Big-Endian Speicherung.

    Erst kommt die nötige Header Bezeichnung 4 Byte, dann die Größe dessen mit 4 Byte. Legt man auf der ausgelesenen Größe die 8 Byte drauf für Header und Dateigröße, hat man die Größe der einzelnen Elemente. Also ganz Easy.

    Nur ist mir die Dekodierung nicht ganz klar wie ich das umsetzen soll.

    Die Bilder scheinen aus 256 Farben zu bestehen und am Anfang steht die Palette.

    Sprich der AHDR Header und das was unter ihm läuft beherbergt die Paletten Definition für die optimale 256 Farbpalette.

    Und dann geht es los mit FRME

    FRME = Frame

    1 FRME beinhaltet sowohl ein Frame Object FOBJ (Sprich die Bilder) und ein IACT (iMUSE Audio)

    Den Audio Part kann ich mit Scumm Revisited dekodieren.
    Der spielt dann auch mehrere Samples unter diesem 1 FRME ab.

    Also gehe ich davon aus das dieses Frame Object FOBJ auch mehrere Bilder haben müsste.


    Jetzt dekodiert das aber FFmpeg total komisch, was halt die Vermutung aufbringt das die Pixel an sich nicht refresht werden dürften, sondern weiter bestehen müssten um das Video korrekt anzeigen zu können.
    Ich glaube nämlich das das FOBJ nur einige Frames an bestimmten Positionen ändert und nur über das vorherige Bild zeichnet, denn das Anfangsbild was FFmpeg mit dem Video macht und auch jeder Frame der eine komplett neue Szene zeigt dessen Farben sich komplett voneinander unterscheiden sind perfekt. Erst danach wird das mit schwarzen Pixeln übertönt, weil FFmpeg ja jeden Frame refreshen tut.

    Das heißt im Endeffekt A) ich müsste es bei FFmpeg anbringen das die das Fixen, wovon ich aber nie ausgehen werden kann oder B) einen eigenen Dekoder zusammenbauen der dies macht.

    Da ich die SAN zwars auslesen kann und Dumpen kann, versetzt mich leider noch nicht in die Lage es dekodieren zu können.

    Und genau da bräuchte ich Hilfe bei. Ich möchte im Endeffekt ein Tool haben (was eventuell auch noch erweitert werden kann) das Speziell für Smush Videos vorgesehen ist.
    Total Genial wäre wenn jemand ein AVISynth Tool dafür schreiben könnte. Das wäre denk ich auch viel Nützlicher.

    Und Anfangen wollte ich mit Star Wars - Shadow of the Empire

    Hier auch mal eine Testdatei, damit ihr das selbst ausprobieren könnt:
    http://www.mediafire.com/download/td5r9…ya/L01INTRO.SAN

    Und hier die Files die ich herausgerippt habe:
    http://www.mediafire.com/download/hpz29…_and_Palette.7z


    Spezifikation des Videos:

    Video:
    Smush Animated
    Auflösung: 640x332
    FPS: 15
    Farbraum: PAL8 (256 Farben) RGB?
    Frames: 1239

    Ton:
    iMUSE
    Audio Kanäle: 2
    Samplingrate: 22050 Hz


    Ich hoffe das sich jemand findet der mir bei dem Vorhaben helfen kann. Bzw. vllt auch eine andere Möglichkeit kennt.

    Einmal editiert, zuletzt von SagaraS (9. September 2016 um 15:02)

  • Ich kenne mich damit zwar nicht speziell aus, würde aber mal vermuten, dass es sich da um eine Art "Sprite-RLE-Codierung" handelt, d.h. es könnte einen reservierten Palettenindex geben, der keine Farbe repräsentiert, sondern Durchsichtigkeit (effizient programmiert, indem man so viele Pixel wie in der Lauflänge angegeben überspringen kann). Vielleicht wird das von ffmpeg nicht korrekt interpretiert.

    Bei der DOOM-Palette gab es so was ähnliches. Dieser Paletteneintrag wird zwar in der Vorschau oft hell-cyan dargestellt, weil das böse auffällig ist, aber dieser Paletteneintrag ist nicht "cyan", sondern "durchsichtig", immer bei der fest codierten Indexnummer.

    Nur 'ne Vermutung...

Jetzt mitmachen!

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