L
Linards Ticmanis
Guest
Hallo allerseits,
ich hab mich ein bisschen in analoge Fernsehnormen eingelesen und die
Feinheitden der Bruch'schen Schöpfung, und 'nen YUV4MPEG nach PAL
Software Encoder geschrieben (bisher nur S/W aber Farbe kommt nach,
vielleicht wird der Code auch noch in mplayer integriert). Das Problem
ist, der PC ist zwar ohne weiteres schnell genug das Signal zu
produzieren (die innere Schleife bleibt dank Tabellen bei knapp 20
Assembler-Befehlen je Sample) währen gleichzeitig noch MPEG2 dekodiert
wird - nur: irgendwie muss es ja raus aus der Kiste in einen
Video-D/A-Wandler. Letzteres ist auch kein Thema, es gibt da offenbar
sowohl bezahl- als auch brauchbare 10-bit-Teile z.B. von Analog
Systems, die nur eine minimale Beschaltung brauchen.
Wie bekomme ich also nun die Daten aus dem PC? 10 bit je Sample bei 27
MHz sind immerhin 270 Mbit/s, und wenn ich, um Shiftregister u.ä. zu
sparen, die Werte als 16 Bit ausgeben will, kommen sogar 432 Mbit/s
zusammen. 8 Bit sind qualitätsmäßig doch eher am unteren Rand, das
wäre zwar einfacher aber wenn sich's machen lässt möchte ich doch
lieber 10 bit benutzen.
Bedingung ist außerdem, dass das ganze unter Linux (Kernel 2.6) laufen
soll.
Alle "klassischen" und leicht zu handhabenden Schnittstellen fallen
also somit leider flach, einschließlich Ethernet. Es bleiben: 1) USB
2.0 High Speed, 2) Firewire und 3) eine PCI-Prototypenkarte, leider
allesamt recht komplizierte Wesen.
3) scheint sich in Preisregionen zu bewegen, die eines Hobbyprojektes
nicht mehr würdig sind. Sehe ich das richtig? Alles jenseits 150 Euter
scheidet bei mir leider aus, da setzt der Geizreflex ein. Und alle
Lösungen, wo man erst mal nen teures Programmiergerät oder teure
Software kaufen muss (die dann außerdem nur auf Windows XP läuft),
entfallen somit leider auch.
Zu 2) habe ich kaum Infos gefunden. Falls jemand was weiß, wäre ich
für Infos dankbar.
Bleibt also 1). Da gibt es ja diese Cypress-Chips und z.B. die Boards
von www.braintechnology.de, nur: wieviel Durchsatz ist damit
tatsächlich möglich? Fehlerkorrektur ist bei dieser Datenrate weder
ohne weiteres machbar noch nötig, solange sich die Fehlerraten in
vernünftigen Grenzen halten -- der isochronous-Modus des USB-Bus
sollte wohl folglich zur Anwendung kommen. Die Daten bräuchten dann
nur noch im 27-MHz-Takt in den A/D-Wandler reingeclockt zu werden, der
eigentliche Schaltungsaufwand jenseits des USB-Kits sollte somit
minimal sein, falls sich der Chip entsprechend takten lässt. Nur ein
RAM müsste vermutlich noch dazwischen, damit kurze Lücken im
Datenstrom überbrückt werden können - oder ist der Datenstrom
gleichmäßig genug, um mittels des FIFOs in dem Cypress-Chip
kontinuierlichen Durchsatz zu ermöglichen? Sämtliche Signalpegel
sollen in Software auf der PC-Seite erzeugt werden, in dieser Hinsicht
ist also jenseits des USB-Busses keine Verarbeitung mehr nötig. Und
die Software darf dabei auch ruhig mit nice -n -19 auf einem ansonsten
nicht aktiven System laufen.
Die Gesamtlatenz ist übrigens nicht so entscheidend, solange die sich
unter 1 Frame, also unter ca. 40 ms bewegt ist davon eh so gut wie
nichts zu merken. Wesentlich höhere Werte wären nicht so toll, da dann
die Sound-Synchronisation leidet. Und einen Soundchip wollte ich
eigentlich nicht auch noch in die Schaltung basteln, da sollte es die
vorhandene Soundkarte tun.
A propos 27 MHz -- reichen eigentlich auch 13.5 MHz (ein Sampel je
DVD-Pixel) für ein vernünftiges PAL-Farbsignal oder wird da der Sinus
allzu sehr vermurkst? Die meisten kommerziellen DVD-Spieler scheinen
27 MHz (zwei Sampels je Pixel) zu benutzen, soweit überhaupt Angaben
dazu gemacht werden.
Natürlich könnte man auch eine Grafikkarte mit TV-Out nutzen, nur ist
bei denen die Bildqualität oft eher mäßig, die Timings sind kein
Norm-PAL, man muss sich mit Overscan rumärgern, dass teilweise nicht
komplett abschaltbar ist, das Refresh kommt irgendwann, nur nicht im
Takt mit der Bilderzeugung im PC, und unter Linux funktionieren sie
schon mal gar nicht richtig, jedenfalls nicht im 720x576-Modus.
Außerdem ist eine Eigenkonstruktion irgendwie cooler. ;-)
Bin für jeden Tipp zu diesen (noch etwas wirren) Gedanken dankbar,
--
Linards Ticmanis
ich hab mich ein bisschen in analoge Fernsehnormen eingelesen und die
Feinheitden der Bruch'schen Schöpfung, und 'nen YUV4MPEG nach PAL
Software Encoder geschrieben (bisher nur S/W aber Farbe kommt nach,
vielleicht wird der Code auch noch in mplayer integriert). Das Problem
ist, der PC ist zwar ohne weiteres schnell genug das Signal zu
produzieren (die innere Schleife bleibt dank Tabellen bei knapp 20
Assembler-Befehlen je Sample) währen gleichzeitig noch MPEG2 dekodiert
wird - nur: irgendwie muss es ja raus aus der Kiste in einen
Video-D/A-Wandler. Letzteres ist auch kein Thema, es gibt da offenbar
sowohl bezahl- als auch brauchbare 10-bit-Teile z.B. von Analog
Systems, die nur eine minimale Beschaltung brauchen.
Wie bekomme ich also nun die Daten aus dem PC? 10 bit je Sample bei 27
MHz sind immerhin 270 Mbit/s, und wenn ich, um Shiftregister u.ä. zu
sparen, die Werte als 16 Bit ausgeben will, kommen sogar 432 Mbit/s
zusammen. 8 Bit sind qualitätsmäßig doch eher am unteren Rand, das
wäre zwar einfacher aber wenn sich's machen lässt möchte ich doch
lieber 10 bit benutzen.
Bedingung ist außerdem, dass das ganze unter Linux (Kernel 2.6) laufen
soll.
Alle "klassischen" und leicht zu handhabenden Schnittstellen fallen
also somit leider flach, einschließlich Ethernet. Es bleiben: 1) USB
2.0 High Speed, 2) Firewire und 3) eine PCI-Prototypenkarte, leider
allesamt recht komplizierte Wesen.
3) scheint sich in Preisregionen zu bewegen, die eines Hobbyprojektes
nicht mehr würdig sind. Sehe ich das richtig? Alles jenseits 150 Euter
scheidet bei mir leider aus, da setzt der Geizreflex ein. Und alle
Lösungen, wo man erst mal nen teures Programmiergerät oder teure
Software kaufen muss (die dann außerdem nur auf Windows XP läuft),
entfallen somit leider auch.
Zu 2) habe ich kaum Infos gefunden. Falls jemand was weiß, wäre ich
für Infos dankbar.
Bleibt also 1). Da gibt es ja diese Cypress-Chips und z.B. die Boards
von www.braintechnology.de, nur: wieviel Durchsatz ist damit
tatsächlich möglich? Fehlerkorrektur ist bei dieser Datenrate weder
ohne weiteres machbar noch nötig, solange sich die Fehlerraten in
vernünftigen Grenzen halten -- der isochronous-Modus des USB-Bus
sollte wohl folglich zur Anwendung kommen. Die Daten bräuchten dann
nur noch im 27-MHz-Takt in den A/D-Wandler reingeclockt zu werden, der
eigentliche Schaltungsaufwand jenseits des USB-Kits sollte somit
minimal sein, falls sich der Chip entsprechend takten lässt. Nur ein
RAM müsste vermutlich noch dazwischen, damit kurze Lücken im
Datenstrom überbrückt werden können - oder ist der Datenstrom
gleichmäßig genug, um mittels des FIFOs in dem Cypress-Chip
kontinuierlichen Durchsatz zu ermöglichen? Sämtliche Signalpegel
sollen in Software auf der PC-Seite erzeugt werden, in dieser Hinsicht
ist also jenseits des USB-Busses keine Verarbeitung mehr nötig. Und
die Software darf dabei auch ruhig mit nice -n -19 auf einem ansonsten
nicht aktiven System laufen.
Die Gesamtlatenz ist übrigens nicht so entscheidend, solange die sich
unter 1 Frame, also unter ca. 40 ms bewegt ist davon eh so gut wie
nichts zu merken. Wesentlich höhere Werte wären nicht so toll, da dann
die Sound-Synchronisation leidet. Und einen Soundchip wollte ich
eigentlich nicht auch noch in die Schaltung basteln, da sollte es die
vorhandene Soundkarte tun.
A propos 27 MHz -- reichen eigentlich auch 13.5 MHz (ein Sampel je
DVD-Pixel) für ein vernünftiges PAL-Farbsignal oder wird da der Sinus
allzu sehr vermurkst? Die meisten kommerziellen DVD-Spieler scheinen
27 MHz (zwei Sampels je Pixel) zu benutzen, soweit überhaupt Angaben
dazu gemacht werden.
Natürlich könnte man auch eine Grafikkarte mit TV-Out nutzen, nur ist
bei denen die Bildqualität oft eher mäßig, die Timings sind kein
Norm-PAL, man muss sich mit Overscan rumärgern, dass teilweise nicht
komplett abschaltbar ist, das Refresh kommt irgendwann, nur nicht im
Takt mit der Bilderzeugung im PC, und unter Linux funktionieren sie
schon mal gar nicht richtig, jedenfalls nicht im 720x576-Modus.
Außerdem ist eine Eigenkonstruktion irgendwie cooler. ;-)
Bin für jeden Tipp zu diesen (noch etwas wirren) Gedanken dankbar,
--
Linards Ticmanis
