Hallo Besucher, der Thread wurde 33k mal aufgerufen und enthält 122 Antworten

letzter Beitrag von Squidward am

Bad Reception TV (BR-TV)

    Zitat von Polaris

    Gibt es eine chance Br-tv in InuYaksa's -Dragons Lair Laserdisc C64Port-Projekt integriert werden, um diese port könnte auch ton?

    Nein, ich fürchte nicht :(


    Die Videos dort sind Nuvies, zusammengesetzt aus einzelnen Nufli-Bildern. Die sind extrem groß und erfordern für die Darstellung sehr viel Rechenzeit. Beides verträgt sich leider nicht mit dem Sample-Playback, das ebenfalls viel CPU braucht & sich ungern unterbrechen läßt.


    BR-TV nutzt deshalb "nur" zeichensatzbasierte Frames, die je nach Darstellung 1 bis 4 kb groß sind. Die schönen Dragon Lair Videos würde aber via Zeichensatz stark leiden, in Details, Auflösung und Farben (color clash)...

    Es gibt offensichtlich noch eine andere, sehr beeindruckende Möglichkeit, Videos am C64 darzustellen:


    They're Taking The Hobbits To Isengard


    Ich habe das bestimmt schon einmal geschaut und nicht weiter beachtet, aber es ist tatsächlich echt! Unter dem Video befindet sich der Downloadlink mit dem Player, dem REU- File und einer Textdatei:


    "This is a version of the famous "They're Taking the Hobbits to Isengard" video
    for the C64 with 16MB REU.


    This version uses Mahoney-style 15.6kHz 8bit sample playback and 25fps (or so)
    video using standard C64 lores bitmap mode.


    Some technical details (for those who care):


    The source video had 3232 frames at 25fps. The resolution was 384x160 pixels.
    This was scaled and cropped to 320x200 pixels and then converted to standard
    C64 lores bitmap mode (Koala format).
    The audio was converted to 8bit mono at 15600Hz. This is then played one
    sample per rasterline using Pex "Mahoney" Tufvessons technique.
    After making room for the audio, there was only room for 1460 video frames,
    but luckily there are a lot of repeating sequences in the video. Using s simple
    brute force approach to compare images, the encoder selected a number of unique
    frames. After playing around with some thresholds, I ended up with 1456 frames.


    The player actually transfers and displays a new image each frame, thus playing
    at 50fps. A table decides which image to show (and which audio chunk of 312
    bytes to play) each frame. As a result, the video will show 25 unique images
    per second when needed, and a lot less when there's little/no action going on.


    Contact:


    Write to me at: maro [at] amidog [dot] se"


    Wurde das im Forum schon mal erwähnt, kennt das jemand?

    Zitat von Squidward

    Nein, ich fürchte nicht :(
    Die Videos dort sind Nuvies, zusammengesetzt aus einzelnen Nufli-Bildern. Die sind extrem groß und erfordern für die Darstellung sehr viel Rechenzeit. Beides verträgt sich leider nicht mit dem Sample-Playback, das ebenfalls viel CPU braucht & sich ungern unterbrechen läßt.


    BR-TV nutzt deshalb "nur" zeichensatzbasierte Frames, die je nach Darstellung 1 bis 4 kb groß sind. Die schönen Dragon Lair Videos würde aber via Zeichensatz stark leiden, in Details, Auflösung und Farben (color clash)...

    Es wäre schon interessant, wie die Details im BR- TV- Format leiden, immerhin schaut der Knatterton- Clip doch ganz ok aus. Die Filme gewinnen eben sehr durch den Originalton, das man das schwächere Bild akzeptieren kann.


    Sehr bemerkenswert finde ich, das die Reu- Files vom Programm selber geladen werden. Wenn das mal ein Player unterstützt, wären also auch längere Filme möglich?

    Zitat von tilobyte

    Es wäre schon interessant, wie die Details im BR- TV- Format leiden, immerhin schaut der Knatterton- Clip doch ganz ok aus. Die Filme gewinnen eben sehr durch den Originalton, das man das schwächere Bild akzeptieren kann.

    Hab mal geguckt: Der Originalton besteht meist nur aus kleinen Sample-Geräuschen, in geschickter SID-Musiker kriegt das wohl auch als SID hin. Und dann würde es ja auch mit den viel detailreicherem Nuvie (zumindest) laufen. Da "lohnt" eine echte Wav-Tonspur kaum...


    Hab mal ein paar Frames konvertiert. Bei Blautönen sieht es ganz schön aus, aber bei Rot kommt meist nur Brei raus (hab ich im Clip lieber weggelassen). Auch sehen Mauerwerk & Nahaufnahmen besser aus als z.B. der helle Held Dirk. Und die Tonqualität leidet auch unter "Farbe"... ;)


    [Externes Medium: https://vimeo.com/201147097]

    @Squidward Habe heute die neueste Version vom BR-TV (V0.7) ausprobiert.


    Der neue Player schaut großartig aus, gefällt mir sehr gut. Etwas gewöhnungsbedürftig war die Bedienung über die Funktionstasten. Für mich intuitiver wäre das Auswählen mit Cursor + Return. Aber das ist wohl eine Geschmackssache.


    Mein Setting:
    C64R, 1541U1


    BAD APPLE: Sound war nicht sehr gut
    DRAGONS LAIR: alle Versionen hatten bei mir kleine Bildfehler - beste Version war die 32kHz. 2kHz Version läuft zu schnell, bei der 4kHz Version war der Ton nicht sehr gut
    I FEEL YOU: Super, gegen Mitte/Ende ein paar Pixelfehler, nicht synchron
    NICK KNATTERTON: hört beim Gärtner auf und beginnt wieder von vorne. Weiß nicht ob das so gewollt ist – Ton und Bild TOP
    PERSONAL JESUS: Ein Klassiker;) - kleine Pixelfehler - gefühlt war die 32kHz Version etwas besser als die 44,1kHz.


    HoP

    Hehe, die F-Tasten-Steuerung nervt mich auch, sie war aber am leichtesten abzufragen ;)


    Zum Bad Apple Sound: Hast du zufällig zuvor noch ein Sid abgespielt? Dann hört es sich furchtbar an. Aber eigentlich sollte die Qualität nicht schlechter sein als die von DLair.


    Die untersten KHz Sample sind tatsächlich nicht zu empfehlen. Da wollte ich nur mal austesten, wie weit man "runter" gehen kann :)

    Zitat von Squidward

    Zum Bad Apple Sound: Hast du zufällig zuvor noch ein Sid abgespielt? Dann hört es sich furchtbar an. Aber eigentlich sollte die Qualität nicht schlechter sein als die von DLair.

    @Squidward Hab es heute noch einmal ausprobiert. Also im Gegensatz zu DLair oder DepecheMode hört sich, bei mir zumindest, Bad Apple ziemlich bescheiden an...


    HoP

    :/
    Hab länger nix mehr in der Richtung gemacht, brauche mal Abstand und wollte längst anderes weitermachen. Daher dachte ich eigentlich daran, erstmal eine Version "as is" zu veröffenlichen. Allerdings fällt da selbst die Readme-Datei unfangreicher aus, als ich dachte. An der schreibe ich noch nun ein wenig (auch, um später selber noch das Format & den Header zu verstehen). Sollte aber bald fertig sein...


    :saint:


    PS:Eine logische Verbesserung wollte ich eigentlich auch noch umsetzen (lasse es aber zunächst doch noch): Die fps werden noch immer vom Raster-IRQ gezählt (Überbleibsel aus der ersten "mal schauen ob´s überhaupt geht"-Phase) statt vom CIA-Timer. Letzteres würde nicht das Sample unterbrechen und auch *jeden* fps-Wert bis 50fps erlauben.

    Ich möchte hiermit nochmal nachfragen, ob es möglich wäre eine Anleitung zu schreiben, wie man so ein Video selbst erstellen kann (wie erstellt man die Frames, wo werden sie in der REU abgelegt, wie bringt man den Sound ins Video usw.), selbst wenn es kein fertiges Tool gibt, wäre eine Anleitung wie man so ein Video "händisch" erstellen kann toll, denn deine Demovideos kommen immer gut an, wenn ich sie auf Retrotreffen vorführe, da glauben viele nicht, dass sowas auf einem C64 möglich ist. Richtig cool wäre es natürlich, wenn man z.B. ein Video selbst produzieren könnte, wo z.B. ein Rundgang auf einem Retrotreffen gezeigt wird.

    Mir ist vor zwei/drei Wochen der PC gestorben. Dies ist bereits der zweite in etwas über einem Jahr :(
    Damit sind wieder einmal alle meine Retro-Projekte z.Z. nicht erreichbar, vorhandene Backups sind leider auch nicht sehr aktuell. Für BR-TV war ich gerade am Schreiben einer Anleitung inklusive Memory Map und Header-Erläuterung.
    Der wiederholte Rechner-Ärger ist für mich ein Zeichen: Deshalb werde ich BR-TV samt Anleitung nun möglichst schnell "as is" online stellen. Allerdings wollte ich zuvor noch sämtliche halbfertigen Test-Videos auch für den 6581 konvertieren (bisher immer 8580 konvertiert). Und natürlich erstmal wieder an die Daten rankommen...



    Generell nutze ich für die Videos SuperCSAM: Bei Personal Jesus z.B. war es glaube ich ein Ausgangsvideo (320x200) mit 8.3333 fps. Dieses habe ich Frame für Frame konvertiert. Und zwar jedes Frame einzelnd, da jedes Frame auch einen eigenen Zeichensatz hat. Ich habe also jedes Einzelbild erstellt und Screen (1kb) und Charset (2kb) abgespeichert. In dieser Reihenfolge gehören sie auch in die Reu, also Screen,Charset,nächster Screen,Charset usw. Jeder Screen hatte noch Metadaten (in den überschüssigen letzten 24 Bytes), darunter die Spritepointer (letzten 8 Bytes). In der Reu liegen die Screen/Charsets dann ab Ende Header. Das müßte bei $000064 (?) in der Reu sein, im Hexeditor die Zeile nach dem Autor-Namen.


    Du könntest ja testweise mal ein paar Frames erstellen (und dann am besten erstmal zu einem Block "mergen", das erspart ein 1000faches Copy&Paste im Hexeditor) und in der PJ-Reu ablegen (alte Frames überschreiben!). Die sollten dann korrekt angezeigt werden...


    Puuh, alles per Tablet geschrieben... :puhh:

    Ich habe mal einen schnellen Test gemacht und ein einzelnes mit CSAM Super konvertiertes Bild 6 mal hintereinander in die REU ab $A00000 (Framestartadresse laut Mediainfo bei PJ) unter Auslassung der Metadatenbytes kopiert, es hat auf Anhieb funktioniert, das Bild ist etwas mehr als eine halbe Sekunde zu sehen, bevor das reguläre Video weitergeht :)


    Das ist schonmal ein guter Start, jetzt heißt es herauszufinden, ob man die Konvertierung irgendwie automatisieren kann, denn ca. 2000 Frames die in dieses Videoformat passen dürften von Hand zu konvertieren ist nicht wirklich spaßig und würde ewig dauern.


    Das massenhafte Einfügen in die REU kann man leicht automatisieren. Dafür würde ich mir einfach einen Injector bauen, der die Frames an der richtigen Stelle in der REU platziert (so wie ich es auch schon für Nuvies mit dem Nuvie-Bildwechsler gemacht habe).


    Was auch noch fehlt ist der Soundkonverter, den hattest du mal per PN verschickt, leider wurden bei mir sämtliche PNs gelöscht, sodass ich den Konverter vermutlich nicht mehr habe, zumindest nicht auf dem Rechner an dem ich gerade bin. Könntest du den hier mal anhängen, damit er "nichtflüchtig" online ist ?


    Mir ist aufgefallen, dass bei PJ gelegentlich die Farben wechseln, ich vermute mal, dass die Farben auch in den Metadaten der Frames hinterlegt sind.


    Wenn ich mal Zeit habe, werde ich auf jeden Fall mit diesem Videoformat ein bisschen experimentieren.

    Ich habe buchstäblich tausende Frames "per Hand" konvertiert!!! :cry:;)


    Zwei wichtige Dinge fehlen CSAM leider:
    1. Die Option "1 Charset per Frame". Das Programm ist halt ausschließlich für den kleinen C64 Speicher ausgelegt
    2. CSAM hat auch keine Stop-Funktion, um beim Erreichen einer einstellbaren Bildqualität (Errorvalue) zum nächsten Frame zu springen. Es wird sogar noch bis in die Unendlichkeit weitergerechnet, wenn Errorlevel 0 erreicht ist ;)


    War gestern etwas spät: Die Frames liegen natürlich am Ende, nach der Wave Datei; wie es in der Info steht. Die Wavedatei liegt direkt hinter dem ReuHeader. Statt Wave geht auch ein Sid, muss ab $001000 in der Reu liegen, Frames dann ab $100000 glaub ich... Im ReuHeader muss dann aber irgendwo auf Video+Sid Format gewechselt werden (nimm einfach den Header von der SidBeispiel Reu)


    Die allererste Reihe (16 Werte) im Header sind Farben für das schnelle Füllen. Erst in der zweiten Reihe beginnen die relevanten Daten.


    Die Metadaten im Screen sind immer die "letzte Reihe" im Hexeditor. Die ersten 8 Bytes sind Flags (0 oder 1) für Dinge wie: neuer Zeichensatz? neuer Colorram? neue Farbe? welche Farbe? Irgendwie so ;) Die letzten acht Bytes sind die Spritepointer und immer gleich, zeigen auf Logo und Rahmen, falls aktiv.



    Wavekonverter such ich mal raus...

    Hab den Wavekonverter doch noch gefunden, brauchst also nicht danach suchen (kann ihn auch gern mal als Dateianhang anhängen falls gewünscht).


    Automatisierung klappt nun auch (mittels AutoIt-Script, das quasi das Programm CSAM-Super bedient, als würde man manuell Frame für Frame konvertieren).


    Hast du Erfahrungswerte wie lange man pro Frame konvertieren lassen sollte (je länger, desto genauer wird es ja, aber man will ja nicht ewig warten) ? Gibt es empfehlungen bezüglich Einstellungen ? (ich habe für meinen ersten Test erstmal alles auf den Standardeinstellungen gelassen)


    Wenn ich mehr Zeit habe (im Moment eher weniger), werde ich weiter herumexperimentieren und ein Frameinjectortool schreiben, um die ganzen konvertierten Bilder in die REU zu schaufeln.

    Mmhh, hab jetzt länger nix konvertiert und das Tool nicht vor Augen. Hab jedenfalls den Wert 20.000 bei Iterations per Update auf 4-5000 runter und meist maximal 50.000 Iterations durchlaufen lassen. Bei einem Pixelerror unter (ich glaube) 1.8 war ich immer zufrieden.


    Wirklich schade ist, dass Csam all seine Berechnungen vom Originalbild macht (bzws. den daraus erstellten 256 8*8 Blöcken), und eben nicht vom restriktionsfreien Optimal-C64-Beispielbild. Dadurch findet & verbraucht Csam viel mehr unterschiedliche Blöcke als auf dem C64 Bild je wären. Darunter leidet die Bildqualität stark und es finden sich eben doch viele doppelte Zeichen im Charset :( Das ist ein massiver Fehler im Ansatz!
    Für ein optimales Ergebnis müßte man also erstmal das Originalvideo auf die C64 Farbpalette oder vier Grautöne runterkonvertieren.


    Vom Wavekonverter muss ich irgendwo ein erweitertes Update haben, das schneller ist und auch gleich die Spritepointer in alle Screens schreibt. Liegt nur leider auf dem kaputten Rechner... :(