neues tool im cvs (location: tuxbox/apps/misc/tools)

Beitrag von **stdin** » Donnerstag 9. März 2006, 19:54

hi,

ich hab heut mein programm dboxshot zum erstellen von screenshots unter der dbox (dreambox konnte ich nicht weiter prüfen) ins cvs hochgeladen.

das tool speichert im bmp-format ab.

ein screenshot ist innerhalb von 0.4 sekunden (so ein benchmarktest bei mir) erledigt.

die syntax zum programm lautet wie folgt:

Code: Alles auswählen

Usage: dboxshot [-d] [-h] [-c hex] [-t n] [-o filename]
  Options
  -d    Debugmodus enabled
  -h    print out this message
  -c    define backgroundcolor in RGB-hex (e.g. -c d0d0d0)
  -t    wait mSec. before Screenshot
  -o    define Outputfilename

viel spass mit meinem programm.

Beitrag von **petgun** » Donnerstag 9. März 2006, 20:37

..super! 0,4 sec fuer einen Screenshot im *.bmp Format vom OSD oder etwa vom TV-Bild? Letzteres waere ja ziemlich sensationell...wo speichert das Teil ab und wie gross ist so ein Screenshot?

--
22

Beitrag von **Tommy** » Donnerstag 9. März 2006, 21:19

-c define backgroundcolor in RGB-hex (e.g. -c d0d0d0)

sollte fast eindeutig sein

Beitrag von **stdin** » Donnerstag 9. März 2006, 22:18

die ausgabedatei wird ins aktuelle arbeitsverzeichnis geschrieben, bzw. je nach dem wo du die ausgabe abgespeichert haben möchtest (option: -o <pfad>).
es wird der inhalt des fb abgespeichert, also nicht das tv-bild.
um nicht gerade einen schwarzen hintergrund zu bekommen, hatte ich die option -c hinzugefügt.

edit: die filegröße ist 406,1 kb

Beitrag von **petgun** » Donnerstag 9. März 2006, 22:38

Tommy hat geschrieben:-c define backgroundcolor in RGB-hex (e.g. -c d0d0d0) sollte fast eindeutig sein

stimmt...dann weiss ich nicht was das soll...ca. 10* so grosses File in einem mehr/nur? unter Windows verbreiteten Format. Da ist mir *.png wesentlich sympatischer.

--
19

Beitrag von **stdin** » Freitag 10. März 2006, 07:54

@petgun: dann teste mal die geschwindigkeit

obwohl mir das bmp-format selber nicht so doll gefällt, aber der einfache aufbau des formates ermöglicht sehr schnelle screenshots.

Beitrag von **PT-1** » Freitag 10. März 2006, 10:14

Erst einmal Danke fuer deine Arbeit !!

Dann die erste Frage,

wenn man dieses BMP per Mounted Drive nutzen um per YWeb Live das Neutrino Interface darzustellen...? Waere ja kein Problem wenn das bild sich immer wieder selbst ueberschreibt....?

Beitrag von **petgun** » Freitag 10. März 2006, 10:31

PT-1 hat geschrieben:wenn man dieses BMP per Mounted Drive nutzen um per YWeb Live das Neutrino Interface darzustellen...? Waere ja kein Problem wenn das bild sich immer wieder selbst ueberschreibt....?

das file ist zu gross (hohe zusaetzliche Netzwerkbelastung), das Format koennte zB. nicht von VLC dargestellt werden (*.png wuerde funktionieren) aber der groesste Nachteil wird die dauernde hohe CPU-Belastung der DBox sein bei so einem kontinuierlichen Betrieb. Sowas wie ein VNC-Server auf der Dbox koenne vielleicht funktionieren fuer eine dauernde Uebertragung des OSD.

--
17

Beitrag von **chkbox** » Freitag 10. März 2006, 12:00

Jeder x-beliebige Browser kann das aber! (jedenfalls bei Standart BMP) Man könnte zB die Web-Fernbedienung damit sinnvoll erweitern, indem man einen <img> Tag mit in die Seite baut und bei jedem "Knopf-Drücken" das Bild neu erzeugt und geladen wird.

Beitrag von **petgun** » Freitag 10. März 2006, 12:07

...die schiere Groesse von *.bmp ist imo ein ko-Kriterium. Angeblich ist ja die schon vorhandene snapshot Funktion um Faktor 3 beschleunigt worden...vielleicht geht da noch mehr oder/und man ueberlegt sich einen sinnvolleren Algorithmus. Die 0,4 sec sind doch auch auf einer Dreambox gemessen, oder?

--
14

Beitrag von **stdin** » Freitag 10. März 2006, 12:29

chkbox hat geschrieben:Jeder x-beliebige Browser kann das aber! (jedenfalls bei Standart BMP) Man könnte zB die Web-Fernbedienung damit sinnvoll erweitern, indem man einen <img> Tag mit in die Seite baut und bei jedem "Knopf-Drücken" das Bild neu erzeugt und geladen wird.

ja da hast du recht, es geht.

ich konnte das selber schon testen, aber da entwickelt zur zeit noch jemand anderes dran. die verzögerung ist max. 1sekunde auf der dbox.

@petgun:

Die 0,4 sec sind doch auch auf einer Dreambox gemessen, oder?

auf der dbox2 (genau sagem mit 66mhz) getestet. im schnitt waren es sogar 0.3-0.4 sekunden.
und das mit dem ko-kriterium kannste getrost vergessen, k.o. ist das png-format, da jenes format einen lzw-algorytmus zur komprimierung verwendet. dieser dauert so lange!

Beitrag von **stdin** » Freitag 10. März 2006, 12:36

PT-1 hat geschrieben:Erst einmal Danke fuer deine Arbeit !!

Dann die erste Frage,

wenn man dieses BMP per Mounted Drive nutzen um per YWeb Live das Neutrino Interface darzustellen...? Waere ja kein Problem wenn das bild sich immer wieder selbst ueberschreibt....?

ich hatte ursprünglich das tool dafür geschrieben, damit es im zusammenhang mit dem yweb-interface läuft.
evtl. könnte ich einen anderen entwickler mal fragen ob er einen patch zur verfügung stellt.

Beitrag von **MTM** » Freitag 10. März 2006, 12:42

Hallo,
es gibt das .BMP-Format doch auch in einer Variante mit RLE-Komprimierung (Lauflängenkodierung) , laut Wikipedia ( http://de.wikipedia.org/wiki/Windows_bitmap ) ...
Könnte das vllt. etwas für die oben angesprochenen Probleme bringen? Die Komprimierung könnte recht gut sein und die Prozessorlast vllt. gering ( das ganze am besten natürlich als optionaler Parameter zu implementieren )

Nur ein Gedanke,
MTM.

Beitrag von **stdin** » Freitag 10. März 2006, 12:50

MTM hat geschrieben:Hallo,
es gibt das .BMP-Format doch auch in einer Variante mit RLE-Komprimierung (Lauflängenkodierung) , laut Wikipedia ( http://de.wikipedia.org/wiki/Windows_bitmap ) ...
Könnte das vllt. etwas für die oben angesprochenen Probleme bringen? Die Komprimierung könnte recht gut sein und die Prozessorlast vllt. gering ( das ganze am besten natürlich als optionaler Parameter zu implementieren )

Nur ein Gedanke,
MTM.

hmmm, die lauflängencodeierung schau ich mir mal an.
das würde schon ein wenig die übertragungsgeschwindigkeit reduzieren. ist aber nur sinnvoll wenn im gegensatz dazu (und das wird passieren) die erstellungszeit des bild nicht viel mehr zeit kostet.

Beitrag von **MTM** » Freitag 10. März 2006, 17:07

Hallo,
deshalb sollte es ja auch optional sein ...
Vllt. kannst du ja abschätzen wieviel langsamer es durch die Komprimierung wird, wenn du es dir etwas genauer anschaust ...

Wie auch immer, es war ja nur eine Idee, quasi ein Kompromiss zwischen dem komprimierenden aber saulangsamen "alten" fb-shot, und dem schnellen aber unkomprimierten dboxshot -> das Beste aus beiden Welten ...

MfG,
MTM.

Beitrag von **dcdead2** » Freitag 10. März 2006, 19:52

Naja, so viel Zeit sollte das auch nicht Kosten, schließlich heisst RLE nur, dass aufeinanderfolgende gleich bits zusammengefasst werden und einfach angegeben wird wie oft diese hintereinander vorkommen

Beitrag von **stdin** » Freitag 10. März 2006, 22:36

dcdead2 hat geschrieben:Naja, so viel Zeit sollte das auch nicht Kosten, schließlich heisst RLE nur, dass aufeinanderfolgende gleich bits zusammengefasst werden und einfach angegeben wird wie oft diese hintereinander vorkommen

wenn dann sind es bytes, da die pixeldaten ja auch in bytes vorliegen

d.h. ich muss wieder bytweise den datenteil durchsuchen, dann wirds langsam.

Beitrag von **yjogol** » Samstag 11. März 2006, 10:50

Hi,
also das sind schon sehr große Dateien.
0,4s ist aber ein interessanter Grund.

Zeilenkompression sollte bei den Neutrino-OSD viel bringen.
Aber bei der Geschwindigkeit, kann man yWeb schön erweitern.

Gruß
yjogol

Beitrag von **Barf** » Samstag 11. März 2006, 13:11

Ich habe ein Target flash-dboxshot in newmake eingefügt (make/misc_tools.mk).

Zum Thema clevere/dumme Bildformate: Ohne die Details zu kennen wurde ich "das Unix-Prinzip: Ein Program pro Aufgabe" bevorziehen. Umwandlung von dummen Bildformat zu kleven kann mit einem andere Programm bewerkstelligt werden.

Beitrag von **yjogol** » Samstag 11. März 2006, 15:39

Barf hat geschrieben:Ich habe ein Target flash-dboxshot in newmake eingefügt (make/misc_tools.mk).

Zum Thema clevere/dumme Bildformate: Ohne die Details zu kennen wurde ich "das Unix-Prinzip: Ein Program pro Aufgabe" bevorziehen. Umwandlung von dummen Bildformat zu kleven kann mit einem andere Programm bewerkstelligt werden.

Das sehe ich auch so. Das Tool ist scheinbar an vielen Stellen ein Überarbeitung von fbshot, sieht jetzt teils auch sauberer aus.
Dann wäre es auch besser, fbshot ein Flag für das Ausgabeformat zu verpassen, so wie ich den Kompressionsfaktor als Flag eingebaut habe.

! => Das Ganze "mergen".

Gruß
yjogol

Beitrag von **stdin** » Samstag 11. März 2006, 17:45

@yjogol: wie soll ich das denn aussehen?
willst du die funktionen zum erstellen der bmp-files nach fbshot portieren, od. wie soll ich das verstehen?

Beitrag von **yjogol** » Samstag 11. März 2006, 19:41

stdin hat geschrieben:@yjogol: wie soll ich das denn aussehen?
willst du die funktionen zum erstellen der bmp-files nach fbshot portieren, od. wie soll ich das verstehen?

Na das wollte ich offenlassen

Ich selbst will da nix, siehe das nicht als Kritik an dir.
Aber zwei Programme die im wesentlichen das gleiche machen ....
Gruß
yjogol

yjogol hat geschrieben:
stdin hat geschrieben: Aber zwei Programme die im wesentlichen das gleiche machen ....

... aber unterschiedlich gross sind

Beitrag von **MTM** » Donnerstag 14. Dezember 2006, 18:09

Hallo,
munderl hat am 5.12.06 eine Version von "dboxshot" mit besagter RLE-Komprimierung eingecheckt.
Es könnte jetzt also getestet werden...

(yjogol vielleicht?)

MfG,
MTM.