Posts by rell

    @ 2) Wenn jemand beisteuern will, MUSS er sich einen fork ziehen und einen PR stellen,

    Das wäre wohl der Ende der Mitarbeit so mancher hier. git eine echte Hürde.

    Möglich. Es kann aber auch eine Chance sein. Möchte sich jemand outen, für den git ein absolutes No-Go wäre? git funktioniert nur, solange jemand damit arbeiten möchte.... und git löst nicht das Problem, dass überhaupt jemand daran arbeiten möchte.


    @ 6) der Code steht unter der AGPL

    Wohl der absolut wenigste code hier.


    GPL: If you publish the software, you have to do the same for the source code of it and any library that it borrows functions from.AGPL: If your software gives service online, you have to publish the source code of it and any library that it borrows functions from.

    Richtig, Fehler von mir.

    Erstmal zu git...

    Wenn man mal das Wichtigste verinnerlicht hat, funktioniert git super.

    Mit "git add ." "git add -p" "git commit" "git rebase -i" "git reset" "git push" "git pull" kommt man schon recht weit.

    Und die ausgefalleren Sachen, und wenns bloß darum geht, einzelne Änderungen wieder in die Staging Area zu setzen, muss ich auch immer wieder googlen, da würde in der Tat ein kleines privates cheatsheet helfen ...

    Ich möchte git nicht mehr missen und wenn man sich bei der Zusammenarbeit mit anderen an ein paar Regeln hält, funktioniert auch das. Was mal in einen Hauptbranch/master gepusht wurde, bleibt da. Ein Rebase erzeugt da nur Chaos und Ärger bei denen, die schon gepullt haben. Das wäre aber auch schon die wichtigste Regel...


    Und jetzt meine Meinung zur Gesamtsituation ... :)

    Ich sehe das Grundproblem nicht bei Git oder nicht-Git. VDR bzw. eigentlich seine Plugins haben einfach das grundlegende Problem, dass die Hierarchie fehlt, die es bei größeren Projekten (libreelec, mesa, kernel etc.) gibt. Maintainer und Reviewer. Und es fehlen klare Regeln, an die sich jeder halten MUSS. Ohne die funktioniert es nicht und es bleibt beim Chaos, dass man den richtigen fork und die patches nicht mehr findet. Jetzt bin ich wirklich auch lange dabei. Überwiegend als Nutzer, aber auch hier und da mal mit etwas Code und wage zu behaupten, dass ich Linux, VDR und C einigermaßen gut verstanden habe. Aber auch ich tat mich vor einigen Monaten beim Wiedereinstieg schwer, mir erstmal einen Überblick zu verschaffen, was gerade so Sache ist. Da liest man einige Threads hier durch und kann sich auch nicht sicher sein, ob das, was im Wiki steht, noch aktuell ist.


    Die angesprochenen Regeln würde ich folgendermaßen definieren:

    /* Wunschvorstellung an */

    1) Es MUSS eine zentrale Stelle geben, an der sämtlicher VDR Code zu finden ist, z.B. https://github.com/vdr-projects

    2) Es gibt keine Mirrors dort, sondern ALLE Plugins, zu denen wer-auch-immer noch beisteuert, liegen dort im Original und die Leute, die sich drum kümmern haben commit Rechte. Das Plugin MUSS dort sein Hauptrepository haben. Wenn jemand beisteuern will, MUSS er sich einen fork ziehen und einen PR stellen, oder er findet jemanden, dem er seinen Patch schickt, der halt dann den PR stellt. Patches hier ins Forum zu stellen ist ja schön, bringt aber m.E. gar nichts, wenn man sich nicht gerade mit dem Thema beschäftigt. Ein Issue auf Github mit dem Patch wäre schon besser, als hier im Forum versteckt. Dann wäre er zumindest schon mal in der richtigen Gegend. Der Riesenvorteil von git, den ich sehr schätze, ist, dass man einen PR reviewen, testen und kommentieren kann. Man kann ihn verändern lassen und wenn man dann zufrieden ist und er auch wirklich läuft, wird er eingecheckt. Die Diskussion könnte zwar hier im Forum auch stattfinden, aber das ist nicht wirklich komfortabel. Klar, damit das alles klappt, brauchts erstmal Leute, die sich kümmern. Das Hauptproblem an sich.

    3) Plugins, die nicht mehr gepflegt werden, offensichtlich nicht genutzt werden, oder evtl. gar nicht mehr laufen, MÜSSEN entfernt werden. Ich wäre da rigoros. Wenn jemand etwas vermisst, meldet er sich schon. Oder er legt selbst Hand an und reaktiviert das Plugin. Ich weiß auch, dass die Hemmschwelle dafür ziemlich hoch ist und vielen das Know-How fehlt oder sie nicht bereit sind oder die Zeit haben, sich das nötige Wissen anzueignen. Jammern lasse ich aber nicht gelten. Jeder hat mal angefangen. Ein Plugin, das nur einer nutzt, kann so wichtig nicht sein. Und wenn es mehrere am laufen haben wollen, steigt ja theoretisch die Chance, dass einer dabei ist, der gewillt ist. Ansonsten kann er ja auch betteln gehen. Dafür braucht er eine Anlaufstelle, wobei wir indirekt beim nächsten Punkt wären.

    4) Das Wiki ist schön und gut aber man kann sich nicht sicher sein, ob da alles stimmt. Also ist es defacto unbrauchbar. Als Beispiel, ich war dabei, als linux-sunxi.org erstellt wurde. Da gab es zwar harte Regeln für alle, die sich einbringen wollten oder Hilfe benötigten, aber am Anfang hat das richtig gut geklappt und das wiki war in Top Zustand. Mittlerweile verwässert alles, viele Seiten sind outdated. Liegt daran, dass das Wiki gewachsen ist, die Disziplin nachlässt und schlichtweg die Motivation und Zeit der "Maintainer" fehlt, da mal wieder aufzuräumen. Die sunxis laufen mittlerweile einfach, ohne dass man notwendigerweise dem Wiki beisteuert. Aber ich behaupte mal, dass es die mainline kernel Unterstützung ohne dieses Wiki und dessen Disziplin nie gegeben hätte. Aber das nur so am Rande. Was bleibt als Anlaufstelle?

    5) Das Forum. Ich persönlich schätze es sehr. Alleine schon wegen des Umgangstons miteinander. Das war zu Zeiten von linvdr teilweise noch anders :) Jeder bekommt hier Hilfe, sofern man auch etwas Eigeninitiative erkennen kann. Und sei es nur, dass ein Log gepostet wird.

    Im Forum MUSS aber klar ersichtlich bzw. schnell zu finden sein, wo man aktuelle Plugins findet bzw. wo es eine aktuelle Liste (z.B. https://vdr-projects.github.io/) gibt und wie eigentlich die Regeln so sind...

    6) Jeder hält sich an diese Regeln. Wäre schön, aber wird schwierig. Alle? verbliebenen Entwicklern kümmern sich um VDR in der Freizeit, der Code steht unter der AGPL, warum soll sich also jemand in ein "Korsett" zwingen lassen? Ich stelle aber mal die Behauptung auf, dass es für die Zukunft von VDR besser wäre, sich selbst ein Korsett zu verpassen. Und nein, ich sehe das Ende von VDR noch nicht am Horizont. Ich bin einer, der VDR nachwievor für lineares Fernsehen und als Videorekorder nutzt.

    /* Wunschvorstellung aus */


    Ein Beispiel zum Schluß: softhd*

    Hier wurde damals leider eine klare Übergabe/Übernahme der Originalversion versäumt, so dass es mittlerweile 3,5? Forks gibt. Es gibt auch mindestens 4 Personen, die sich aktiv damit beschäftigen. Sicher ist jeder Fork für sich eine Bereicherung, aber schöner wäre es natürlich gewesen, alles in einem einzigen Plugin zu haben, was sicher möglich gewesen wäre, da sich einiges überschneidet und wofür git bzw. github o.ä. die richtige Wahl gewesen wäre. Aber leider ist es dafür zu spät, der Aufwand ist wohl zu groß. Wie alles andere, was ich geschrieben habe, soll das natürlich keine Kritik sein.


    Fazit:

    Für ein Fazit reicht es nicht mehr :) Ich hab auch keines. Auch keine Lösung. Ich möchte mich aber auch nicht beschweren. Bei mir funktioniert alles was ich nutze (softhddevice, streamdev, epgsearch, live, markad, tvguideng, skindesigner). Und diese 7 Plugins kann ich mir auch zusammensuchen oder patche selbst...


    Gruß

    Andreas


    PS: Nachdem ich nochmal durchgelesen habe, was ich geschrieben habe, muss ich gestehen, dass ich mich bis jetzt selbst auch nicht immer an diese "Regeln" gehalten habe :)

    Ok. D.h. wir haben die Situation Seite 6 mittlere Grafik. Der Speicherbereich für unser Multimedia liegt "dynamisch" im reservierten CMA-Bereich und kann auch von anderen Nutzern belegt werden, falls softhddevice das nicht tut. Wenn man davon keinen ausreichenden großen zusammenhängenden Bereich mehr frei hat, bekommt softhddevice ein Problem.

    Wenn man über das dts für den Decoder entsprechend CMA reserviert, sollte der Speicher "theoretisch" von niemand anderem benutzt werden dürfen und wir wären auf Seite 6 untere Grafik.


    Soweit so gut. Das erklärt, warum es krachen kann. Aber es erklärt nicht mein Problem mit dem ausgehenden Speicher aus Post #41, oder? Kann das noch jemand reproduzieren?


    Ich glaube, ich werde dann jetzt doch mal CMA für die VPU über das dts reservieren und schauen, was das bewirkt.


    Weiteres Problem:

    Gestern hatte ich das erste Mal das Problem, dass im laufenden Betrieb ein altes Frame "mitgeflackert" ist. Beim Umschalten war das dann wieder weg. Ich weiß nicht, ob ich was besonderes gemacht habe und konnte das bisher nur beobachten, wenn ich eine Aufnahme bearbeitet habe und diese verlasse.

    Kann das auch jemand bestätigen? JoeBar hast du da noch was rausgefunden?


    Ich versuche in den nächsten Tagen mal hier weiterzukommen. Sonst läufts eigentlich ganz gut. Auch mit 2.5.4 jetzt.


    Gruß

    Andreas

    kls Ich glaube hier

    Code
    1. Mai 25 16:57:24 server01 vdr[17147]: [17392] /home/media/records/Verrückt_nach_Meer_(354)/2021-05-25.16.08.1-0.rec: 937589627 errors

    passt noch was nicht. Kommt beim Start einer Aufnahme wohl von hier.


    Gruß

    Andreas

    So ich habe den Fehler nun gefixt. War ein Fehler im openglosd.

    Ich hoffe es hat nun keine Seiteneffekte auf andere Skins.


    mfg

    jojo61

    Wunderbar, danke. Habs in mein sofhddevice-drm übernommen und jetzt klappts. War wohl schon immer falsch in den GL Varianten...

    Code
    1. cBitmap charBm(w, h, 24);
    2. charBm.DrawRectangle(0, 0, w, h, bg);
    3. charBm.DrawText(0, ttSetup.txtVoffset, buf, fg, 0, font);
    4. osd->DrawBitmap(vx, vy, charBm);

    das sich die Ausgabeplugins unterschiedlich verhalten, habe ich an den VDR-Maintainer gemeldet und warte auf die Rückmeldung, wie es eigentlich wirklich sein sollte.

    Ich meine, das ist eigentlich klar.

    charBm.DrawRectangle -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l248

    charBm.DrawText -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l242

    osd->DrawBitmap -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l902


    charBm ist ein neues Bitmap mit entsprechendem Hintergrund und das wird dann mit dem alpha Wert wird ins OSD geblendet. charBm ist an sich richtig.

    Wenn der Bereich aber im OSD jetzt bereits belegt ist, wird über die alten Pixel geblendet. Bei schwarzem Hintergrund fällt das nicht auf.

    Bei mir läuft: vdr-softhddevice-1.1.0 (https://github.com/ua0lnj/vdr-plugin-softhddevice)

    und das kann übrigens auch "cuvid" (ich habe hier Intel VA-API im Einsatz).

    Mit oder ohne GL Unterstützung?

    https://github.com/ua0lnj/vdr-plugin-softhddevice/blob/vdpau%2Bvaapi%2Bcuvid/Makefile#L23

    https://github.com/ua0lnj/vdr-…aapi%2Bcuvid/Makefile#L45


    Ich würde meine Zeilen eher als Workaround sehen, da kann man schon noch optimieren.


    Lese ich es richtig, dass die Zeichen alle mit DrawPixel gezeichnet werden?

    ^ Sry, nein. Mit DrawText.

    sind die Message-Boxen (z.B. Kanalwechsel), die so auftauchen können, vom Hintergrund OK und was passiert, wenn die wieder verschwinden...sind da auch noch alte Textfragmente sichtbar oder ist der Bereich, in dem die Message-Box gezeichnet wurde, nach dem Verschwinden anders wie der Rest?

    Wie kann ich die Message-Boxen denn einblenden? Ich habe es nicht geschafft, außer dem osdteletext was anzeigen zu lassen. Und es ist tatsächlich so, dass jedesmal eine neue Seite mit dem Alpha über alles alte geblendet wird, was dann natürlich im Wirrwarr endet...


    Wenn sich an einer Seite was ändert, wird dann die Seite komplett mit allen Bereichen neu gezeichnet, oder nur die "dreckigen" Bereiche?


    Ich stelle mir das so vor, dass jedesmal, wenn in einen Bereich etwas gezeichnet wird, für diesen Bereich erstmal alles gelöscht wird. Am besten wohl mit ->DrawRectangle in einer Funktion ählich ->CleanDisplay. Falls alles neu gezeichnet wird, würde wohl ein CleanDisplay reichen. Ich meine, so wäre es sauber, da ich nicht glaube, dass eine "Überblendfunktion" im Teletext Sinn macht?!


    Allerdings frage ich mich, warum sich deine Ausgabeplugins da da anders verhalten. Nutzt du das softhddevice mit GL?


    Ohne deinen Code ganz verstanden zu haben, tut es hier und hier möglicherweise auch schon ein

    Code
    1. osd->DrawRectangle(vx + leftFrame, vy + topFrame, w - 1, h - 1, GetColorRGB(ttcTransparent,0));

    EDIT: Wenn das funktionieren sollte, ist es aber sicher nicht die performanteste Lösung :)


    Gruß

    Andreas


    ...dann wäre die Frage, welche OSD-Implementierung denn nach Vorgabe funktioniert bei Drübermalen von Bitmaps mit Alpha-Kanal.

    Die original Software Implementierung von VDR?

    Wenn du mehrere ->DrawBitmap in ein OSD, sprich auf pixmap[0] machst, ohne das OSD dazwischen zu löschen, sollten sich die Draws mit dem jeweiligen Alpha entsprechend überlagern. Das Foto sieht danach aus. Wird das OSD oder die pixmap irgendwann gelöscht, ausser, wenn osdteletext geschlossen wird?

    Korrigiert mich, wenn ich mich irre, aber nur eine Vermutung ins Blaue:

    Die OpenGL Implementierungen rendern auf Pixmaps und kombinieren diese dann in ein OSD. Dieser OSD-Buffer wird vor jedem "zusammenrendern" gelöscht.

    odsteletext nutzt http://git.tvdr.de/?p=vdr.git;…06054bad2a2;hb=HEAD#l2109 und rendert über Umwege auf pixmap[0]. Meiner Meinung muss irgendwer diese pixmap löschen, bevor die Zeichen einer neuen Seite darauf gerendert werden.

    Evtl. verhalten sich da OpenGL und Software Implementierungen anders. Funktioniert es denn bei jemandem mit OpenGL, von welchem softhd* auch immer?

    Gruß

    Andreas

    Kann es sein, dass markad immer nach /usr/bin installiert wird? Selbst übersetzte Programme habe ich lieber in /usr/local.

    Ich habs dann verschoben, aber ich fände es gut, wenn man es mit dem Standard “--prefix“ mitgeben könnte... Oder hab ich was übersehen? Ansonsten klappt das richtig gut!

    Gruß

    Andreas

    Na dann reden wir wohl von 2 verschiedenen Beobachtungen und Problemen.

    CMA ist am Ende schon entscheidend, denn wenn ffmpeg davon für av_frame_alloc nichts mehr bekommt - warum auch immer - krachts. lowmem hin oder her. Ich habe hier eh "nur" 1GB und wenn VDR nach dem Beenden der Wiedergabe wieder alles hergeben würde, was belegt wurde, hätte ich genauso viel wie vor Start der Wiedergabe und wäre glücklich. Aber so ist es halt nicht. Der freie Speicher wird jedesmal weniger.

    Mir reichts für heute, ich denk da morgen wieder drüber nach. Schönen Dank bis hierhin.

    Zu dem Zeitpunkt ist die aktuelle Aufnahme ja nicht geschlossen! Es wird ja eben diese abgespielt. Der Speicher wird von vdr freigegeben wenn die zu schneidende Aufnahme beendet wird.

    Ich glaube, ich habe mich falsch ausgedrückt. Wenn der Speicher ausgeht, während die Aufnahme abgespielt und Marken gesetzt werden, ok... - das Problem habe ich aber hier gar nicht. Es geht mir erstmal nicht darum, dass der Speicher ausgehen kann, wenn man Maken setzt, die Aufnahme pausiert und dann wieder startet.

    Meine Frage ist, warum der freie CMA Speicher VOR Wiedergabe der Aufnahme nicht NACH deren Beenden wieder in der gleichen Größe zur Verfügung steht?
    Das Prozedere "Aufnahme abspielen, Schnittmarke verschieben, Aufnahme beenden, wieder Live-TV ansehen" verringert jedes Mal den CMA Speicher, bis er ausgeht.

    Optimalerweise müsste es doch beispielhaft für den CMA so sein:

    LiveTV: 150MB frei

    Aufnahme abspielen, Pausieren, Schnittmarken verschieben, Schnittmarken anspringen etc....: geht runter bis auf 50MB frei (z.B.)

    Wiedergabe stoppen, LiveTV fortsetzen: wieder 150MB frei


    In Wirklichkeit sind es aber nur mehr 130MB und das nächste Mal 110MB etc...


    Ist meine Theorie, dass ein als CMA allokierter Bereich beim Beenden der Wiedergabe nicht mehr freigegeben wird, denn so abwegig? Es geht mir nicht darum, was während der Wiedergabe mit dem Speicher passiert, sondern dass der CMA nach dem Beenden der Wiedergabe jedesmal schrumpft.

    Genau das wird gebraucht!


    Bei den alten Allwinner SoCs war https://git.kernel.org/pub/scm…t/dts/sun7i-a20.dtsi#n175 notwendig, um den CMA im unteren Speicherbereich zu reservieren, damit die VE damit umgehen kann. Bei den neueren SoCs gibt es diese Einschränkung und somit auch die Reservierung über das dts nicht mehr, da läuft das über die Kernelconfig/-parameter und wird intern durch DMA zur Verfügung gestellt. LE reserviert z.B. 320MB über die Kernelconfig. Nur dem H3 wird als Kernel-Parameter noch "vmalloc=320M" mitgegeben, von dem ich nicht weiß, was es damit auf sich hat.

    Ja :)

    Quote

    CMA wir von vielen Treibern benutzt.

    Klar. Auch bei gcc wird der ganz schnell ganz wenig. Aber das dürfte auf dem Allwinner kein Problem sein, da während der VDR Nutzung auch wirklich nur VDR CMA nutzt. Zumindest niemand anderes im vergleichbarem Umfang.

    Quote

    Ist der Low Mem belegt kann nix mehr eingeblendet werden.

    Warum kann der lowmem so belegt werden, dass kein CMA mehr eingeblendet werden kann, wenn doch 256MB reserviert sind?

    Quote

    Ist der Speicher freigegeben wird er benutzt.

    Welcher Speicher? Generell lowmem oder der für CMA reservierte Teil davon?

    Quote

    Das macht vdr.

    Was macht VDR? CMA belegen und nicht mehr freigeben? Wenn CMA, wo und wie belegt VDR da den Speicher?!

    Quote

    Wird auf Play gedrückt wird auf einmal haufenweise Speicher gebraucht.

    Wäre doch kein Problem, wenn jeder den benutzten Speicher wieder freigegeben hat? Es wird doch auch nicht mehr Speicher angefordert als beim ersten Start des Streams?


    Sorry wenn ich nerve, aber ich wills verstehen.


    Das mit der Reservierung im dts habe ich vor Jahren glaub ich gemacht. Da steht der Speicher wirklich nur der VE zur Verfügung. Aber m.E. muss das anders gelöst werden können.