Posts by jojo61

Ich werde es mir ansehen. Ich hatte das openglosd einfach übernommen und dachte es sei sauber

So nun erstmal die Korrektur vom uint zum FT_ULong. Hoffe das damit das OSD stabiler läuft.

9000H kannst du das mal testen ?

mfg

jojo61

9000H Sehr gut beobachtet.

Das ist definitiv falsch und wohl schon seit ewigen Zeiten im openglosd. Ich werde es korrigieren, bin aber erstmal bis Mittwoch unterwegs

mfg

jojo61

Hmmm da stürzt in libfreetype die libGraphicsMagick-Q16.so.3 ab.

Ich sehe das die /lib/libGraphicsMagick++-Q16.so.12 und die /lib/libGraphicsMagick++-Q16.so.3 genutzt werden. Da könnte etwas mit den Libs nicht stimmen.

jojo61

So man kann nun in den General Settings den Cachesize auf 0 setzen und damit das Cache abschalten.

Das sollte für Leute mit "defektem" Treiber ausreichen. Das geht auch jetzt schon erzeugt dann aber nutzlose syslog Einträge.

Jetzt fehlt nur noch der Crash von 9000H  

ofenheizer welchen Kernel nutzt du denn ? Da scheint es ja zu funktionieren.

jojo61

Ja auch von mir vielen Dank für den VDR. Ich bin seit Anfang an dabei noch bevor die erste Mailingliste entstand

Über die Jahre lief er auf der unterschiedlichsten Hardware und ich habe ihn auch im Bekanntenkreis eingeführt. Was mich allerdings nun zum

Admin dort macht und ich die Installationen pflegen darf

Ich wünsche mir das es mehr Entwickler geben würde die die bestehenden oder neue Plugins pflegen würden. Die Plugins sind der entscheidende Unterschied zu kommerziellen Lösungen und da hapert es ein wenig.

jojo61

Da scheint es also ein Problem mit dem Cache bei vaapi (Intel) zu geben. Ich werde das Cache dort jetzt erstmal ausschalten um das Problem zu umgehen.

Ich denke das Cache ist auch nicht mehr so wichtig bei den heutigen Rechnern. Ich werde es optional abschaltbar machen.

Da der GPU Treiber das Cache anscheint manchmal kaputt macht sieht mir das nach einem Treiberproblem aus. Vielleicht sollten wir mal die Kernelversionen vergleichen von denen wo es geht und wo es nicht geht.

beta Danke für die Tests.

jojo61

Wenn du ein Suspend machst vor dem Kodi dann sollte alles gelöscht werden. Aber ich bin kein spezialist für das openglosd. Hänge doch mal den Cache da ab indem du in Zeile 1485 ein return 0; einbaust. Dann sieht man zumindest ob es an dem cache liegt.

baue mal in openglosd.cpp hinter die Zeile 326 ein glFlush(); ein. Die Stelle hatte ich noch vergessen.

Ich hab nochmal nachgearbeitet. Teste nochmal bitte.

9000H wrote:

Hi,

still issues with tvguide and others, with skin lcars and skinnopacity.

malloc(): corrupted top size

Magick: abort due to signal 6 (SIGABRT) "Abort"...

Aborted (core dumped)

CU

9000h

Display More

Was sagt denn da der BT ? Wer stürzt denn da ab ? Ist das mit oder ohne placebo ?

beta Nutzt du die libplacebo ?

Ok ich sehe was passiert bin mir aber nicht ganz sicher warum. Habe mal einen Fix eingecheckt und probiert es mal aus.

Da scheint der Upload der Texturedaten nicht zu funktionieren,

mfg

jojo61

Die größe des OSD speichers sollte hier egal sein. Es gibt in Code noch eine Stelle zwischen dem OSD und dem Videostream anzeigen die nicht verriegelt ist.

Ich werde das mal verriegeln und dann sehen ob es hilft. Bei "langsamen" CPU könnte das die Ursache sein. Würde mich aber trotzdem über einen Screenshot freuen.

jojo61

beta Ich hoffe du redest hier vom softhdvaapi und nicht vom vaapidevice. Das sind unterschiedliche plugins

Kanst du mal einen Screenshot von so einem verwürfelten OSD machen ?

mfg

jojo61

Ich schau mir tvguide mal an. Könnte aber gut sein das der Fehler im tvguide ist.

mfg

jojo61

beta wrote:

Leider stürtzt das Plugin aber mit einem Segfault ab, wenn ich es mit -s -D bei AUSGESCHALTETEM TV starte.

Kannst du mir mal einen BT von dem Absturz zukommen lassen ?

jojo61 wrote:

Das mit den Rückwärtssprüngen schaue ich mir mal an. Da kann man evtl. noch etwas verbessern

Versucht mal "Soft Start a/v sync" zu aktivieren. Das sollte helfen.

ofenheizer wrote:

Weiter habe ich hier eine Aufnahme von Sky 1 HD (scheinbar mit Fehlerchen) wo bei Wiedergabe das Bild komplett stehen. Sonst sind bei Empfangs-Entschlüsselungproblemen einfach nur Pixelfehler und Sprünge in der Wiedergabe. Bei dieser Aufnahme rührt sich nix mehr, auch im Log nicht. Letzter Eintrag ist

Code

1. Feb 8 17:58:37 VDR vdr: [933] [softhddev] vom VDR kommt Clear:
2. Feb 8 17:58:39 VDR vdr: [933] [softhddev] vom VDR kommt Clear:
3. Feb 8 17:58:45 VDR vdr: [4013] ERROR: frame larger than buffer (10236600 > 1048476)
4. Feb 8 17:59:14 VDR vdr: [4013] ERROR: frame larger than buffer (8062568 > 1048476)

Erst bei Sprung (10s) Vorwärts geht es ganz normal weiter.

Der default Puffer am VDR ist auf 1 MB eingestellt. Ich hatte diesen Fehler auch mal und wollte die Buffer auf 2 MB vergrössern, aber dann ging gar nix mehr. Bei dir sind es Frames von 10 MB und 8 MB das wird nie funktionieren. Da ist die Aufnahme einfach kaputt. Evtl. kann ffmpeg das beim umkodieren reparieren aber am Plugin kann ich da nix machen.

Noch etwas; Wie streamst du zum Client ? Streamdev oder minisatip ?

Das mit den Rückwärtssprüngen schaue ich mir mal an. Da kann man evtl. noch etwas verbessern

Murry wrote:

seit der suche nach den memleaks habe ich nach einem deta/atta (kodi) Fehler im Osd. Die OSD Schrift erschein flackernd auf demKopd stehen am oderen Bildschirmrand. Ein vdr neustart behebt dies.

Hmmm am OSD habe ich da gar nichts gemacht. Und auch nichts bei cuvid. Dein Footer sagt du hast ne NVIDIA. Ist das so richtig ?

seahawk1986 wrote:

Gibt es in dieser Zeile im Makefile nicht ein = zu viel?

Heut ist nicht mein Tag... gefixt.

So die Entwicklung von VAAPi und drm ist erstmal abgeschlossen und es wird im Moment nur noch Bugfixing geben.

Die Version für den Raspi habe ich nicht vergessen, aber da warte ich noch auf ein ffmpeg das v4l2m2m auch in Hardware dekodiert. Vorher ist das sinnlos. Und das wird wohl erst mit Kodi 20 etwas werden. Also Geduld ist da angesagt, Das gleiche gilt wohl auch für einen Kernel mit ordentlicher HDR unterstützung. In 5.5 hat sich da wenig getan und der Patch für den NUC ist da auch nicht reingewandert

Ich werde mich nun mal mit den Gammakurven beschäftigen. Wenn man da genauer hinschaut dann ist das ganze HDR geraffel (neben einer höheren Farbtiefe) immer nur angepasste Gammakurven. Damit wird HDR10, HDR10+ und Dolby Vision gemacht. Dafür braucht es eigentlich keinen Fernseher mit diesen Anpassungen. Das geht auch mit angepasster Gammakurve vor dem Fernseher Zudem sind die HDR Gammkurven im Fernseher nicht unbedingt immer die besten für den jeweiligen Film. Das hängt dann davon ab wie er gemastert ist. Da ist man dann ganz schnell in einem großen durcheinander

Was will ich machen ? Ich will erstmal Gammakurven generell unterstützen. Dann möchte ich die Gammakurve in abhängigkeit von dem Umgebungslicht anpassen (ok dazu braucht es Hardware am VDR und das war gerade der letzte Schrei auf der CES Dann möchte ich HLG Gammakurven unterstützen die im Fernseher auf eine BT 1886 Gammakurve trifft.Damit sollte dann HLG an einem "normalen" Fernseher funktionieren (das mach die libplacebo jetzt schon).

Das ganze wird aber noch etwas dauern.

mfg

jojo61