Osd2tcp

Aus open7x0.org

Datei: /usr/bin/osd2tcp

Das eigens von Andreas.Koch für die M740AV entwickelte Kommando osd2tcp ermöglicht es, Änderungen am OSD zu verfolgen und das OSD über eine Netzwerk-Verbindung (TCP) zu übertragen.

Inhaltsverzeichnis

1 Aufruf
2 Funktionsweise
3 TCP-Protokoll
- 3.1 Kommandos
4 Benötigte CPU-Zeit
5 Programmquelle
6 Benötigte Firmware
7 Kommandos in »Lemmis Firmware«
8 Verwendete Ports

Aufruf

Bei Aufruf ohne Angabe von Parametern erfolgt die 'usage'-Ausgabe:

osd2tcp V 0.0.4 - Andreas Koch - 2005-08-10
usage: osd2tcp [-v] [-x|--block_width n] [-y|--block_height n] [-p|--check_block_part n]                    
               [-b|--bits_per_pixel n] [-c|--compression_level n] [-w|--wait_frame n] port
   -v :
       verbose
   -x | --block_width n :
       Breite eines Blocks des OSDs. n muss ein Teiler von 720 sein.
       Bereich: 10..720
       Standardwert: 60
   -y | --block_height n :
       Hoehe eines Blocks des OSDs. n muss ein Teiler von 576 sein.
       Bereich: 12..576
       Standardwert: 32
   -c | --compression_level n :
       Kompression des uebertragenen Bilds
       Werte: 0 (keine Kompression), 1 (RLE)
       Standardwert: 1
   -p | --check_block_part n :
       n/1000 eines Blocks bei der Aenderungserkennung verwenden.
       Bereich: 1..500
       Standardwert: 15
   -b | --bits_per_pixel n :
       Bits pro Pixel die uebertragen werden
       Moegliche Werte: 1 := 32 Bits/Pixel, 2 := 16 Bits/Pixel, 3:= 8 Bits/Pixel
       Standardwert: 3
   -w | --wait_frames n :
       n Frames (1/25 Sekunde) zwischen Aenderungspruefungen warten
       Bereich: 1..50
       Standardwert: 13
   port : 1..65535

Funktionsweise

Wenn ein Client am Tool angemeldet ist, überprüft das Tool das OSD laufend auf Änderungen. Es wird dazu eine Prüfsumme (ADLER32) jedes OSD-Blocks berechnet. Es werden dazu jedoch nicht alle Pixel eines Blocks benutzt, sondern wie als Parameter ("-p" bzw. "--check_block_part") übergeben ein Anteil von Pixel eines Blocks. Die Abstände in denen diese Überprüfung stattfindet können über den Parameter "-w" bzw. "--wait_frames" eingestellt werden. Auch die Blockgröße kann über die Parameter "-x" bzw. "--block_width" und "-y" bzw. "--block_height", die die Breite und Höhe eines Blocks angeben, eingestellt werden. Zu beachten ist dabei, dass die Breite eines Blocks ein ganzzahliger Teiler der gesamt Breite des OSDs (720 Pixel) und die Höhe eines Blocks ein ganzzahliger Teiler der gesamt Höhe des OSDs (576 Pixel) sein muß. Das OSD wird dann in Blöcke der angegebenen Größe unterteilt. Dabei wird mit dem Block 0 in der oberen linken Ecke des OSDs begonnen. Die Blöcke werden von links nach rechts durchnummeriert. Ist der rechte Rand des OSDs erreicht, wird die Nummerierung mit dem Block am linken Rand der nächsten Zeile fortgesetzt.

Beispiel zur Block-Nummerierung für 6 Blöcke (Breite 240, Höhe 288):

0--------240-------480------720
|         |         |         |
|    0    |    1    |    2    |
|         |         |         |
288-------+---------+---------+
|         |         |         |
|    3    |    4    |    5    |
|         |         |         |
576-------+---------+---------+

Erkennt das Tool Änderungen am OSD, wird an jeden angemeldet Client die Anzahl der zuletzt geänderten Blöcke und die Anzahl der Blöcke, die nach Änderung (noch) nicht an den Client übertragen wurden, übermittelt. Ein Client kann die Übertragung eines Blocks über seine Blocknummer oder alle Blöcke die Änderungen für ihn Änderungen enthalten anfordern. Die Blöcke werden Zeilenweise im RAW-Format oder im lauflängenkomprimierten RAW-Format (RLE) übertragen.Die Pixel einer Zeile eines Block werden von links nach rechts hintereinanderweg übertragen und nach dem Ende einer Zeile wird die Übertragung mit der darunter liegenden Zeile des Blocks fortgesetzt.

Beispiel für ein Block der Größe 10x12 Pixel im Block:

0,0	1,0	2,0	...	10,0
0,1	1,1	2,1	...	10,1
0,2	1,2	2,2	...	10,2
. . .
0,12	1,12	2,12	...	10,12

Übertragungsreihenfolge der Pixel:

0,0

1,0

2,0

...

10,0

0,1

1,1

2,1

...

10,12

Ein Pixel besteht dabei aus 1,2 oder 4 Bytes (konfigurationsabhängig Parameter -b bzw --bits_per_pixel). Ein Pixel setzt sich aus den vier Farbkanälen Transparenz, Rot, Grün und Blau zusammen, die immer in dieser Reihenfolge übertragen werden. Werden 4 Bytes pro Pixel übertragen, wird je ein Byte pro Kanal verwendet; werden 2 Bytes übertragen, wird für die Tranzparenz nur 1 Bit und für die restlichen drei Kanäle je 5 Bits verwendet; wird 1 Byte übertragen, werden je 2 Bits pro Kanal verwendet.

Übertragung der Farbkanäle pro Pixel bei 32 Bit (in Übertragungsreihenfolge):

Byte	0								1								2								3
Bit	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
	Transparenz								Rot								Grün								Blau

Übertragung der Farbkanäle pro Pixel bei 16 Bit (in Übertragungsreihenfolge):

Byte	0								1
Bit	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
	Transparenz	Rot					Grün					Blau

Übertragung der Farbkanäle pro Pixel bei 8 Bit (in Übertragungsreihenfolge):

Byte	0
Bit	7	6	5	4	3	2	1	0
	Transparenz		Rot		Grün		Blau

Wird ein Block im RLE-Format (einstellbar über den Parameter -c bzw --compression_level ) übertragen, gibt das jeweils erste Byte an ob nun Farbwerte folgen und wie viele Pixel in Übertragungsreihenfolge die selben Eigenschaften haben. Das oberste Bit des Bytes ist 0, wenn eine Anzahl transparenter Pixel dargestellt werde müssen, in diesem Fall werden keine Farbwerte übertragen und es folgt das nächste Zähler-Byte; ist es 1 sind die Pixel nicht transparent und es müssen die nachfolgenden Farbwerte, dargestellt werden. Bei 32 Bits/Pixel werden jedoch nur noch die untersten 3 Bytes übertragen, da die Transparenz der Pixel ja schon bekannt ist. Die restlichen 7 Bit des Zähler-Bytes geben an, wie oft das Pixel in Übertragungsreihenfolge dargestellt werden muß; auf diesen Wert ist 1 zu addieren, da eine Anzahl von 0 Wiederholungen keinen Sinn ergeben würde (es müßte gar nicht übertragen werden).

Zähler Byte im RLE-Übertragungsformat:

Bit	7	6	5	4	3	2	1	0
	Transparenz 0 := Pixel sind transparent (keine Übertragung von Farbwerten) 1 := Pixel sind sichtbar (Übertragung von Farbwerten, bei 32-Bit entfällt das 1. Byte)	Anzahl der Pixel + 1

Es kann auch vorkommen, dass ein Block vollständig transparent ist, dies erkennt das Tool, und übermittelt es dem Client in diesem Fall. Damit sich ein Client auf die Konfiguration des Tools einstellen kann, kann diese über ein Kommando von ihm aus angefordert werden. Der Client kann durch ein Kommando auch eine Änderungsprüfung erzwingen

TCP-Protokoll

Die Übertragung der Daten erfolgt über TCP, der Port ist über den Parameter -p bzw. --port konfigurierbar. Das Protokol ist wesentlichen ASCII-Zeilen basiert.

Bei Änderungen von Blöcken sendet das Tool die Zeile an alle Clients:

OSD_BLOCKS_MODIFIED <Anzahl zuletzt geänderter Blöcke> <Anzahl Blöcke, die nach Änderungen nicht an den Client übertragen wurden>

Kommandos

Kommando Zeile	Kommando Beschreibung	Antwort Zeile(n) des Tool	Antwort Beschreibung
`GET_CONFIG`	Konfiguration anfordern.	`OSD_BLOCK_CONFIG <Breite eines Block> <Höhe eines Blocks> <Bits pro Pixel>`	Die aktuelle Konfiguration des Tool
`GET_VERSION`	Version anfordern.	`OSD2TCP_VERSION <Major-Version> <Minor-Version> <Revision>`	Die aktuelle Konfiguration des Tool
`GET_OSD_BLOCK <Block Nummer>` `GET_OSD_BLOCK MODIFIED`	Im ersten Fall die Übertragung des Blocks mit der entsprechenden Nummern initiieren. Im zweiten Fall die Übertragung aller Blöcke, die Änderungen enthalten, die (noch) nicht an den Client übertragen wurden, initiieren.	`OSD_BLOCK_CLEAR <Block Nummer>` `OSD_BLOCK_RAW <Block Nummer> <Länge der RAW-Daten>` `OSD_BLOCK_RLE <Block Nummer> <Länge der lauflängencodierten RAW-Daten>`	Für jeden Block antwortet das Tool mit einer der drei Zeilen. In den letzten beiden Fällen gefolgt von der angegeben Anzahl an Bytes der entsprechenden Daten - RAW oder RLE kodiert. Im ersten Fall ist der Block vollständig transparent und braucht nicht übertragen werden.
`GET_WHICH_OSD_BLOCKS_MODIFIED`	Block Nummern der Blöcke die Änderungen enthalten, die (noch) nicht an den Client übertragen wurden, anfordern.	`BLOCK_MODIFIED <Block Nummer>`	Für jeden geänderten Block wird die Zeile mit der jeweiligen Block Nummer gesendet.
`WAKEUP`	Es wird eine Änderungsprüfung durchgeführt.	keine

Benötigte CPU-Zeit

Die Überprüfung der Änderungen am OSD kostet (je nach Einstellungen) so gut wie keine CPU-Zeit, bei der Komprimierung und/oder Übertragung des OSD-Bild kann die verwendet CPU-Zeit jedoch kurze Zeit auf über 90% ansteigen. Außerdem ist die Last der CPU abhängig vom Inhalt des OSDs

Programmquelle

Das Programm ist in C geschrieben. Die Quellen des Programmes sind im SVN abgelegt:

osd2tcp

Das Programm wurde mit der alten toolchain übersetzt.

Benötigte Firmware

Das Programm ist in Lemmis Firmware ab Oktober 2005 enthalten. Aktiviert wird es durch die »osd2tcp«-Einstellungen in der Datei /var/etc/lemmi-settings.txt. Die Kommunikation findet dann über Port 10101 statt.

Ansonsten kann es auf allen Firmware-Versionen mit telnet-Zugang verwendet werden.