[ANNOUNCE] OSD picture in picture plugin 0.0.5 (osdpip-0.0.5)

clausmuus

Kannst du damit auch richtig was erkennen ?

So habs getestet, schätze so 2-3 fps auf 128 Farben, variable Palette.

Nicht schlecht !

Kann man bei einem Rechner über 2 GHz ein richtig flüssiges Bild erwarten ?

Da meines Wissens nach nur die I-Frames (vollständiges Bild) gegrabbed werden können und die alle 12 Frames im Transportstream auftauchen, dürfte es bei ca. 2 Frames pro Sekunde bleiben, unabhängig von der Rechnergeschwindigkeit

Günter

Zitat

Kann man bei einem Rechner über 2 GHz ein richtig flüssiges Bild erwarten ?

Na klar, habe hier einen 2,6er P4 da läuft das mit 25 fps ohne Probleme !!

LordJaxom:

Machst Du eingentlich noch eine neue Version Deines (genialen) Prugins, das die 4MB Karten ausnutzt. z.B. wegen der Kanalanzeige u.s.w.

Salaam

Nur mal um die Performance zu vergleichen:
Ich kann auf meinem 900Mhz Athlon zwei komplette PIPs ohne Framedrops darstellen. Also Livebild und 2 eingeblendete Videos (werden von Platte geladen) mit voller Farbtiefe und beliebiger Größe. Beim dritten PIP machts glaub ich die Platte nicht ganz mit, der Prozessor könnte es evtl. noch.
Der Spruch hilft hier natürlich niemanden weiter, zeigt aber, dass mit entsprechender Softwareoptimierung noch ganzschön was aus der Hardware rauszuholen ist. Das ganze läuft unter Win2k (!) nicht hauen

Gruß
Jarny

Meine Angabe bezog sich nicht auf eine Ausgabe über das OSD, sondern auf einen Framebuffer (Windows) und über den TV-Out meiner GF2Mx aufs Fernsehgerät (übrigens in einer Qualität die sich mit dem TV-Out der FF-DVB-s messen kann)
Wo liegt dann eigentlich der limitierende Faktor bei PIP? Das OSD scheint ja von der Bandbreite her 25 Bilder pro Sekunde hinzubekommen. Ich dachte immer das wäre der Flaschenhals im System. Da hier aber steht, dass man mit einem 2,6Ghz-Rechner die 25 Bilder hinbekommt habe ich eher auf einen Flaschenhals bei der Mpeg-Decodierung getippt.
Ich glaube auch, dass man von den OpenSource-Mpeg2-Decodern nicht die Performance von hochoptimierten kommerziellen Decodern unter Windows erwarten kann.

Gruß
Jarny

Zitat

aber nicht über das OSD der DVB-Karte, oder? Sicher sind problemlos 25 fps drin von der Rechenleistung her, aber die ist auch nicht der limitierende Faktor beim osdpip Plugin.

Doch natürlich über die DVB-Karte. Ist überhaupt kein Problem.

Salaam

Zitat

Originally posted by salaam

Doch natürlich über die DVB-Karte. Ist überhaupt kein Problem.

Salaam

Wenn dann vollständig zititieren

Zitat

jarny:

aber nicht über das OSD der DVB-Karte, oder? Sicher sind problemlos 25 fps drin von der Rechenleistung her, aber die ist auch nicht der limitierende Faktor beim osdpip Plugin.

Andreas

powarman hat mich gemeint! Deshalb steht da ja auch: jarny vor seinem Beitrag!!
Bei deinem Betrag war das schon klar mit dem OSD, mein Beitrag war missverständlich.

Gruß
Jarny

jungs, der av7110 schafft im osd modus keine 25fps. das problem ist weder der
rechner noch pci oder sonstwas. es ist einfach die architektur auf der dvb
karte. ist eh schon erstaunlich, das es ueberhaupt geht.

btw, ein fullscreen 24bit farbbild dauert gute 7 minuten zum darstellen - egal
was fuern rechner druntert

-- randy

randy:

Wenn man davon ausgeht, dass jeder Bildpunkt mit einem syscall gezeichnet wird, geb ich Dir recht... Mit SetBlock (also so wie jetzt auch) würde sich die Zeit für ein Fullscreen-Update höchstens vervierfachen (also ausgehend von einem Fullscreen-Refresh etwa zwei Sekunden).

BTW (@all) ist das OSD von VDR seit jeher dadurch beschleunigt, dass nur geänderte (also sehr kleine) Bildbereiche an die Karte übermittelt werden. Wäre das nicht der Fall hätten sich bestimmt schon vor Jahren Leute über die OSD-Geschwindigkeit beschwert

Hi,

imho ist der Flaschenhals nicht der ARM, sondern der Datentransfer durch's DPRAM. Wenn ich das richtig gesehen habe, dann gehen die OSD-Daten in 1 KByte Häppchen in Richtung ARM. Das ergibt natürlich eine ziemlich miese Performance.

Evtl. könnte man die Datenmenge durch Kompression reduzieren.

Oder man könnte das Buffer-Handling optimieren.

Höchstwahrscheinlich ist es sogar möglich, das 4Kx16 DPRAM durch ein 8Kx16 oder sogar 16Kx16 zu ersetzen. Das würde den Durchsatz drastisch verbessern. Müßte man sich aber noch mal genauer anschauen. Allein vor dem Löten des DPRAM-Chips graut's mir - 100 Pin TQFP im 0,5mm Raster.

CU
Oliver

UFO:

Meine Güte Du kommst auf Ideen

Was mich mal interessieren würde wäre ob die DVB Karte RLE codierte Daten akzeptieren und verarbeiten kann. Die DxR3-Karte kann das nämlich und das Plugin nutzt es auch aus.

Was meinst Du mit Buffer Handlin optimieren?

Zitat

Original von LordJaxom
Meine Güte Du kommst auf Ideen

Tja, wenn's einmal angefangen hat...

Zitat

Was mich mal interessieren würde wäre ob die DVB Karte RLE codierte Daten akzeptieren und verarbeiten kann. Die DxR3-Karte kann das nämlich und das Plugin nutzt es auch aus.

Noch geht das nicht. Sollte aber imho kein Problem sein, ARM-seitig einen RLE-Decoder in den OSD-Code-Zweig einzubauen. Müßte dann halt Klaus machen. Erscheint sinnvoll. Wenn die Karte im Transfermode ist, wird das OSD schon etwas lahm.

Zitat

Was meinst Du mit Buffer Handlin optimieren?

Momentan gibt es im 8KByte DPRAM 4 Puffer. Hoffe, es stimmt, was ich jetzt schreibe.
- 2x 2KByte: ARM -> PC (Aufnahme)
- 1x 2KByte PC -> ARM (Wiedergabe)
- 1x 1KByte PC -> ARM (OSD)

Es fällt auf, daß die Puffer fest zugeordnet sind und immer nur in einer Richtung verwendet werden. Ich denke, daß man das besser lösen könnte (flexible Zuordnung, Nutzen der Puffers für beide Richtungen). Könnte evtl. die Interruptllast für PC und ARM reduzieren. (Wobei ich halt nicht weiß, wie das alles auf ARM-Seite realisiert ist. Ich sehe da aber kein grundsätzliches Problem.)

CU
Oliver

Zitat

Original von UFO
Höchstwahrscheinlich ist es sogar möglich, das 4Kx16 DPRAM durch ein 8Kx16 oder sogar 16Kx16 zu ersetzen. Das würde den Durchsatz drastisch verbessern. Müßte man sich aber noch mal genauer anschauen. Allein vor dem Löten des DPRAM-Chips graut's mir - 100 Pin TQFP im 0,5mm Raster.

Update:
Hab' mir mal die Beschaltung des DPRAM genauer angesehen. Das vorhandene 4Kx16 SDRAM könnte problemlos durch ein 8Kx16 ausgetauscht werden. Die zusätzlich benötigte Adreßleitung ist sogar schon korrekt verdrahtet!

Beim Apotheker kostet so ein 8Kx16 DPRAM übrigens ~32 Euro.

Ein großer Nachteil der Sache wäre allerdings, daß man die Kompatibilität mit allen bisher existierenden Firmware-Versionen verliert, d.h. die Karte würde nur noch mit einer neuer Firmware funktionieren...

Daher sollte man erst mal versuchen, den OSD-Datentransfer mit der jetzigen Hardware zu optimieren. Wenn das allerdings nicht reicht, könnte man auch noch das DPRAM vergrößern.

CU
Oliver

Tach auch...

heute nur zwei Sätze von mir...

Osdpip 0.0.5 lief nach 5 Minuten, daher heisst es wahrscheinlich auch 5
Bei meinem 2.6er XP hab ich mit I,P Frames ne stabile und auch recht flüssige Darstellung. Mit I,P,B stürzt er nach ner Weile mit nem Segfault ab, wieso auch immer.

Was mein Namensvetter da mittlerweile mit so ner DVB-Karte veranstaltet, ist schon (trotz krummer Kabel) der pure Wahnsinn. 0.5 mm ??? Mir bleibt die Spucke wech. Wenn das man klappt. Ich drück dir auf jeden Fall die Daumen...

Winke Olaf

P.S.: Na gut, zwei ABsätze