[ANNOUNCE] Avards-Plugin 0.1.4

Hi Firefly,
Warum funktioniert Avards nicht mit Xineliboutput und Softdevice?

Ich weiss, die haben etwas theoretisch ähnliches drin, aber das klappt nicht annähernd so gut wie bei Avards...

mfG,
Stefan

Zitat

Original von steini
Was kann das sein? Mit älteren Treibern (2.6.13.12er Kernel mit den Refactoring-Treibern vom Oliver) funktioniert alles super.

Vermutlich hast Du den Kernel bzw. die DVB-Module ohne v4l1-Support compiliert.

Gruß
e9hack

e9hack,
danke für den Hinweis. Hab den Kernel jetzt mal neu mit

CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEO_V4L1=m

Avards startet jetzt, gibt aber trotzdem folgendes aus

Mar 22 19:15:05 activy user.err vdr: [1759] avards: switching WSS to 16:9
Mar 22 19:15:05 activy user.err vdr: [1759] avards: Error: Can't open vbi device '/dev/vbi0' (No such device or address)

oder

Mar 22 19:20:32 activy user.err vdr: [1759] avards: switching WSS to L16:9
Mar 22 19:20:32 activy user.err vdr: [1759] avards: Error: write to vbi device failed (Bad file descriptor)
Mar 22 19:20:32 activy user.err vdr: [1759] avards: closing vbi device

vbi ist als Link auf vbi0 vorhanden und vbi0 wird auch angelegt. Also stimmt da was noch nicht. Hat sich da vielleicht an den Devices was geändert?
Gruß
Steini

Zitat

Original von FireFly
steini: was gibt ein "ls -l /dev/vbi*" aus?

Hier'n Ausschnitt:

lrwxrwxrwx    1 root     root            9 Nov 27  2007 /dev/vbi -> /dev/vbi0
crw-rw-rw-    1 root     root      81, 224 Jul  1  2003 /dev/vbi0
crw-rw-rw-    1 root     root      81, 225 Jul  1  2003 /dev/vbi1

sieht für mich normal aus

Zitat

Original von FireFly
Innerhalb Avards hat sich am vbi-Device nix geändert, aber das ist ja auch nicht der Thread zur aktuellen Version

Nee, ich meinte ja ob sich da im Treiber was geändert hat. Ich hab auch die 0.1.5 von Avards.....ändert auch nix;)
Der Treiber wurde auch nicht neu geladen, ich hab da glaub ich alles gelesen was geht...zuerst natürlich deine README.
Dieses Problem tritt reproduzierbar immer auf und nur bei diesen neueren Treibern, beim "alten" Treiber nie, auch nicht wenn der Treiber neu geladen wird.
Ich denke das liegt am Treiber oder an meiner Konfiguration. Vielleicht hat ja jemand da ne Idee.
Gruß
Steini

Hi, hilft das evtl.?
http://zapping.sourceforge.net…zvbi/group__DVBDemux.html

Was wird denn gebraucht für avards? ein /dev/vbi device und eine Videoquelle. Könnte man dafür nicht grabimage nutzen oder so wie es das Live-Plugin macht?

Sollte doch dafür reichen?

mfG,
Stefan

Hi,

Es geht mir um das richtige Erkennen des Bildformats und dessen Weitergabe! WSS ist nicht wichtig bei xineliboutput und softdevice, da dort eh eine feste Ausgangsauflösung eingestellt ist! VDR soll halt nur da dann die richtigen Letterboxen einfügen (bzw. das Plugin). Nur darum gings!

Und ich hatte es so verstanden, dass avards grabimage braucht um einen Frame zu grabben? Und da dachte ich, sollte auch was anderes gehen, da das Live-Plugin auch mit was anderem als FF funktioniert!

mfG,
Stefan

Hi,
Wie das Live-Plugin das macht ist eine gute Frage, da muss ich passen, müssdte man mal den Entwickler fragen!
Aber geht grabimage nur bei FF?

Zum Xineliboutput-Plugin:
Ich werde rnissl mal befragen, wie man das einbauen könnte. Der macht das Plugin. Das hat feste Ausgabeauflösung und baut halt letterboxen ein, damits passt, muss also auch wissen, welches Format grad gesendet wird und dafür könnte man besser deine Routine nutzen, da die besser funktioniert!

mfG,
Stefan

Zitat

Original von FireFly
Das Grabben kenne ich bisher nur von /dev/video bei FF-Karten. Weißt Du wie das Live-Plugin das macht?

Das Live-Plugin verwendet die GrabImage()-Funktion. Avards kann man per Patch auch dazu überreden, GrabImage() zu verwenden.

Zitat

xineliboutput etc. haben also eine feste Auflösung (ich habe bisher nur mit FF Erfahrung). Wie kann man denen dann im laufenden Betrieb ein anderes Bildformat unterschieben?

Der Bildinhalt wird hochskaliert. Die Frage ist nur, was GrabImage() zurückliefert. Wenn es das Mpeg dekodierte Bild ist, könnte AvardsXXL ein Signal an xineliboutput senden, das die Skalierung umschaltet. Wenn GrabImage() den Letterbox-Rand nicht mit liefert, funktioniert das Verfahren so nicht.

Gruß
e9hack

FireFly,
nochmal kurz zu meinem Problem.
vbi-Devices legt man doch selbst an...oder täusche ich mich da? Ich hab da ne ganze Menge von....mehr als 10.
Das Problem liegt woanders. Ich werde das weiter untersuchen wenn ich dafür mehr Zeit habe. Die Tools wie dvb-aspect und dvb-wss-overdrive funktionieren auch nicht mit den gleichen Fehlermeldungen.
Es würde mir dabei nur sehr helfen wenn mir jemand bestätigen würde dass avards mit den ganz aktuellen Treibern funktioniert.
Die letzten Treiber von Oliver (UFO) vom September 2008 funktionieren bei mir damit noch, die ganz aktuellen jedoch nicht.
Vielen Dank
Gruß
Steini

Zitat

Original von steini
vbi-Devices legt man doch selbst an...oder täusche ich mich da? Ich hab da ne ganze Menge von....mehr als 10.

vbi-Devices werden vom Treiber/Modul angelegt. Es gibt genau eins pro FF. Selber bzw. per udev wird nur ein Link von /dev/vbi auf /dev/vbi0 angelegt.

Zitat

Es würde mir dabei nur sehr helfen wenn mir jemand bestätigen würde dass avards mit den ganz aktuellen Treibern funktioniert.

Avards funktioniert mit den aktuellen Treibern. Ich verwende zwar ein verpatchtes Avards, abe das bezieht sich nur auf den Input.

Gruß
e9hack

Hi,

So hab grad n interessanten Chat mit rnissl, den ich euch nicht vorenthalten möchte:

ª 23:04 Wäre der Einbau von Avards in Xineliboutput denkbar?

ª rnissl_ Montag, 23. März 2009
ª 23:05 was macht avards gleich wieder

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:06 korrekte seiteverhältniserkennung bei FF Karten
ª 23:06 und dann das WSS Signal an den TV am Scart senden, aber das ist unwichtig...

ª rnissl Montag, 23. März 2009
ª 23:07 du meinst, wenn z. B. 4:3 in 16:9 mit schwarzen balken gesendet wird?

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:07 Ich finde die Seitenverhältniserkennung von Avards klappt besser als die interne, hatte heut schon n Thread im Portal mit Firefly darüber, der das Plugin macht
ª 23:08 nein die Erkennung, was gesendet wird
ª 23:08 also, dass er merkt, jetzt wird grad 4:3 gesendet und dann halt die Balken einbaut

ª rnissl Montag, 23. März 2009
ª 23:09 also es kommt 4:3 und es soll mit schwarzen balken zu 16:9
ª 23:09 ergänzt werden?

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:10 ja, das macht Xineliboutput doch, oder nicht?

ª rnissl Montag, 23. März 2009
ª 23:10 das macht xine-lib von ganz alleine

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:10 damit man ne feste statische Auflösung hat
ª 23:11 ja, es geht nur um die Erkennung, welches Format das gesendete hat
ª 23:11 und da ist die Xinelib-Erkennung schlechter funktionierend als die von Avards

ª rnissl Montag, 23. März 2009
ª 23:11 man kann das z. B. über ein video post plugin lösen

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:12 daher hatte ich die Hoffnung, man könnte die Avards- Erkennung nutzen

ª rnissl Montag, 23. März 2009
ª 23:13 also wenn ich das richtig verstehe, dann wird das bild ausgelesen und geschaut ob sich an den rändern schwarze balken befinden
ª 23:14 und dann obwohl der sender sagt, es wäre 4:3 z. B. 16:9 verwendet und hineingezoomt

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:14 ja genau

ª rnissl Montag, 23. März 2009
ª 23:14 typischer fall: 16:9 tv, sender strahlt film (16:9) via 4:3 aus

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:14 genau

ª rnissl Montag, 23. März 2009
ª 23:14 gibt rund rum einen schwarzen rahmen

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:14 ja

ª rnissl Montag, 23. März 2009
ª 23:16 also vdr-xine würde einen screenshot zurückliefern, der das format des tv hat
ª 23:16 also in obigem fall, wäre der schwarze rahmen enthalten

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:17 avards liest das bild über grabimage ein

ª rnissl Montag, 23. März 2009
ª 23:17 genau, passt für vdr-xine perfekt

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:18 bzw. die neueste avards ist mit einem patch versehbar, der das ermöglicht, ansonsten geht das nur bei FF,

ª rnissl Montag, 23. März 2009
ª 23:18 und wie stellt es dann den zoom ein?

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:18 bin kein Entwickler sorry, frag lieber Firefly, ich kenn auch nur den Fred und die Homepage
ª 23:19 aber wäre ein echter Gewinn!

ª rnissl Montag, 23. März 2009
ª 23:19 das problem ist wohl, es gibt eine definierte schnittstelle um dies Plugins mitzuteilen

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:20 das zoomen könnte man ja evtl. sogar noch in Grafik-Hw auslagern aus Performancegründen

ª rnissl Montag, 23. März 2009
ª 23:20 das macht es für vdr-xine fast unmöglich
ª 23:20 äh, stimmt so nicht
ª 23:21 auch das würde noch passen, solange das bild nicht verschoben wird

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:21 frag ihn doch mal im Thread
ª 23:21 man müsste halt avards zwischen decoding und Ausgabe schalten

ª rnissl Montag, 23. März 2009
ª 23:21 sonst kann ich das in vdr-xine nicht mehr lösen -- aber xineliboutput könnte

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:22 geht ja nur ums Xineliboutput-Plugin

ª rnissl Montag, 23. März 2009
ª 23:22 blos ist das schon arg aufwendig, das bild via grabimage zu diesem zweck zurückzuliefern

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:22 hmm ok, kann ich nich beurteilen...
ª 23:23 Ich weiss nur es funktioniert mit ner FF perfekt, ein echter Mehrgewinn
ª 23:24 als Gimmick wäre sogar eine Funktion für Sportübertragungen denkbar die Werbung erkennt und das Splitscreen auf das doppelte hochzoomt, für ne spätere Version
ª 23:24 auf Tastendruck
ª 23:25 es muss nich grabimage sein, kann Xineliboutput ein /dev/video bereitstellen?

ª rnissl Montag, 23. März 2009
ª 23:25 gegen die funktion spricht nichts, nur die implementierung wäre besser in xine-lib aufgehoben, dann bräuchte man nicht soviel hin und herübertragen

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:26 das machen die FF ja, und so macht es die Standardversion und greift die dort ab

ª rnissl Montag, 23. März 2009
ª 23:26 /dev/video zu emulieren wäre ähnlich komplex
ª 23:26 das problem ist, das das videobild halt in einem anderen Prozess exisitert

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:27 das wäre ja kein Problem, der Code sollte ja verfügbar sein
ª 23:28 könnte man ja abschaltbar im plugin implementieren

ª rnissl Montag, 23. März 2009
ª 23:28 ich hatte xine-lib's expand plugin dahingehend erweitert, dass es 4:3 in 16:9 erkennt und als 4:3 zur verfügung stellt

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:28 aber grabimage sollte doch eh schon implementiert sein, da sonst doch auch graphtft-fe das nicht bekommen könnten?

ª rnissl Montag, 23. März 2009
ª 23:29 also einfach mal als --post plugin angeben, evtl. tut das dann schon

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:29 du meinst avards als postplugin beim xineliboutputaufruf?
ª 23:30 --post avards?

ª rnissl Montag, 23. März 2009
ª 23:31 dachte aber eher an --post expand mit einem Sack parameter

ª rnissl Montag, 23. März 2009
ª 23:31 schau mal expand an
ª 23:32 dort gibt es centre_crop_out

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:32 ok mach ich, ok

ª rnissl Montag, 23. März 2009
ª 23:32 ist für 4:3 in 16:3 als 4:3 gedacht
ª 23:32 funktioniert aber nicht mit vdpau oder xxmc
ª 23:32 nur mit x11 oder xv

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:32 ja, aber tw senden die auch in 14:9 etc.

ª rnissl Montag, 23. März 2009
ª 23:33 müsste man halt mal etwas anpassen

ªSurfaceCleanerZ Montag, 23. März 2009
ª23:44 was sagst du zur Verwendung vom Toms MoComp, schon mal versucht?

ª rnissl Montag, 23. März 2009
ª 23:47 mit hardwarebeschleunigung gehen diese deinterlacer nicht

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:48 ok klar
ª 23:48 aber ist das so cpu lastig, wenn man nur das deinterlacing in cpu macht?
ª 23:48 decoding scalen etc kann ja alles gpu machen trotzdem

ª rnissl Montag, 23. März 2009
ª 23:51 decoding legt die daten in der graka ab -- bei xxmc gibt's keine api um darauf zuzugreifen
ª 23:51 und bei vdpau bremst das ungemein

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:51 hmm das is sehr doof

ª rnissl Montag, 23. März 2009
ª 23:51 vdpau's deinterlacer sind nicht schlecht

ª SurfaceCleanerZ Montag, 23. März 2009
ª 23:52 du meinst spatial_temporal?
ª 23:52 als besten

ª rnissl Montag, 23. März 2009
ª 23:52 genau

So ich ergänze, wenns noch weiter geht!

mfG,
Stefan

Zitat

Original von SurfaceCleanerZ
So hab grad n interessanten Chat mit rnissl, den ich euch nicht vorenthalten möchte:

Da hast Du mit rnissl aber über die falschen Sachen geredet. Beim Avards-Plugin geht es primär um die Letterbox-Erkennung bei 4:3. Der Fernseher soll ein 4:3 Bild mit schwarzen Balken oben und unten auf ein 16:9 Bild ohne Balken aufzoomen.

Ein Erkennen von 4:3 bzw. 16:9 ist simpel. Die Info wird im MPEG-Header übertragen.

Gruß
e9hack

Hi,

nee das hat er wohl schon verstanden.

Es wäre schon einfacher, wenn du oder Firefly mal direkt mit ihm darüber chatten würdest, bin kein Programmierer

mfG,
Stefan

Hi,
ich möchte nur noch kurz erwähnen dass es wie vermutet an meiner Konfiguration liegt. Wenn ich udev für die Treiber- und Devicekonfiguration nehme klappt Avards auch mit den aktuellen Treibern.
Zur Info: Ich hab schon seit langer Zeit keine konventionelle Distri sondern eine Minimalinstallation so in etwa wie die Struktur von Linvdr und auf der Basis von Debian lenny und auf einer 512MB CF-Disk. Da sind die Devices fest angelegt, also z.B mit "mknod /dev/vbi0 c 81 224". Bei den aktuellen Treibern geht das bzg. dem vbi-Device so offenbar nicht.
Nachdem ich udev testweise eingebunden habe funktioniert allles wie geschmiert
Ich muss jetzt nur noch schauen wie ich udev sauber integriere.....ohne dass da permanent Schreibzugriffe auf die CF stattfinden. Ich denke aber das da nichts geschrieben wird außer auf tmpfs, also ins RAM.
Vielen Dank für Eure Unterstützung.
Gruß
Steini