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

letzter Beitrag von Squidward am

Bad Reception TV (BR-TV)

    Moin!


    Ich möchte hier ein Programm vorstellen, an dem ich noch werkel & für das ich in den letzten Monaten mühsam ca. 4500 Frames konvertiert habe. Es ist ein Player für den C64, der Videos von einer 16mb REU abspielt. Anders als Nuvie aber nicht im Nufli-Bild-Format, sondern als Charset-Animation - dafür aber mit digitalisiertem Audio.


    Bild und Ton sind natürlich nicht die besten (hence the name). Andererseits konnte ich entsprechende Videos nicht bei Youtube hochladen, weil Audio und Video(!) als urheberrechtlich geschütztes Material erkannt wurde X/


    Der Player spielt verschiedene Formate/Variationen, die sich teilweise deutlich auf Clip-Laufzeit,FPS,Audio Qualität usw. auswirken. Ein paar Eckdaten:
    - bis zu 50 Bilder pro Sekunde / bei schlechter Audio-Qualität bzw. SID-Playback
    - Audio mit bis zu 44.1kHz** (oder gar höher) / bei schlechter Framerate und/oder Bildqualität
    - Audio ist entweder 4Bit ( "klassisch" ) oder 8Bit konvertiert nach Mahoney
    - SID Playback statt digit. Audio möglich
    - Charset-Animationen mit einem Zeichensatz für *alle* Frames / vierfarbig, mehr als 10.000 Frames möglich*
    - Charset-Animation mit einem Zeichensatz *pro* Frame / vierfarbig, mehr als 5.000 Frames möglich*
    - Charset-Animation mit Zeichensatz und Color-RAM / vielfarbig, mehr als 3.000 Frames möglich*
    - Charset-Animation mit allem dazwischen (variable Nutzung von Charsets, globaler Colorram, 2-Color-Hires, variable Colorsets per Frame...)
    *abhängig von Länge/kHz der Audio-Datei
    **darf man nicht auf die Goldwaage legen, da der Ton x-mal pro Sekunde vom Bildaufbau unterbrochen wird und somit nicht 44.1kHz Qualität erreichen kann


    Die Erstellung von Clips soll auch für andere möglich sein, ohne Programmierkenntnisse (Copy&Paste im Hexeditor vorausgesetzt), alle Einstellungen liest das Programm aus dem Header der REU-Datei. Allerdings sind aufgrund der Einschränkungen (nur 256 verschiedende Zeichen pro Bild, Farblimitationen, Bildaufbau "zerhakt" Audio je nach Framerate/Datenmenge) nicht alle Videos gleich gut zum Konvertieren geeignet. So wollte ich eigentlich dieses Nuvie umsetzen, welches aber zu viele Details pro Frame hatte und einen "zu empfindlichen" Sound :(


    Ein paar Beispielclips habe ich dennoch hochgeladen:


    Personal Jesus

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

    Charset-Animation, Zeichensatz pro Frame, 8.33fps, 44.1kHz Audio, Scene-abhängiges Farbschema, ca. 2000 Frames.


    Bad Apple

    [Externes Medium: https://www.youtube.com/watch?v=n8NQEd1azDs]

    Charset-Animation, 1 Zeichensatz für alle Frames, Unique Colorram, 10fps, 44.1 kHz Audio.


    I feel you

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

    Outdated! Charset-Animation, Zeichensatz pro Frame, 8.33fps, ca. 24kHz Audio, ca. 2500 Frames



    "Personal Jesus" repräsentiert quasi die goldene Mitte zwischen all den Settings/Qualitäten des Players. Etwas unter 4 Minuten, Audio is passable, Framerate auch, bestmögliches Bild (je nach Motiv), die Szenen cyceln durch eine Farb-Tabelle. "I feel you" dagegen beruht noch auf einer früheren Player-Version. Damals noch per selbst-inkrementierendem Zeropage-Player, der nicht mehr als 25kHz schaffte. Das Wechseln durch die Farb-Schemas geschah noch per Hand und zum Test einiger Farbkombinationen, daher teilweise Garbage auf dem Bild. Dazu noch Audio zu schnell und asynchron. Dass die beiden ersten Video-Konvertierungen von Depeche Mode stammen liegt auch daran, das sie dem Player mit der Optik sehr entgegen kommen (sw, grainy...). Last but not least: "Bad Apple" ist ein Beispiel für eine 1-Charset-Animation und daher beim Erstellen die weitaus einfachste. Ich habe keine halbe Stunde gebraucht. Kein Vergleich zu den ersten beiden Beispielen, für die ich (bummelige) Monate gebraucht habe, nur um die Frames zu erstellen!



    Zum Download gibt´s den Player leider noch nicht, und das hat drei Gründe (naja, hauptsächlich "Drittens"):


    Erstens ist er zur Zeit noch total überladen. Jede Format-Variante hat ihre eigene Playerroutine im Speicher. Teilweise unterscheiden sie sich aber nur minimal. Geplant ist eigentlich, dass das Programm später anhand des REU-Headers die Abspielroutine selber zusammensetzt. Aber das hat mir z.Z. noch ein viel zu großes Fehlerpotential, allein wegen der ganzen relativen Sprünge... Zudem sind noch die alten ZP-Player und deren Routinen drin, die ich inzwischen gar nicht mehr nutze (Ohh Gott, was hab ich da Zeit zum Optimieren investiert). Gleiches gilt für´s Menü, und damit kommen wir zu Zweitens.


    Zweitens soll der User am Ende auch noch etwas mit den Settings spielen können. Framerate ändern, nur die Audiodatei hören, nur das Video sehen, Farben (bzw. Hires) und Schemata ändern, Infos zum File lesen (Autor usw.). Teile des Menüs sind schon da, Routinen zur Eingabe aber nicht. Frißt z.Z. nur ungenutzt Speicher.


    Drittens habe ich keine Möglichkeit, den Player an realer Hardware zu testen. Ich besitze nämlich keine U1541II oder sonstige REU-Variante und plane auch nicht, mir entsprechendes zuzulegen. Ich nutze also ausschließlich WinVice und hoffe, dass es die REU (und den REU-Bug) entsprechend gut emuliert. Toi,toi,toi...



    Zur Zeit will ich noch ein Beispiel für eine Animation mit variablen Colorram & Zeichensatz erstellen, sowie eine Animation mit SID statt digit. Audio. Kann mich bloß nicht entscheiden, welches Video ich nehmen soll... :drunk:

    Zitat von Squidward

    Bad Apple

    [Externes Medium: https://www.youtube.com/watch?v=n8NQEd1azDs]

    Charset-Animation, 1 Zeichensatz für alle Frames, Unique Colorram, 10fps, 44.1 kHz Audio.

    Das sollte besser gehen, ein grosser Teil der Frames aus Bad Apple lässt sich mit weniger als 256 Zeichen darstellen und bei den wenigen wo es nicht passt (zB der Baum mit den vielen feinen Verästelungen) lässt sich das mit wenig Aufwand runterrechnen, ohne dass man den Unterschied (deutlich) wahrnimmt.


    Zitat

    "Personal Jesus" repräsentiert quasi die goldene Mitte zwischen all den Settings/Qualitäten des Players. Etwas unter 4 Minuten, Audio is passable

    Der Ton klingt so, als ob dein Player die Samples nicht exakt im richtigen Zeitraster ausgibt - bei Bad Apple klingt es zB ein wenig wie zusätzliches Vibrato oder so auf dem Ton. Wenn es nicht machbar ist, die Ausgaben der Playerroutine gleichmässiger zu gestalten, aber die exakten Ausgabezeitpunkte der Samplewerte vorherberechenbar sind, dann könnte man das wahrscheinlich mit einer Vorverarbeitung der Sampledaten reduzieren.

    Zitat von Unseen

    Das sollte besser gehen, ein grosser Teil der Frames aus Bad Apple lässt sich mit weniger als 256 Zeichen darstellen

    Klar, mit einem Zeichensatz je Frame ist wohl eine nahezu 1:1 Umsetzung möglich. Aber das hätte für mich einem Monat "Konvertieren" bedeutet. Da ich aber eh noch kein 1-Charset Beispiel hatte, habe ich mich eher dafür entschieden ;)



    Zitat von Unseen

    Der Ton klingt so, als ob dein Player die Samples nicht exakt im richtigen Zeitraster ausgibt - bei Bad Apple klingt es zB ein wenig wie zusätzliches Vibrato oder so auf dem Ton.

    Der Audio-Player an sich spielt schon exakt. Das Vibrato (oder auch schlimmer: Rauschen) stammt von den Unterbrechungen des Frame-Fetch. Für den habe ich 3 Möglichkeiten eingebaut: Brute Force (am Anfang des Frames alle Daten einlesen), Double Buffer (alle zwei Frames die doppelte Datenmenge einlesen) oder Distributed Fetch (Daten 2x pro Frame auf sechs Frames verteilt einlesen). Alles unterbricht aber den Sample-Player, und zwar je nach Format mit 256Bytes - 6kb Lücken. Je nach Source-Audio hört sich mal das eine oder andere besser an. Nie aber Distributed Fetch. Das hört sich immer schrecklich an, obwohl es auf dem Papier das sinnvollste wäre...

    Zitat von Squidward

    Klar, mit einem Zeichensatz je Frame ist wohl eine nahezu 1:1 Umsetzung möglich. Aber das hätte ich für einem Monat "Konvertieren" bedeutet.

    Ich habe das Gefühl, als ob dein Konverteralgorithmus noch etwas ungenutztes Optimierungspotential hat. =)


    Zitat

    Das Vibrato (oder auch schlimmer: Rauschen) stammt von den Unterbrechungen des Frame-Fetch.

    Oh, grössere Unterbrechungen sind natürlich unpraktisch. Wären es einfach nur schwankende Sample-Zeitpunkte, dann hätte ich es als Vorverarbeitungsschritt am PC mit einem Resampling auf ca. 985kHz (C64-Takt) versucht und aus der Datei per Script die Samples herausgezogen, an denen die Playerroutine tatsächlich ein Sample ausgibt. Das macht zwar die Frage nach der maximal darstellbaren Frequenz etwas kompliziert (erste Näherung: Samplerate = grösster Zeitabstand zweier Samples), sollte aber die Störungen reduzieren.

    Zitat von Unseen

    Ich habe das Gefühl, als ob dein Konverteralgorithmus noch etwas ungenutztes Optimierungspotential hat. =)

    Hehe, ich konvertiere per Hand mit SuperCSAM. Und das ist leider noch recht unpraktisch und unterstützt keine 1Frame1Charset-Methode. Auch würde es an einem Frame bis zum Ende aller Tage rechnen, weil es keine Abbruchbedingungen kennt (nicht mal,wenn es einen Error-Value von 0 erreicht!?!). Und Batch-Verarbeitung wäre ein Traum... :cry:




    Zitat von Unseen

    Oh, grössere Unterbrechungen sind natürlich unpraktisch.

    Das ist ja leider *das* große Problem beim Abspielen von Audio&Video. Multi-Tasking ist ja nicht auf´m C64, und für luxuriöse Pausen (zwecks Framefetch) zwischen den Sampledaten ist der Prozessor auch viel, viel zu langsam.

    Zitat von oobdoo

    Aber woher nimmst Du diese Daten für Dein "Bad Apple"??

    Die konvertiere ich vom Originalvideo mittels CSAM. Das Programm teilt einen Screen in 1000 Zeichen (8x8px ) ein und sucht dann einen Zeichensatz von nur noch 256 Zeichen zusammen, der den Screen/die Screens am besten repräsentiert. Doch statt einen Zeichensatz vom Bild zu erstellen gebe ich einen vor und zwinge das Programm damit quasi, das Bild mit meinem Zeichensatz darzustellen. Dieser besteht nur aus 16 Zeichen und eignet sich sehr gut, um Silhouetten stylisch darzustellen. Habe ich (neben dem Intro zu Mini Arcade:Climax) auch schon hier gemacht:


    "Resolution 80x50", unreleased One-File-Demo

    [Externes Medium: https://www.youtube.com/watch?v=FJOR-4Nwxv8]

    Zitat von Squidward

    Die konvertiere ich vom Originalvideo mittels CSAM.

    Danke für die Info. Gleich mal mit Lesezeichen versehen.


    Aber CSAM? Irgendwie finde ich dazu nur "Certified Software Asset Manager" auf Google. 8|

    Hab grad mit Schrecken festgestellt, dass SuperCSAM beim Erstellen in Farbe gar nicht den Colorram als File liefert, sondern nur einen Lookup-Table für´s jeweilige Zeichen. Das nützt mir leider gar nichts, weil es so viel zu lange dauern würde, das jeweilige Frame einzufärben. Jetzt muss ich hoffen, dass bald ne neue Version von CSAM erscheint, die den Colorram als 1000Byte (besser noch 1024Byte) File speichert... oder ich muss ein prg schreiben, das erst mühsam für jeden Screen anhand des Lookup-Tables den Colorram erstellt und dann abspeichert.
    :gahh:

    Hallo Squidward,


    wie in der Konversation gewünscht poste ich mein Testergebnis hier im Thread:


    1541ultimate (die erste, keine U2 oder U2+): Video wird abgespielt, aber ohne Ton, hab zwei unterschiedliche Firmware-Versionen getestet, bei beiden das gleiche


    Turbo Chameleon 64: kein wirkliches Bild (nur senkrechte Streifen), dafür aber Ton


    Ich bin die nächsten Tage erstmal weg, kann also erst später weitertesten (z.B. neuste Firmware auf das Turbo Chameleon 64 aufspielen).

    Danke für die Infos. Also mit der U1 scheint es dann zu funktionieren - laut REU-Header soll nämlich auch nur das Bild gespielt werden. Wenn du wieder Zeit hast kannst du den Header per Hexeditor umstellen.Der zweite Wert bestimmt die Art der Wiedergabe:
    00 = Video & Wave
    01 = Video ohne Ton (dieser Wert sollte dort auch z.Z. stehen)
    02 = Wave only
    03 = Video & SID-Tune


    Probier möglichst alle mal aus. Auch interessiert mich, ob es im Video machmal "kaputte" Bilder gibt. Das wäre dann nämlich der REU-Bug, den ich in Vice erfolgreich abgefragt habe...


    Danke schon mal :)


    PS: Beim TC64 scheint schon der Header nicht richtig eingelesen zu sein, und daher mißinterpretiert.

    Zitat von Squidward

    00 = Video & Wave
    01 = Video ohne Ton (dieser Wert sollte dort auch z.Z. stehen)
    02 = Wave only
    03 = Video & SID-Tune

    So habe es nun mal mit folgender Konfiguration ausprobiert: 1541U1, JiffyDos, C64R


    00 = geht nicht (schwarzer Bildschirm)
    01 = Video nur Schwarz / Weiß, unterer Bildschirm weiße Striche
    02 = 2 sec Ton in Endlosscheife
    03 = Perfekt - Video läuft ohne Störungen inkl. SID Tune und den Farben Rot und Blau. Anm.: Nachdem das Video länger in Endlosschleife gelaufen ist kam es zu Störungen (evt. REU Bug?)


    00:


    03:


    HoP

    Danke für´s Feedback!


    Also...


    Zitat von HouseOfPain

    00 = geht nicht (schwarzer Bildschirm)

    Das ist schon mal :buhu
    Hast du die Kombi auch mal mit Vice ausprobiert? Zumindest da sollte es schon laufen...


    Zitat von HouseOfPain

    01 = Video nur Schwarz / Weiß, unterer Bildschirm weiße Striche

    Die Striche sind z.Z. noch gewollt, sie zeigen die Art des Frame-Fetch an. Der vierte Wert im REU-File bestimmt die Art:
    00 - Brute Force: Vor jedem neuen Bild werden die Daten (3kb) "gefetcht", Szene-Farbe unterstüzt
    01 - Buffered: Vor jedem zweiten Bild werden die Daten für zwei Bilder (6kb) "gefetcht", Szene-Farbe noch nicht unterstüzt
    02 - Distributed: Die Bilddaten werden verteilt auf 6 Frames 2x pro Frame in 256Byte-Stücken "gefetcht", Szene-Farbe noch nicht unterstüzt


    Das bestimmt, wie lange und wie oft die Sample-Wiedergabe für Bilddaten unterbrochen wird. "Buffered" hört sich wohl am besten an, "Distributed" ist zwar am regelmäßigsten - hört sich aber furchtbar an. Beim Abspielen eines SIDs ist´s immer Brute Force, weil da ist´s egal.



    Zitat von HouseOfPain

    02 = 2 sec Ton in Endlosscheife

    Hört sich fast nach dem REU-Bug an. Scheint nicht zu "wrappen". Oder es liegt an den Command / Control-Registern der REU. Da musste ich auch unter Vice immer schonmal zwischen Autoload und No Autoload wechseln, ohne, dass ich einen Grund dafür gefunden hätte... :gruebel



    Zitat von HouseOfPain

    03 = Perfekt - Video läuft ohne Störungen inkl. SID Tune und den Farben Rot und Blau

    Gut, das zumindest das schon funktioniert :)


    Hattest du eigentlich bei einzelnen Frames Garbage auf dem Screen? Zum Beispiel recht früh am Anfang des Videos, wenn der anfahrende Wagen von der Seite zu sehen ist? Da schlägt nämlich der REU-Bug zu. Und ich weiß nicht, ob Vice den akurat widergibt und ich den auf realer Hardware korrekt abfange..?


    Danke schonmal für die Mühe :)






    Zitat von HouseOfPain

    Anm.: Nachdem das Video länger in Endlosschleife gelaufen ist kam es zu Störungen (evt. REU Bug?)

    Das liegt daran, dass ich noch nicht festgelegt habe, was am Ende den Clips (oder eigentlich eher der Wave-Datei) passieren soll. Vermutlich wird´s ein Rücksprung ins Menü am Ende vom Wave, bzw. am Ende vom Video (bei SID-Wiedergabe) geben. Zur Zeit resettet er nur den Clip oder springs ins ERROR, falls ich das überhaupt schon abgefragt habe...

    Ich habe nun nochmal getestet, Ergebnisse:


    1541u1:


    00 - Video spielt, aber leider kein Ton, nur gelegentliches Knacksen, am unteren Bildrand ein Störstreifen, ähnlich einem VHS-Player mit verstellter Spur
    01 - Video spielt ohne Ton (so wie es sein soll), am unteren Bildrand ein Störstreifen, ähnlich einem VHS-Player mit verstellter Spur
    02 - es werden die ersten 1-2 Sekunden Ton in Dauerschleife gespielt (sehr nervig nach kurzer Zeit)
    03 - Video spielt einwandfrei mit SID-Musik (so wie es sein soll, keine Störstreifen vorhanden)



    TC64 (mit neuster Firmware):



    00 - Ton (Wave) spielt, kein Bild, nur senkrechte Streifen, am unteren Bildrand ein Störstreifen, ähnlich einem VHS-Player mit verstellter Spur
    01 - wie 00
    02 - wie 00
    03 - wie 00


    Da das Ergebnis bei TC64 mit allen Einstellungen gleich ist, habe ich es nicht nur mit meinem Konfigurationstool (s.u.) probiert, sondern auch mit per Hexeditor gepatchten REU-Dateien (um auszuschließen, dass mein Tool nicht funktioniert, weil z.B. die REU read only ist).




    Um den Abspielmodus leichter umschalten zu können, habe ich ein kleines Tool geschrieben, dass auf dem C64 läuft. Damit kann man, nachdem man die REU-Datei geladen hat, den Abspielmodus ändern. Das Programm ändert das entsprechende Byte in der REU. Ist das REU-File bereits geladen, kann man mit dem Tool den Abspielmodus erneut ändern, ohne das REU-File nochmal laden zu müssen, einfach Konfig-Tool nochmal laden, Modus ändern und BR-TV erneut starten (spart einiges an Zeit gegenüber dem Laden von gepatchten REU-Files und man muss nicht 4 verschiedene REU-Files auf der SD-Karte vorhalten, was auf der SD-Karte 48 MB Speicherplatz spart).



    br-tv-v06-config.prg

    Danke für die Tests!


    Habe jetzt selber nochmal getestet, und zwar mit dem neusten NightlyBuild von Vice. Ergebnis: Dort geht es auch nicht. Unter Vice2.4SC geht es aber noch. Die REU Emulation scheint damit in den neusten Versionen genauer zu sein. Gut für mich, dann werde ich in den nächsten Tagen mal damit testen können. Scheint wohl etwas mit dem Timing der REU Command & Control Register zu tun zu haben.


    Zitat von daddlertl

    am unteren Bildrand ein Störstreifen, ähnlich einem VHS-Player mit verstellter Spur

    Zumindest das kann ich leicht klären: das ist ein INC $d020 DEC $D020 im IRQ, zwecks Erkennung :)



    Zitat von daddlertl

    Um den Abspielmodus leichter umschalten zu können, habe ich ein kleines Tool geschrieben, dass auf dem C64 läuft.

    Später soll man dies (und weitere Einstellungen) auch im Menü machen können. Ich selber ändere das zur Zeit noch ganz einfach im Quellcode, aber für Test-User ist das sicher bequemer, als am PC mit Hexeditor zu hantieren. Danke! :thumbup: Zu gegebener Zeit könntest du dein Tool auch noch um´s vierte Header-Byte erweitern (siehe Post #17) ;):weg:



    Zitat von daddlertl

    TC64 (mit neuster Firmware):

    Scheint den Header überhaupt nicht richtig einzulesen... :gruebel