www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Video DEcoder mit AVR


Autor: Michael Juen (jmibk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe soeben ein LED Array gebastelt, welches Werte aus dem RAM im 
Nultiplexverfahren an das Array ausgibt. Momentan funktioniert das ganze 
über DMX und ist daher auf 512 Pixel beschränkt (bei Farbe um das 3fache 
weniger).

Jetzt kommt mir die Idee, ein Videosignal (BAS, FBAS oder auch DVI oder 
VGA, Super Video??) auszuwerten (welches ist mir eigentlich egal, 
hauptsache es geht) und im RAM des uCs zu speichern.
Es gibt wenige Themen hier, die um das ganze handeln, jedoch alles 
kompliziert.

Ich bräuchte eigentlich nur 50x100 oder MAXIMAL!!! 200x300 Pixel, zum 
Anfang mal Schwarz/Weiß (also wahrscheinlich mit BAS anfangn) mit einer 
Widerholrate von zwischen 10 und den 25 Frames/Sekunde.

Wenn das ganze im RAM gespeichert wird (Ram Adresse 0x0070 = Pixel links 
oben, RAM Adresse 0xXXXX = Pixel rechts unten) wäre ich absolut 
zufrieden.

Es gibt AVR uCs, die 2k und 4kByte RAM haben. Somit wird man erst mal 
mit dem auskommen müssen und die Pixelanzahl an das anpassen.

Hat wer einen Vorschlag oder auch nützliche IC's/Schaltungen, wie man 
ein normales Video in den Atmel bekommt?

Autor: Tom M. (tomm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein erster Gedanke ist, ffmpeg dazu zu verwenden, um Videodaten in ein 
"gäbiges" Format zu konvertieren. Habe ein ähnliches Bastelprojekt (LED 
Matrix, einfarbig, 4 Helligkeitsstufen), für das ich's auch gerne mal 
ausprobieren möchte. Also offline Videodaten aufbereiten, auf 
Speicherkarte schreiben und diese dann aufm AVR auslesen und ausgeben.

Hab mir aber noch nicht durch das ffmpeg Manual und die Myriaden Codecs 
und Konfigurationsoptionen gekämpft. Wenn du damit etwas weiter kommst, 
lass uns teilhaben. :)

Schönen Sonntag!

Autor: melt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansatz wäre auch das Video mit mplayer in einzeldateien zu exportieren 
und dann mit ImageMagick die restlichen Bearbeitungsschritte auszuführen 
und die Rohdaten zu exportieren.

Autor: Michael Juen (jmibk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht ob es überlesen wurde oder einfach von mir unklar 
formuliert wurde: Es geht darum, da dran einen DVD Player oder sowas 
anzuschließen und diese Daten dann an das LED Array auszugeben.

Daher kein ffmpeg und dergleichen vorhanden.

Autor: plödi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit den CPUs aus der ST20-Serie z.B. STM5516 kein Problem.
MPG-Stream dekodieren und in den Arraypuffer blitten.
Ein STM5516 hat dem AVR aber auch einen MPG-HW-Dekoder
und einige MIPS voraus.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, die Idee ist es auch nicht, einen MPEG STream zu dekodieren, 
sondern einen 'LED-Bildschirm' zu bauen, dem man ein BAS oder PAL Signal 
anbietet und das Gerät analysiert dann das Signal.

Also
Schwarzschulter rausholen, Zeilen zählen, Austastlücke auswerten u dgl.

Da aber noch nicht einmal Grossmeister ELM-CHAN da was fertiges hat, 
denke ich, wird ein AVR du nur schwer mitkommen. Lass mich aber auch 
bekehren. Beim ELM-CHAN findet sich ein Gerät, welches aus einem 
Videosignal eine bestimmte Zeile ausfiltert und ein Triggersignal für 
diese Zeile für einen Oskar generiert.

Hauptproblem wird wohl sein, das Farbsignal auszufiltern und nur das 
Schwarz/Weiß Signal übrig zu lassen. Da man vom Videosignal sowieso das 
meiste wegwirft, müsste man allerdings ausprobieren, ob man da mit dem 
Timing mitkommt.

Autor: Michael Juen (jmibk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Also
> Schwarzschulter rausholen, Zeilen zählen, Austastlücke auswerten u dgl.

Das heißt man muss sich hier etwas in die thematik Videosignal einlesen 
(eh klar). Vorerst gehts nur um SW und da nicht die ganze PAL Auflösung 
sondern weit kleiner.

Autor: hdd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für S/W wäre S-Video ganz gut, da hast du ja direkt das BAS-Signal für 
die reinen Helligkeitswerte.
Reicht es dir, wenn du z.B. jede m-te Zeile mit jedem n-ten Bildpunkt 
ausgeben kannst oder willst du die Werte über ein m*n-Rechteck gerundet 
haben? Ersteres wäre deutlich einfacher.

Autor: Michael Juen (jmibk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So einfach wie möglich, also das erste. Die meisten DVD Player haben 
einen SVideo Anschluss. Sonnst kann man das - soweit ich gehört hab - 
mit Filtern trennen.

Aber nehmen wir den einfachsten Fall an, dass man einfach jeden nten 
Bildpunkt in jeder nTen Zeile hernimmt und das ganze von einem SVideo 
aus - den Rest kann man ja dann immernoch erweitern.

Lernen tut man aber dennoch aus einfachen Dingen am besten.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Juen schrieb:

> Lernen tut man aber dennoch aus einfachen Dingen am besten.


In diesem Forum lernt man allerdings sehr schnell, dass Variationen des 
Satzes "Ich lerne am besten aus Beispielen" ein Pseudonym sind für 'Kann 
mir das mal wer machen' sind.

Also: Was hast du denn bisher über dein Signal in Erfahrung gebracht, 
welchen Verlauf hat es, welche Information steckt in welchem 
Signalverlauf?

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit einem (8-Bit-)AVR eine Auflösung 200x300-Bildpunkte zu erreichen ist 
illosorisch!
Man kann vielleicht Standbilder ausgeben, aber kein Video "aufnehmen", 
um es anzuzeigen.

Autor: netb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde eher sagen, dass der Bau einer ordentlichen 200x300 LED-Matrix 
das größere Problem ist. Wenn er beispielsweise nur 1 Bit pro Bildpunkt 
mit Hilfe eines Komparators aufnimmt, dann sind das gerade mal 1,5MBit 
pro Sekunde für den AVR, das sollte man noch hin bekommen, je nachdem 
wie die Matrix organisiert und angesteuert wird.

Also er sollte sich erst einmal Gedanken über die Matrix machen, wie die 
realisiert wird, wie man ihr schnell die nötigen Daten ohne großen 
Aufwand übermitteln kann und die Sache mit dem BAS Signal kann dann 
beliebig vereinfacht werden, so dass ein AVR das auch schafft.

Autor: Michael Juen (jmibk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit der Matrix funktioniert bereits. Dabei macht ein Atmega8515 
genau 8x8 RGB Pixel. Reiht man mehrere dieser Arrays aneinander bekommt 
man dann die dementsprechende Auflösung.

Das funktioniert bereits per DMX bestens und gibt auch seine "Videos" 
aus, jedoch per DMX Software.

Ich hätte dann vor über ein eigenes Protokoll die Daten von diesem 
Bilddekoder an dieses einzelnen Arrays zu senden (so wie es eigentlich 
DMX ja auch schon macht).

Autor: netb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast also 900 Teilarrays mit je 8x8 Pixeln und je einem AVR? Das ist 
sportlich!

Am besten benutze zur Kommunikation zwischen den AVRs einen Einweg-Bus 
der per Hardware auf dem Haupt-AVR zur Verfügung steht. Beispielsweise 
indem du alle Matrix AVRs parallel an eine RS232-Leitung hängst und dann 
in deinem Haupt-AVR einfach nur die Bytes in das RS232-Senderegister 
schreibst. Wenn du das versuchst über ein Software-Protokoll zu lösen, 
dann verbraucht das zu viel Zeit.

Bei 200x300x1Bit und 25 Bildern / Sekunde muss dein Haupt-AVR 1,5 MBit 
pro Sekunde einlesen, in 8er Gruppen sammeln und dann z.B. in das 
RS232-Senderegister schieben. Du hast also so ca. 10 Assembler-Befehle 
pro Bit bei 16 MHz zur Verfügung. Das sollte genügen.

Du musst dir dann nur noch Gedanken machen, wie du dein Haupt-AVR auf 
das BAS-Signal synchronisierst (Zeilen- und Bildsynchroninformationen 
aus dem Signal zurückgewinnen) und wie du deinen Matrix-AVRs mitteilst, 
welcher Matrix-AVR das gerade gesendete Byte entgegen nimmt. Das könnte 
man eventuell so machen, dass diese intern mitzählen wie viele Bytes 
gesendet wurden und dann eben nur das verarbeiten, was für sie relevant 
ist. Das ganze kann dann auch regelmäßig über einen Impuls 
synchronisiert werden.

Autor: Michael Juen (jmibk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die schon vorhandenen Module haben 6x24 LED Kanäle, die per 64 Step PWM 
einzeln Dimmbar sind. Momentan halt auf DMX Basis, bei der die DMX 
Hardware schon am UART des ICs hängt - somit wäre das mit einem 
Firmwareupdate alleine umgestellt. DMX ist zwar nicht Bidirektional, 
aber man kann ja auf der Platine vor dem DMX Treiber schon auf RS232 
abweichen, da sehe ich wenig Problem.

Mit "Eigenem Protokoll" meine ich in der Art von DMX die Pakete 
mitzählen, die per UART reinkommen und jeder Chip nimmt sich dann seine 
raus oder so in der Art.

Es geht mir hier wirklich nur um das, dass der Videocontrollerchip das 
Video in seinen Ram mit vorerst 1000 oder 1500 Pixeln/Bild einliest. Das 
ist dann vorerst eine Auflösung von rund 40x50 Pixeln (nichteinmal das).

Ich hab nur absolute Probleme diese Analogtechnik zu verstehen und 
erhoffe mir (wie die Vorredner eh schon vermutet haben) ein wenig Hilfe 
ausm Forum (es gibt sicher schon Leute, die sich mit sowas gespielt 
haben und so schon Erfahrung gesammelt haben).

Autor: Brumbaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AVR dürfte überfordert sein.

Die Zeilenfrequenz beträgt beim BAS Signal 15,625kHz, was erst mal kein 
Problem darstellt.

Davon sind 52µs Bildinfo - bei 50 Pixel pro Zeile ist das 1µs pro Pixel.

In den horizontalen Austastlücke hast du 12µs und in der vertikalen 
sogar 1,6ms für alles Mögliche. Und natürlich noch die 64µs all jener 
Zeilen aus denen du keine Pixel liest. Also reichlich Zeit.

Die Frage ist es ob du in 1 µs dein Pixel in einen Digitalwert gewandelt 
und ggf in den AVR bekommst.

Bei einem einzelnen Bit kein Problem.

Bei externer Wandlung und einem hohen Takt kannst du bestimmt auch Bytes 
über ein Port einlesen und für die Weiterleitung vorbereiten.

Willst du die 50 eingelesenen Bytes innerhalb einer Zeile wieder 
loswerden brauchst du bei einem UART mindestens 7,845 Megabaud.
Bei 1 Bit (7 Byte) immer noch  1,1 MBaud.

Verteilst du die Datenübertragung auf das gesamte Bild genügen 1 bzw. 
0,125 MBaud.

Eigentlich brauchst du etwas mehr, weil in irgendeiner Form noch 
zumindest ein Bildstart Signal eingebunden werden muss (selbst wenn es 
als Signallücke geschieht, kostet es Zeit). Wenn das ganze noch in ein 
Protokoll verpackt werden muss, steigt das Datenvolumen noch weiter an.

Falls du Schwierigkeiten mit der Einlesegeschwindigkeit bekommst könnte 
man die Pixel versetzt einlesen.
Da du nur etwa jede 8 Zeile einliest, wäre es möglich z.B. die geraden 
und ungeraden Pixel aus aufeinanderfolgenden Zeilen zu lesen. Das würde 
bedeuten, du hast 2µs zum "Einlesen" eines Pixels statt nur einer. Ob 
der "Versatz" bei einem 50 x 40 Bild auffällt  muss man sehen.

Also es sollte mit dem AVR machbar sein, wenn man die Datenübertragung 
auf das gesamte Bild verteilt,  oder eine Zeile liest und ihre Daten 
dann in den nächsten 7 ignorierten Zeilen überträgt.

Mit einem hohen Takt, kann man bei versetzten Pixeln sogar den internen 
AD Wandler verwenden.

Bei höheren Auflösungen wird es allerdings ganz schnell eng.

Bei einem F-Bas Signal geht es nur schlecht ohne externer 
"Farbumwandlung".

Ein RGB Signal und seine Derivate sind angenehmer zu verarbeiten als 
F-BAS (ohne Zusatzhardware), aber man braucht halt drei Wandler (was bei 
einem Bit pro Farbe natürlich kein Problem darstellt) und die Datenmenge 
verdreifacht sich im Vergleich zum BAS Signal bei gleicher Auflösung und 
Bittiefe pro Komponente.


MfG
SH

Autor: Tim O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin..

Warum hat eigentlich die Datensicherung vom Amiga 500 über den Parallel-
port auf einen Videorecorder und zurück funktioniert?

Weil man kein Echtzeitvideo darstellen wollte.. einfach nur Bitmuster,
wenn man das Video auf nem Fernseher betrachtet hat, war es nicht viel
mehr.

Videotext ist doch auch sowohl erzeugbar als auch dekodierbar, mit nem
Z80 !!

Also, nicht übertreiben, sondern auf das Problem eingehen:

Die Matrix hat nen RAM, und die vorhandene Schaltung liest aus dem RAM
und schickt an die LEDs.

Soweit so gut..

Nun wollen wir also nur von der Datenquelle DMX512 weg, zu einer 
anderen.

Also nehmen wir uns nen schnellen AVR, nen LM1881, und erwarten dann
halt die Pixel für die LEDs an der Stelle, wo unser AVR mit rechnen und
übertragen fertig ist.

Wie erzeugt man dann das FBAS-Signal mit den Pixeln ? Na im Endeffekt
schnappt man sich irgendein Gerät, das nen FBAS-Signal erzeugt, so ne
dumme kleine CCD-Kamera oder irgendwas.. es geht ja nur um die schwer
selbst zu erzeugenden Dinge am FBAS.. Mit nem weiteren LM1881 holt man
sich die Impulse, und schaltet dann anstelle des FBAS-Erzeugers eine
definierte Spannung auf die Ausgabeleitung. Ist dann mangels Phase halt
nicht wirklich Farbfähig, aber wir übertragen ja nur Bitwerte.. 1 oder
0 .. und aus diesem Bitstream liest ja der andere AVR seine Daten fürs
LED-PWM ..

Gruss,
Tim

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Videotext ist doch auch sowohl erzeugbar als auch dekodierbar, mit nem
>Z80 !!

Videotext ist ja auch Pippifax gegenüber dem Videosignal:
Da werden nur die Informationen digital in der Austastlücke übertragen. 
Die Anzeige hat ein anderer Chip dann übernommen (STV53... oder so).

>Warum hat eigentlich die Datensicherung vom Amiga 500 über den Parallel-
>port auf einen Videorecorder und zurück funktioniert?

Weil die Daten nicht gerade in Hochgeschwindigkeit (2GiB bei 
240er-VHS-Cassette) gespeichert wurden.
Pendant wäre da wohl die Datasette (auch Commodore).

Mit einem AVR wirst du keine 8Bit Helligkeitauslösung hinbekommen.
4 Bit mit externem Flash-Wandler vielleicht.

Autor: Tim O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin..


Also, nochma das, was der TE wünscht:

> Jetzt kommt mir die Idee, ein Videosignal (BAS, FBAS oder auch DVI oder
> VGA, Super Video??) auszuwerten (welches ist mir eigentlich egal,
> hauptsache es geht) und im RAM des uCs zu speichern.
> Es gibt wenige Themen hier, die um das ganze handeln, jedoch alles
> kompliziert.

> Ich bräuchte eigentlich nur 50x100 oder MAXIMAL!!! 200x300 Pixel, zum
> Anfang mal Schwarz/Weiß (also wahrscheinlich mit BAS anfangn) mit einer
> Widerholrate von zwischen 10 und den 25 Frames/Sekunde.

> Wenn das ganze im RAM gespeichert wird (Ram Adresse 0x0070 = Pixel links
> oben, RAM Adresse 0xXXXX = Pixel rechts unten) wäre ich absolut
> zufrieden.

Also doch.. LM1881 - warten auf Sync-Impuls, Verarbeitung starten ->
Über Komparator schauen, wie "hell" der Pixel ist. Schwarz/weiss halt.
1 oder 0. Wert im Bitpuffer sichern. Jetzt ist Zeit vergangen, und der
nächste Pixel kann gelesen werden.

Nun ist es doch für die Auswertung egal, ob das der erste sichtbare 
Pixel
ist, den man auf einem normalen TV sehen würde. Und ob der nächste Pixel
dann der rechts daneben ist. Selbst die Zeilen sind egal. Die 50x100 
wird
man in der PAL-Auflösung also auf jeden Fall unterbringen können.

Um natürlich nun ein dazu passendes Signal zu erzeugen, --- moment, das
hab ich ja schon beschrieben.

Gruss,
Tim

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte auch einen Teil der Intelligenz und vor allen Dingen den 
Bildspeicher in die Anzeigemodule verfrachten. Dazu ein paar Gedanken:

1. der zentrale Controller tastet das Signal ab und schickt es, in Bytes 
verpackt über seine serielle Schnittstelle. Die Geschwindigkeit dieser 
ist so hoch zu wählen, daß das vorhergehende Byte sicher raus ist bevor 
das nächste zu senden ist.

2. die seriellen Ports der Anzeige-Controller sind wie in einer Kette 
hintereinander gehängt, der Ausgang des letzten Anzeigemoduls ist offen.

3. Die Anzeige-Controller haben einen Ringpuffer, der so groß ist wie 
die gesamte Zeilenbreite mal die Zeilenanzahl des Moduls. In einer 
Mainloop wird auf das nächste Byte gewartet, in den Ringpuffer gelesen 
und ein um die Anzahl der Bytes pro Modulzeile verzögertes Byte auf den 
UART gegeben.

4. Nach dem Ende der letzten Darstellungszeile wird für eine Zeile die 
Ausgabe gestoppt und ein SYNC-Signal an alle Controller gesendet. Jetzt 
übernimmt jeder Controller die für ihn relevanten Daten aus dem 
Ringpuffer und speichert sie in seinem Anzeigespeicher.

5. Der Eingang eines Bytes wird zusätzlich (mit entsprechendem 
Vorteiler) zum Multiplexen der Anzeige benutzt. Aus diesem Grund werden 
in der vertikalen Austastlücke Dummy-Bytes gesendet.

So könnte ich mir das zumindest vorstellen.

Jörg

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht gibt dir Peggy Inspirationen:

HW:LED-Matrix --- HW:Peggy ---TWI--- HW:Arduino ---USB--- HW:PC
Aufbereitung des Videosignals auf dem PC mit Processing.

http://www.evilmadscientist.com/article.php/peggy2twi

Autor: Michael Juen (jmibk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Ideeninput. Da die LED Arrays ja eigentlich jedes seinen 
RAM hat, der für sich selbst auch mehr als ausreichend ist kann man 
wirklich einen Seriellen Bus bauen und der Videoumwandel AVR macht aus 
dem Video einfach einen Seriellen Echtzeitstream mit den einzelnen 
Pixeln. Die Arrays holen sich dann ihre Bytes da raus und die Sache 
läuft.

Werd mir dann in der nächsten Zeit das mit dem AVR Video mal anschauen 
und ausprobieren, wenns Fragen gibt bin ich ohnehin wieder hier ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.