OSD Speicher

servus Oga

ich vermute mal, dass es mit hardware-seitigem aufrüsten nicht getan ist.
vermutlich muss dann auch der DVB-treiber angepasst werden...

gruessle

Hi Zusammen,

eine Frage in dieser Richtung wollte ich auch schon immer mal stellen. Aber ich würde sogar noch nen Schritt weiter gehen:

Basierend darauf, daß viele Sachen aufgrund des begrenzten OSD-Speichers UND des relativ schwachen ARMs nicht realisierbar (z.B. mehr als 5 Bilder beim PIP-Plugin) sind, ist eine reine Erweiterung des OSD-Speichers doch nur Schmuck am Nachthemd (aber zugegeben schöner Schmuck). Ich bin zwar kein Hardware-Spezi, aber ich denke es müssten doch mittlerweile viel Leistungsfähigere ARM-Modelle auf dem Markt sein, oder? Nein, ich glaube jetzt nicht, daß man einfach mal den ARM gegen ein anderes Modell austauschen kann, Firmware und Treiber müssten dahingehend sicherlich angepasst werden (korrigiert mich wenn ich mich irre). Aber wie wäre es, wenn wir alle Zusammen TechnoTrend bitten würden, mal einen neue Kartengeneration zu entwickeln? Wenn man dabei dann wieder auf einen ARM setzt (dann natürlich nen schnelleren), müssten die Treiber und Firmware-Anpassungen sich doch eigentlich in Grenzen halten...

Wenn TT dabei dann auch noch einen Blick auf die hier vorgestellten Erweiterungsplatinen hinsichtlich Schutz der Ausgänge usw. wirft, könnten sie (natürlich nur mit Einverständnis der Entwickler wie STB usw) gleich auch noch ein paar andere Features einbauen, die sie wiederum von ihren Billig-Wettbewerbern aus Fernost abheben würde.

Ich habe kein Gefühl dafür wieviele der verkauften Karten unter Windows eingesetzt werden, und wieviele unter Linux. Aber wenn alleine die hier in diesem Board Anwesenden je eine dieser neuen Karten als primäres Device kaufen würden, käme doch schon eine nette Stückzahl zusammen. Für TT langfristig sicher lohnend... Und wir hätten ne Karte, die bzgl. OSD gegen MediaCenter und Co. anstinken kann.

Andere spinnen am Abend, ich am Morgen... aber ist das wirklch alles gesponnen?

Gruß

Jiupp

Zitat

Original von Jupp Schlonz
Hi Zusammen,

Basierend darauf, daß viele Sachen aufgrund des begrenzten OSD-Speichers UND des relativ schwachen ARMs nicht realisierbar (z.B. mehr als 5 Bilder beim PIP-Plugin) sind,

Das mit den 5 Bildern hab ich auch mal geglaubt... Das Ding kann mehr.
Mit meiner momentanen Konfiguration habe ich ein flüssiges Farbbild... das PIP Bild ist manchmal sogar einen Bruchteil schneller als das echte Fernsehbild.

Das nur mal so nebenbei:)

Cat

Zitat

Original von Jupp Schlonz
...Aber wie wäre es, wenn wir alle Zusammen TechnoTrend bitten würden, mal einen neue Kartengeneration zu entwickeln?...

Sorry, aber da bin ich etwas desillusioniert! Wann hat die Industrie mal was entwickelt, das der Konsument wollt? Ok, ist nen bisschen überspitzt, aber die Ideen, die wir haben, sollte ein Entwickler längst haben, es tut sich trotzdem nichts! Warum? Weil "wir" zu wenig sind! Der Großteil der Konsumenten kauft Lemming-gleich das, was ihm angeboten wird, da werden wir paar "Freaks" nichts dran drehen!

Den einzigen Weg aus der Miesere, den ich sehe ist dieser:
Output über VGA oder DVI. Da ist natürlich doof, dass der Prozessor den MPG2-Kram erledigen muß, aber machbar ists!

Fazit
=> Wir bräuchten Output-Plugins, die im Prinzip das bereitstellen, was momentan vom Treiber bereitgestellt wird. Und das natürlich auch in entsprechender Erweiterung (Mehr Farben, mehr Auflösung, mehr mehr...!) Wenn allerdings eine solche Schnittstelle entwickelt wird, sollte man gleich die Anforderungen und nicht die Limitationen des DVB-Treibers im Kopf haben!

Greets!

also, das thema wurde schon oefters auf der ml durchgekaut.
aktuell ist auch ufo drannen. das problem ist nicht der arm, oder das 2. ram.
das problem ist der fehlende SC2 (sram chip select 2). der arm kann 32mb
osd ram locker ansprechen, das wuerde also fuern vollfarb bild als osd tun.
leider hat tt scheinbar kosten sparen wollen und den 2. chip ned mitdesigned.
man kann nun einen baugleichen (z.b. alte vga graka) 1:1 auf den vorhandenen
huckepack draufloeten, muesste nur sc2 "extra" verdrahten. leider weis keiner
aktuell, wie man da ran kommt. btw hat kls selber auch grosses verlangen

evtl koemma drauf hoffen, das es entweder von tt nen neues design mit
j2, vid out schutz und 32mb osd ram gibt, oder die software loesungen
"stable" werden. die meisten laufen zwar schon supergut, aber an ne ff
karte kommts halt einfach noch ned ran...

ps: also ich kann mit elchi4d und iosd super leben das ist beiweitem schon
mehr, als tt jemals getraeumt hat. ich dnek mal die sind auch voll
neidisch, was lord und so alles aus der (langsamen) hardware rausholen.

-- randy

Zitat

Original von BigDiSt
=> Wir bräuchten Output-Plugins, die im Prinzip das bereitstellen, was momentan vom Treiber bereitgestellt wird.

softmpeg, xine, softdevice. was willst du denn noch mehr?

-- randy

Zitat

Original von randy
softmpeg, xine, softdevice. was willst du denn noch mehr?

Ne offene Pluginarchitektur (Input, Output, ...) a la Winamp

Greets!

Zitat

evtl koemma drauf hoffen, das es entweder von tt nen neues design mit j2, vid out schutz und 32mb osd ram gibt

wissen die jungs von tt das denn?
ich mein wenn die gar nicht wissen es leute gibt die damit so hervorragend arbeiten, und dran entwickeln, warum sollten dann was an ihrem disign aendern?

__
andreas

Zitat

Original von BigDiSt
Ne offene Pluginarchitektur (Input, Output, ...) a la Winamp

da ist kls fleissig drannen, das das noch offener wird. aber ich glaub
du hast noch nie den source geguggt? oder meinst, das die o.g. plugins
erstmal vdr patchen um solche sachen machen zu koennen? vdr ist
schon so "offen", das es ihm egal ist woher und wohin das mpeg laeuft.
und wohin das osd soll etc..

-- randy

Zitat

Original von BooStar
wissen die jungs von tt das denn?
ich mein wenn die gar nicht wissen es leute gibt die damit so hervorragend arbeiten, und dran entwickeln, warum sollten dann was an ihrem disign

die haben doch kontakt mit convergence wegen der firmware von den ff
karten... also ich nehm schon an, das tt das weis - zumindest nen paar entwickler.
aber auf der anderen seite wirds halt die leute mitm taschenrecher geben,
die dann halt letzendlich druebert entscheiden was sache ist...

als beispiel sei die low profile dvb-s genannt, die zwar auf der webseite
von TT abgebildet ist, aber im handeln noch nie erhaeltich war... dabei gibts
echt tausende lowprofile gehauese fuer epia boards z.b....

-- randy

Hi,

zumal ja auch offensichtlich was bei convergence im Busch ist. Ich zitiere mal aus der Mailingliste:

Zitat

Klaus Schmidinger
Does this mean convergence(?) will be producing a DVB-S/C/T PCI card that
- can deliver the full TS
- can do (PES-) MPEG decoding in hardware (the format VDR currently uses)
- supports CAMs through the LL interface
- has a fullscreen OSD with at least 256 colors
- has a builtin AC3 output port - has A/V and RGB output (others?)
- does not require any firmware (or at least no "closed source FW")
- is _really_stable_ - did I forget anything?

Alles anzeigen

Anwort von Holger Waechtler von convergence (05.03.04):

Zitat

we are right now in the process of founding a design house indepependent of convergence but will definitely cooperate whenever it makes sense. Prototypes of a terrestrial and satellite receiver are built and in the verification stage. Right now it's too early for details (but you know our claim - it's going to be the best and cheapest piece of hardware you can get for money now and tomorrow, trust us and be a little patient for a few more days - ;).

gruesse
michael

Hallo

Na mein Epia hat auch mpg on board

MFG

Zitat

Original von randy
da ist kls fleissig drannen, das das noch offener wird.

Soweit hab ich's auch mitbekommen

Zitat

Original von randy
aber ich glaub du hast noch nie den source geguggt? oder meinst, das die o.g. plugins erstmal vdr patchen um solche sachen machen zu koennen?

Asche auf mein Haupt, nein: Ich sah nie die heiligen Sourcen! Allerdings: glaub ich auch nicht, dass das irgendetwas ändert, da ich vor knapp 7 Jahren das letzte mal mit c/c++ zu tun hatte.

Und nochmal nein: ich glaube nicht das Plugins patchen! Dafür reicht meine Vorstellungskraft einfach nicht aus. Ich kenne die Plugin-Schnittstelle nicht, aber es scheint aj dann so zu sein, dass ein Plugin "alles" machen könnte (vom input über Verarbeitung bis zum Output). Wie auch immer, lass uns die Geschichte hier jetzt nicht vertiefen! Ich fänd die Geschichte mit der Unterscheidung zwischen Input-Plugins und Output-Plugins halt ganz nett, weils auch neue Möglichkeiten der Oberflächen Gestaltung liefern würde (Liste der "Quellen" bspw.)

Greets!

Zitat

Original von BigDiSt
Ich fänd die Geschichte mit der Unterscheidung zwischen Input-Plugins und Output-Plugins halt ganz nett, weils auch neue Möglichkeiten der Oberflächen Gestaltung liefern würde (Liste der "Quellen" bspw.)

haja, das gibts doch halt schon in form der input und outputdevices:

// --- cDigiboxDevice --------------------------------------------------------


class cDigiboxDevice : public cDevice {
private:
  int source;
  int digiboxChannelNumber;
  int fd_dvr;
  cTSBuffer *tsBuffer;
  int fd_lirc;
  void LircSend(const char *s);
  void LircSend(int n);
protected:
  virtual bool SetPid(cPidHandle *Handle, int Type, bool On);
  virtual bool OpenDvr(void);
  virtual void CloseDvr(void);
  virtual bool GetTSPacket(uchar *&Data);
public:
  cDigiboxDevice(void);
  virtual ~cDigiboxDevice();
  virtual bool ProvidesSource(int Source) const;
  virtual bool ProvidesTransponder(const cChannel *Channel) const;
  virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsSetChannel = NULL) con
  virtual bool SetChannelDevice(const cChannel *Channel, bool LiveView);
  };

(sky.c)

virtual bool ProvidesSource(int Source) const; <- ich geb dir was (input)
virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, <- ich biete dir channels an

etc..

nur koennen halt die plugins noch nicht alles, daher muss elchi patchen.

aber kls macht das schon ;))

-- randy

Zitat

Original von randy
nur koennen halt die plugins noch nicht alles, daher muss elchi patchen.

aber kls macht das schon ;))

*grr* werde nicht mehr ruhen und jede Zeile Code studieren! Ich finde schon was, wo Du nix gegen sagen kannst, Du!

Greets!

Zitat

Original von ogawoga
Wir sollten alle Weltverbesserer werden. Wenn nur nicht wie oben erwähnt die Leute mit den Taschenrechnern wären.

Und die s.g. "Content-Industrie" (wobei "content" ja auch sowas wie zufrieden bedeuten kann!)

Greets!

Zitat

Original von randy
aktuell ist auch ufo drannen. das problem ist nicht der arm, oder das 2. ram.
das problem ist der fehlende SC2 (sram chip select 2). der arm kann 32mb
osd ram locker ansprechen, das wuerde also fuern vollfarb bild als osd tun.
leider hat tt scheinbar kosten sparen wollen und den 2. chip ned mitdesigned.
man kann nun einen baugleichen (z.b. alte vga graka) 1:1 auf den vorhandenen
huckepack draufloeten, muesste nur sc2 "extra" verdrahten. leider weis keiner
aktuell, wie man da ran kommt. btw hat kls selber auch grosses verlangen

Alles anzeigen

Da mein Name nun schon gefallen ist, kann ich ja mal was zum momentanen Status sagen:

Habe mir einen Arm-Cross-Assembler aufgesetzt und ein kleines Testprogramm geschrieben, um auf den Speicherbereich, der durch SCS2 adressiert wird, zuzugreifen.

Dann habe ich angefangen, die Leiterbahnen auf der Oberseite des av7111 nach dem SCS2-Signal abzusuchen. Bisher erfolglos. Die anderen SDRAM-Signale (und sonst noch so einiges) habe ich mittlerweile lokalisiert. Nur - das brauchen wir ja nicht.

Das ganze ist leider sehr zeitaufwendig und knifflig. Schaut Euch mal den av7111 unter der Lupe an! Wenn also jemand die Lage des SCS2-Signals kennt, kann er mir gerne eine Message wie "Königin auf Y13" schicken.

Wieso die Pinbelegung nicht im Datenblatt steht, ist mir völlig unverständlich. Was soll den daran geheim sein?

Wie dem auch sei, bisher hat es mein Test-Arm ganz gut überstanden. Danke nochmal an Carsten Koch, der mir seine defekte Karte für diese Tests zur Verfügung gestellt hat.

CU
Oliver