[reelbox] [eHD] Kernel Modul auf 64-bit portiert + reelbox-plugin funktionsfähig

  • created issue list on related repositories...contributions are welcome

  • As far as I remember, OSD resolution cannot be done more due to small memory on eHD.


    I compiled xinelib and xinemediaplayer plugin, but I absolutely don't remember how to set the priority of the codec in xine, to select the eHD decoders. Now I have sound but no video.


    Also, files trans.c, softDecoder.c, eac3toac3.c are not needed, I once wanted to make a soft decoder eac3.


    May be you called new driver hdshm4, and plugin reelbox-4?

  • As far as I remember, OSD resolution cannot be done more due to small memory on eHD.

    did some calculation: memory should at least be enough for 1280x720 8-bit color: https://github.com/pbiering/vdr-plugin-reelbox/issues/2 if I trust that 720x576 24-bit (TrueColor) is supported (not working on LCARS, no text visible anymore...)

    Also, files trans.c, softDecoder.c, eac3toac3.c are not needed, I once wanted to make a soft decoder eac3.

    files removed from repo

    May be you called new driver hdshm4, and plugin reelbox-4?

    Hmm, so far I bumped the version to 3.1.x in driver and plugin - did not apply too much changes for a major release as mostly only 64-bit and other compatibility issues were fixed.

  • Just note, applied without the

    Code
    return false;

    -> were they introduced by accident?

  • Hi, ich habe bei mir eine eHD (Reserve) rum legen und wollte fragen, ob ihr die eHD auf einem Mainboad, das man einfach kaufen kann, zum Laufen bekommen habt ?!

    Wenn JA, würde ich das als Linux DAU (ohne Bauen u kompilieren) auch hin bekommen ? Welche Distri .... ?

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

  • Vielleicht ist pbrb da andere Meinung, aber die eHD ist schon immer etwas fummelig gewesen. Es gibt heute wirklich keinen Grund die noch in Betrieb zu nehmen. Bei einem "Mainboard das man einfach kaufen kann" ist heute in aller Regel eine Grafikkarte, die der eHD überlegen ist, auch einfach so direkt mit drauf. Also in der CPU die du da drauf setzen wirst.

  • Na ja, nach 1 Jahr intel nuc10i3 und dem software deinterlacing/scaling der softhd* plugins, weiß ich, dass das bei 576i/1080i/720p nicht an die Quali der eHD od z.B. v spezialisierten Broadcom Chips (dream,o.ä.) ran kommt.

    Die Unterschiede sind ab einem 42" Monitor sichtbar ... ganz zu Schweigen von der Wiedergabe am HD Beamer ...

    Bei 1080p ist der Unterschied kaum zu sehen.

    Mit NVIDIA sind die Unterschiede deutlich geringer u bei 1080p quasi nicht vorhanden.... just my 2 Cents ;)

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Einmal editiert, zuletzt von gggggg ()

  • dass das bei 576i/1080i/720p nicht an die Quali der eHD od z.B. v spezialisierten Broadcom Chips (dream,o.ä.) ran kommt.

    Da ich schon Jahre mit Intel ausgebe, muss ich hier mal widersprechen. 720p ist sehr gut, das ist nur eine Frage des Scalings, 1080i nur eine Frage des De-interlacings. Beides jeweils für sich genommen funktioniert astrein mit Intel.


    576i ist "Garbage" mit Intel, kein adäquates Deinterlacing mit hochwertigem Scaling, das stimmt, aber das löse ich einfach damit, das ich eben nur noch HD Material abgreife. Ein Sender der heute noch in 576i sendet ist meine Zeit und Beachtung schlicht nicht mehr wert.


    Für die eHD ist Zeit halt auch irgendwie nicht stehen geblieben, scheinbar ist ja das Problem, das die Karte nach PowerOn sehr lange benötigt bis sie sich am PCI Bus meldet, was wohl im Prinzip alle Schwierigkeiten bereitet. Und naja, man muss einfach sehen alles andere ist irgendwie viel schneller geworden ...


    Ich fand auch Nvidia war über alles schon besser als Intel. Mit deren VDPAU 576i (auf FHD) Ausgabe konnten sich selbst Spezialchips nicht messen. Aber ich vermisse auch nicht die VDR Riesenkisten (mit 200-300W PSUs) im Vergleich zu meinen NUCs, die ich als VDR in Akasa Gehäusen betreibe, ohne aktive Lüfter an einem schmalen 45W Tisch-/Steckernetzteil, dazu kein Geschwurbel mit IR usw. Es überwiegen die HW Vorteile und die Tatsache das HD Ausgabe gut bis sehr gut ist.

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • fnu da ich grad am handy tippe ;) u in deiner Signatur deine Distri,... nicht sehe. Was nutzt du denn ?

    Und ist das soweit ootb, dass ich als nicht make/build/compile oldy das verwenden könnte ;) ?

    An welchen Komponenten (Grafiktreiber, softhd* plugin = scaling/ deinterl.,...) denkst du, liegt deine positivere Erfahrung?

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    3 Mal editiert, zuletzt von gggggg ()

  • Und ist das soweit ootb, dass ich als nicht make/build/compile oldy das verwenden könnte ?

    War mal OOTB aus meinem PPA, ist es aber schon lange nimmer. War zu bequem die letzten Jahre und verwende tatsächlich bis heute eine gepatchte softhddevice Version. Der Patch ist von unseren Freunden aus Finnland und auch die vaapidevice Version, welche auf dem zweiten VDR läuft. Die VDR laufen und tun was sie sollen ... wenn dann irgendwann mal der großflächige UHD Einstieg erfolgt, werde ich wohl dran arbeiten müssen ... 🧐😜🤣 ... aber selbst Ubuntu 18.04 hat noch "ewig Wartung".

    HowTo: APT pinning

  • schade ... wenn wenigstens eines der Auagabeplugins so wie die ehd nativ an den TV zum scaling u deinterl. übergeben könnte ... aber nada ... )-:

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

  • Das wird technisch schwierig bis unmöglich bei GPUs, schon Prinzip-bedingt, da die von Haus aus eben für die grafische Ausgabe auf Benutzeroberflächen (im vordefinierten Rahmen) mittels passender Hardware-Treiber gestaltet sind.


    GPU != Dekoder-Karte, nur weil wir GPUs irgendwie verquer dazu "missbrauchen". Und das ist eine Diskussion, die führen wir hier seit gefühlt 15 Jahren ... 🧐🙄


    Vor 15-18 Jahren gabe es mal den Ansatz der Framebuffer-Ausgabe ohne grafische Oberfläche, konnte auch für VDR genutzt werden, das ist aber auch damals schon wieder schnell eingeschlafen gewesen. Dafür bräuchte es auch quasi Treiber, die es für keinen modernen Grafikchip heute gibt.

    HowTo: APT pinning

  • Vielleicht ist pbrb da andere Meinung, aber die eHD ist schon immer etwas fummelig gewesen. Es gibt heute wirklich keinen Grund die noch in Betrieb zu nehmen. Bei einem "Mainboard das man einfach kaufen kann" ist heute in aller Regel eine Grafikkarte, die der eHD überlegen ist, auch einfach so direkt mit drauf. Also in der CPU die du da drauf setzen wirst.

    Also für einen neuen VDR würde ich auch keine eHD mehr nutzen. Hab meine alte ReelBox aktuell schlafen gelegt und die neue mit einem Intel ITX J3455 am laufen mit Softdevice usw, und würde nicht mehr zurück bauen. Paar Tipps findet man hier: https://github.com/pbiering/ReelBoxNG/wiki


    Ausgabe ist ein 75" Panasonic-TV, bei allem HD-Material super, und alte SD-Aufnahmen müßte ich mal prüfen, dachte, da entsprechend gute Einstellungen gefunden zu haben.


    Was inzwischen auch auffällt, daß die eHD beim Vor- & Rückspulen und Springen immer etwas klemmt (wer in den Code schaut, findet auch den "üblen" Workaround dazu...), mit SoftHDDevice geht das wunderbar...


    Nachteil vom eHD ist auch die Kernel-Modul-Abhängigkeit und daß mir bis heute leider nicht die Buildumgebung zugelaufen ist, um neue Images für eHD zu erzeugen, um da ggf. noch was zu fixen. Hier der letzte Stand an Binaries: https://github.com/pbiering/Re…tree/main/bin-reelvdr/eHD


    Und dann wäre noch das OSD-Problem, was wohl aus technischen Gründen niemals auf HD umbaubar ist...und wer einmal mit Skindesigner gearbeitet hat und die Full-HD-OSD-Auflösung genießt, der will ggf. nicht mehr zurück...


    Zusammenfassung:

    - man kann mit eHD immer noch einen VDR aufbauen, auch mit 64-bit-Kernel (hab ja das Kernel-Modul entsprechend gepatcht)

    - ob man es wirklich will...ich würde davon abraten, außer man hat gute Gründe und tiefe Kenntnisse...es lief unter Fedora 34 soweit stabil auch mit dem passenden justierten Plugin dazu...aber 100% sauber ist der Code immer noch nicht (ReelMultimedia hat da etliche Bugs hinterlassen...)


    BTW: aktuell habe ich kein lauffähiges eHD-Fedora34-Testsystem mehr...der ehemalige Testaufbau ist nun produktiv ohne eHD...die alte Reelbox muß ich erstmal umstellen auf neues OS.

  • Für alle noch existierenden eHD-Nutzer/Leidensgenossen: ich habe ein neues Release erstellt:


    https://github.com/pbiering/vdr-plugin-reelbox/releases


    Und bis auf weiteres werde ich meine Test-ReelBox damit wohl weiterlaufen lassen erstmal...mein Wunschmainboard für's Upgrade ist aktuell "dank" Chipmangel nicht zu bekommen...


    BTW: hätte noch eine eHD-Karte zu verkaufen...hatte mal 3, brauch nur noch eine...

  • Ach und noch etwas ist mir aufgefallen, kann es sein, daß sich VDR inzwischen schwertut mit der Width-Berechnung von Text bei LowRes OSDs (ggf. verursacht durch Rundungsfehler wegen Nutzung von Integer)? Ist mir aufgefallen bei osdteletext-Plugin daß Text nicht mehr in eine Box paßt, beim LCARS Theme passiert das gleiche.


    Wer mal mitsuchen will, kann das ReelBox-Plugin mal mit z.B. folgender Debug-Mask starten:
    --debugmask 0xff6ddfff

    Dann werden rote Linien um die Textbereiche gemalt, wenn der Textbereich durch vorher von VDR berechnete Widths ohne Puffer definiert wird (z.B. in osdteletext), paßt der Text horizontal nicht ganz in die Box hinein...


    Passiert das bei anderen LowRes OSDs (gibt's noch welche?) außer "reelbox" auch?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!