Posts by FireFly

,zip? Musst Du das nicht erst entpacken vor dem Einspielen??

Die Pipes "|" sind Zeilenumbrüche in der epg.data, die werden vom VDR seit jeher darin so abgespeichert und das funktioniert auch. Ich denke, das liegt an Eurem epgd bzw. was dahinter steckt. Mit EPG via DVB-S habe ich keine Probleme.

Woher bekommst Du denn Dein EPG?

MegaV0lt wrote:

Bin ich wirklich der einzige, der den Fehler hat?

Scheinbar ... habe es gerade mal ausprobiert, live und Aufzeichnung:

Die Gäste werden im OSD (skinElchi) auch so angezeigt.

Evtl. ein Patch (zu viel)?

Im Prinzip wird das Plugin noch gepflegt, aber eigentlich arbeite ich seit Jahren am Nachfolger (der endlich TrueColor unterstützt) und finde einfach zu wenig Zeit dafür.

Mit neueren VDR-Versionen ist durch das Locking einiges nicht mehr möglich (zumindest ohne Verrenkungen). Das Tracelog von Dir zeigt den Check bei der Kanalanzeige, ob ein Timerevent gerade läuft, um dann das REC-Symbol andersfarbig darzustellen. Dafür habe ich in VDR 2.4+ bisher noch keine Möglichkeit gefunden außer die Funktion zu disablen, weshalb ich bisher keine neue Version veröffentlicht habe.

Ich denke, vermeiden kann man das nicht. Wenn die Info im DVB-Stream z.B. zu selten gesendet und damit zu spät kommt, hat VDR schon die info-Datei geschrieben. Da der VDR in aktuellen Versionen bei ihm bereits bekannten Aufnahmen die info-Datei beim Rescan (touch .update) nicht neu einliest hilft nur ein VDR-Neustart oder Umbenennen der Aufnahme auf der Komandozeile und anschließendes touch .update

Für Serienaufnahmen ist das im VDR eigentlich so gedacht, dass Du ein Verzeichnis "Zu Tisch" (EPG Title) hast und darin je eine Aufnahme mit "Lyon", "Paris", "Frankfurt" etc. (EPG ShortText). Dazu musste aber der Timer entsprechend gesetzt sein.

VDRadmin zeigt das nur so an wie es auf de Platte ist.

Bist Du sicher, dass in HW dekodiert wird? Schau mal auf die CPU Auslastung bei SD und bei HD

Hallo Zabrimus,

was mich bzw. meinen Code angeht kannst Du das Plugin gerne weiter entwicklen/verwurschten/verunstalten/benutzen und auch in Dein Repo aufnehmen, aber ich bin auch nicht der erste Ersteller des Plugins. (Filterplugin für hbbtv, ... wie die Zeit vergeht ....)

Bei Fragen dazu kann ich auch gerne helfen, nur möchte ich keinen Aufwand in die CE-HTML Dekodierung stecken wie o.a. Wenn das CE-HTML aber von einem Browser-Plugin komplett erschlagen würde, wäre das eine Lösung, vorausgesetzt man kann das Bild über dem VDR-Bild darstellen.

FireFly

dvb91 wrote:

Sorry, I didn't explain enough.... VDR is totally unusable : live mode, view recording, and of course mvp plugin.

You should compile against ffmpeg 4.x - version 3.x does not always use the video decoder in the GPU....

jojo61 wrote:

FireFly Ich denke du musst das glewinit mal debugen. Das Missing GL version kommt ja daher und da musst du mal in den Quellen schauen wo das erzeugt wird. Soweit ich das gesehen habe gibt es da eine Funktion die die aktuelle GL Version versucht zu ermitteln und das geht bei dir irgendwie schief. Da musst du mal ein paar debug prints reinbauen um zu sehen wo es hackt.

Ja, genau das habe ich ja gemacht. Allerdings kann er die GL Version in glewInit() ermitteln, aber anschließend ruft glewInit() die Funktion eglewInit() auf wo es dann fehlschlägt (das GLEW_ERROR_NO_GL_VERSION ist so ne Art Universalfehlmeldung wenn beim Init irgendetwas schief geht):

Das eglInitialize steht dann in libEGL, das wiederum Funktionen in libglnvd aufruft, was an die HW-spezifischen Treiber weiterleitet oder so. Das habe ich nicht weiter gedebuggt.

Hast Du wirklich nur das ligGLEW selbst kompiliert? Mir kommt es so vor, als würde da bei mir noch was fehlen. Immerhin meldet das Beispielprogramm auch den Fehler, ist also reproduzierbar. Wenn man das return aber auskommentiert läuft es ohne sichtbare Probleme weiter :->

Der OpenGL Benchmark glmark2-es2 bricht ebenfalls ab, glmark2 (ohne ES) funtkioniert. Geht das bei Dir?

Was gibt bei Euch denn ein glxinfo | grep OpenGL aus? Ist das normal dass dort oben 4.5 als Core Profile steht, aber unten dann nur 3.0 als version string? Bei VAAPI scheint das "normal" zu sein, bei NVidia steht da die gleiche OpenGL version wie bei core Profile: OpenGL version string: 4.6.0 NVIDIA 390.132

jojo61 wrote:

Das DRM plugin nutzt ja auch vaapi als dekoder. Ich bin immer noch der Ansicht das die glew installation nicht sauber ist. DRM nutzt im OSD kein glew und VAAPI nutzt glew im OSD. Wenn man glew neu übersetzt und dann mit ldconfig lädt, dann übermangelt Suse es wieder mit der alten Version. Deswegen sollte man es nach usr/local/lib installieren und im ld.so.conf den Pfad /usr/local/lib nach vore legen. Dann nimmt er die neue glew zuerst.

Da hast Du insofern Recht als dass in meinem selbstgebauten RPM noch ein Fehler drin war (beim install baute er es nochmal ohne EGL). Jetzt passt es aber:

Erfolg hat das aber nicht gebracht:

Ich habe schon versucht die GL Version zu setzen im Source Code oder mit MESA Umgebungsvariable, ohne Erfolg. Auch mit und ohne .drirc

Update: Ein Testprogramm liefert jetzt ebenfalls bei glewInit() keine GL Version - ich versuche das mal zu debuggen

Update2: in libglew schlägt eglInitialize() fehl, sowohl auf dem Nvidia-PC als auch auf dem Intel-PC. EGL Libs scheinen aber alle installiert zu sein

Nachdem bei mir immer noch kein OSD mit vaapi angezeigt wird habe ich mal drm ausprobiert und da bekomme ich das OSD angezeigt, aber nach kurzer Zeit ruckelt das Bild, es gibt Artefakte bis zur Unkenntlichkeit des Bildes und buffer overflows im Log. Die GPU ist zwar lt. gpu-top zu 25% mit rendern beschäftigt, aber offenbar wird ja ein Großteil der Arbeit von der CPU verrichtet. Wo wird das das konfiguriert, wo kann man da was nachsehen?

Kann für das OSD mit vaapi irgendwo Testcode in das Plugin einbauen? Wenn ja wo?

beta wrote:

FireFly : Kannst Du zum Testen einmal folgende Variablen vor dem VDR-Aufruf setzen:

Code

1. MESA_VENDOR_OVERRIDE="mesa" MESA_RENDERER_OVERRIDE="mesa" MESA_GL_VERSION_OVERRIDE=4.5COMPAT vblank_mode=0 mesa_glthread=true

Das macht dann die Dekodierung in Software, oder? Weil es ruckelt und der Ton wird asynchron nach kurzer Zeit. OSD wird aber auch keins angezeigt und beim zweiten Einblenden bleibt das Videobild auch hängen. Die GPU ist aber trotzdem zu 100% mit Render beschäftigt lt. intel_gpu_top bei der max. GPU-Frequenz.

jojo61 wrote:

Ich kann dir mal ne Liste machen mit allen Paketen die ich installiert habe.

Ja bitte, am besten per PN, auch wenn ich vorr. erst nächstes Wochenende wieder zum Testen komme.

jojo61 wrote:

Hattest du auf dem Rechner evtl. mal den NVIDIA Treiber installiert. Der würde die Mesa installation kaputt machen (nur so ne Idee).

Nee, außer wenn es durch ne Abhängigkeit installiert worden wäre. Aber in dem Rechner war nie ne NVidia-Karte drin. Außerdem habe ich erst die neueren und dann wieder die alten Mesa-Pakete installiert.

jojo61 wrote:

Das mit dem externen setzten von VAAPI=1 kann ich gerne einbauen. Nur leider bin ich kein Makefilespezialist. Kannst du da helfen ?

Einfach mit Name ?= Wert, dann wird Name nur definiert wenn es bisher nicht definiert war (wobei ein leerer Name bereits als definiert gilt)

jojo61 wrote:

FireFly Gehts denn nun ?

Nö, sonst hätte ich das geschrieben. Immer noch das gleiche Verhalten: Nach dem Start des VDR kommt das Videobild ohne OSD und wenn das zweite mal ein OSD aufgemacht werden soll bleibt das Videobild stehen (immer noch ohne OSD) und nur noch der Ton läuft weiter.

Alle openGL Testprogramme, die im Netz finde und kompiliere, oder glmark2 funktionieren aber.

Ich verliere langsam die Lust weiter zu suchen ....

Schreibe doch mal die Voraussetzungen ins Readme.

Außerdem wäre es schön wenn man für die Paketerstellung das VAAPI=1 etc extern setzen könnte und nicht das Makefile patchen muss

Mit COMPATIBILITY_PROFILE

stürzt er mir ab:

Mit CORE_PROFILE:

bekomme ich openGL 4.5, was ja langen sollte, auch mit dem "alten" Mesa 18.3.2:

Irgendwie gefällt mir das nicht ....

Immer noch 3.0 .... Hat aber wohl nicht viel zu bedeuten denn:

Mit der Mesa Version hat das nichts zu tun: auf meinem PC mit ner Uralt NVidia Karte meldet glewinfo openGL 4.6.0

jojo61 wrote:

FireFly Das bringt mich auf eine Idee. Bau doch mal in openglosd.cpp folgendes ein:

Code

1.     glutInit(&argc, argv);
2. + glutInitContextVersion( 3, 3 );
3. + glutInitContextProfile( GLUT_COMPATIBILITY_PROFILE );
4. glutInitDisplayMode (GLUT_SINGLE | GLUT_RGBA | GLUT_ALPHA);

Dann findet glewInit hoffentlich eine GL Version

Damit bekomme ich:

glewinfo zeigt übrigens:

GLEW version 2.1.0

Reporting capabilities of display , visual 0x143

Running on a Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2) from Intel Open Source Technology Center

OpenGL version 3.0 Mesa 18.3.2 is supported

... und das erste MISSING kommt bei GL_VERSION_4_1

Wenn ich glutInitContextVersion( 3, 0 ); nehme habe ich kein Videobild mehr (OSD auch nicht). Ich versuche mal das glew in ein RPM-Paket zu bekommen

jojo61 wrote:

Wenn jemand weiss wie ich GL sagen kann das er Version 330 nehmen soll dann bräuchte ich kein .drirc

mfg

jojo61

Hilft das evtl?
https://sites.google.com/site/…pengl-context-and-profile

jojo61 wrote:

Da ist wohl immer noch etwas faul mit dem glew. Nun stürzt der OSD thread ab. Versuch erstmal dein GLEW inOrdnung zu bringen.Das kannst du mit glewinfo testen.

Was meinst Du mit "in Ordnung bringen"? ich habs mit SYSTEM=linux-egl kompiliert und die originalen Libs vom RPM mit den neuen überschrieben. Was gibt bei Dir

glewinfo |grep -i egl|grep -c OK

und

glewinfo |grep -i egl|grep -c MISSING

Oder hänge mal bitte den kompletten Output Deines glewinfo an.

Müssen evtl. noch mehr Libs selbst kompiliert werden?

Habe mir den Error mal ausgeben lassen:

Das sieht aber so aus als wäre glew ok