Beiträge von GnaGetier

  • Die Grenzen eines analogen Grabbers - und die digitale Lösung

    Aber er verwendet doch einen digitalen HDMI Grabber, auch wenn wir nicht wissen, was der intern für einen analogen Hokuspokus veranstaltet. Das Rauschen kommt von der Bildverkleinerung.


    Für mich sieht das danach aus, als ob das Bild kurz aussetzten würde und dann die korrekten Bilddaten wieder erkannt/gesetzt würden. Ist irgendwo ein qualitativ minderwertiges HDMI-Kabel im Einsatz?

  • Die Grenzen eines analogen Grabbers - und die digitale Lösung

    Ja, ich glaube ich habe oben nicht ganz klar gemavht, dass ich den Blureffekt mit dem Y&H Grabber nicht aktiviert habe.


    Zwischendurch hatte ich den Effekt getestet, weil ich den leistungsfähigen Prozessor eh verwendet habe und es mit RÜis ja zu problemen kam. Jetzt habe ich aber entschieden beim (teuren) Y&H zu bleiben weil der aufbau so schön einfach ist und es nur ein gerät braucht.

  • Die Grenzen eines analogen Grabbers - und die digitale Lösung

    Hallo nochmals,


    ich habe mittlerweile zwei Filme und einige Folgen einer Serie gestreamt. @Paulchen-Panther's Lösung mit dem Blurreffekt scheint weiterhin einwandfrei zu funktionieren.


    Mit dem Y&H Grabber bin ich soweit auch zufrieden und habe den hohen Preis mittlerweile verdaut. Einer der Filme wurde vom HTPC mittels des internen Platform-Grabbers gestreamt. Wenn man sich selbst im Ambilight-Testmodus befindet fällt einem ein deutlich höheres Delay auf. Wenn man nicht darauf achtet und sich zwingt die Augen auf den Fernseher zu richten stört es jedoch nicht.


    Beim Platform-Grabber X11 ist mir noch etwas komisches aufgefallen. Dafür habe ich einen neuen Thread erstellt, ich denke das passt hier nicht hin. Ich würde mich freuen, falls ihr trotzdem kurz reinschaut.
    https://hyperion-project.org/t…-xorg-unter-ubuntu.10442/


    Viele Grüße

  • Hyperion.ng und Xorg unter Ubuntu

    Hallo zusammen,


    mir ist etwas aufgefallen, von dem ich nicht sicher bin, ob es sich um einen Bug handelt oder ob es an der Arbeitsweise von Hyperion liegt und alles in Ordnung ist.


    Hyperion läuft bei mir auf einem AMD A10-6800K unter Ubuntu 19.10. Die Auflösung des Ubuntu Desktops ist 1920x1080@60Hz. Der Platform-Grabber ist auf X11 mit 30 FPS und einem Bildverkleinerungsfaktor von 2 eingestellt. Wenn Hyperion.ng läuft und der Platform-Grabber aktiviert ist sieht die CPU-Auslastung so aus:




    Wird der Grabber auf 25 FPS und einen Bildverkleinerungsfaktor von 4 umgestellt reduziert sich die benötigte CPU-Zeit von Hyperion und auch Xorg deutlich.




    Komisch ist folgendes. Wird der Platform-Grabber nun deaktiviert sinkt die CPU Zeit von Hyperion erneut drastisch. Die CPU Zeit von Xorg bleibt jedoch quasi identisch. Das gleiche Ergebnis erhält man, wenn man Hyperion im Dashboard deaktiviert. Die CPU-Zeit von Xorg bleibt hoch. (Siehe Screenshot)




    Wenn jetzt aber, mit deaktivierten Platform-Grabber und/oder deakviertem Hyperion die Einstellungen des Platform-Grabbers wieder auf 30 FPS mit Verkleinerungsfaktor 2 geändert wird sieht die CPU-Last so aus:




    Die Last von Xorg erhöht sich ohne das Hyperion oder der Platform-Grabber aktiv wäre. Vor dem Start von Hyperion und nach dem Beenden sieht die Auslastung folgendermaßen aus:




    Das wirklich Störende an der Sache ist nicht die Hohe CPU-Auslastung, es stehen schließlich ausreichend Ressourcen zur Verfügung, sondern, dass alle GUI-Funktionen von Ubuntu anfangen zu ruckeln. D.h. Animationen im Betriebssystem aber auch das GUI von Kodi. Wenn die Grabber FPS auf 10 stehen und ein Verkleinerungsfaktor von 4 gewählt wird fällt es kaum auf, wird mit höheren Werten experimentiert ruckelt alles deutlich. Und das auch bei deaktiviertem Hyperion. Wird Hyperion geschlossen oder vor dessen Start läuft alles butterweich.


    Kennt sich jemand damit aus und kann etwas dazu sagen?


    Danke und Grüße



    edit: Rechtschreibung, Layout


    edit2: Mich würde auch interessieren, ob jemand Xorg nutzt und dieses Verhalten bei seiner Installation nachvollziehen kann.

  • Hyperion NG no colors over USB grabber

    So no saturation settings problem.


    Did you migrate from hyperion to NG on the same pi installation? I'm not an expert but to my understanding the live video should not be affected by hyperion if the image and pixel format is correct. So hyperion.ng should receive the same image feed on the same installation.


    Am I right, anyone?


    Unfortunately I don't know anything else you could look for.


    Regards

  • Umsetzung mit 4K, HDR, ARC und co möglich?

    Hi,


    in anderen Threads wird von guten Erfolgen mit diesem Splitter berichtet (ich selbst besitze ihn nicht und kann daher auch nur über Erfahrungen Dritter berichten):



    Wie der Vorposter bereits erwähnt hat brauchst du natürlich noch Hardware um die Bildinformationen irgendwie an deinen Pi weiterzureichen. Hierfür gibt es den einfachen analogen Weg, über den du sicherlich schon in vielen Threads oder Guides gestoßen bist oder den (teuren) digitalen Weg. Ganz gleich welchen du einschlägst, der oben verlinkte Splitter hat den Vorteil, dass er einen Downscaler besitzt, d.h. 4K Material nicht als solches weiterverarbeitet werden muss.


    Mein Setup sieht im Moment so aus und verzichtet gänzlich auf einen Splitter:


    https://hyperion-project.org/threads/die-grenzen-eines-analogen-grabbers-und-die-digitale-lösung.4438/page-8#post-24462


    HDR ist ein Thema, was zur Zeit noch sehr viele Probleme bereitet. Damit habe ich selbst noch nicht herumprobiert aber du wirst nicht um das Lesen von einigen Threads und dem Ausprobieren einiger Lösungen herumkommen. Mein letzter Stand ist auch, dass es für Dolby Vision noch überhaupt keine vernünftige Lösung gibt oder ich sie bei meinen Recherchen noch nicht gefunden habe.


    Viele Grüße

  • PC Setup for curved monitor (WIP)

    Hey there,


    I just wanted to share my "work in progress" setup for a curved PC monitor.


    The main reason I share is that I was thinking about a lot of different ways of creating a LED bearing frame before I came up with the solution I finally went with. So maybe this provides some valuable input for thos who are thinking about doing the same.


    I didn't want to tape the LEDs just to the back of the monitor. Of course this would have been the most easy way to go as I'm using a 34" curved monitor. Somehow that just didn't feel right and I guess I couldn't have looked at the back of my montitor for too long. (Because thats what they are there for, right? :D)


    So I was thinking about creating a jig for bending a frame or ways to create a frame from a lot of different straight pieces. Finally this is what I came up and went with:




    It worked really well up to this point. The frame consists of

    • 15 mm x 15 mm x 1 mm aluminium square tubes
    • 15 mm x 2 mm aluminium flat sections
    • some 2 mm thick stainless wire and wire clamps
    • self made plastic pieces to screw everything together (no glueing involved)


    Next up is putting on LEDs and start wiring. I'll update this post with the finished setup. But again, my main intention was sharing the frame. Unfortunately my LED strip didn't come with adhesive tape attached. I'm thinking about using a lot of very short strips of heat shrinking tube to affix it to the frame. But the decision is not made yet.


    The LED control is done by an Arduino Uno (clone) as a powerful CPU is already available. It's quite similar to my TV Setup, which is based on a HTPC and an Ardunio as well. The arduino is mounted on some kind of tray inside the PC enclosure.




    A nice feature of the (otherwise pretty expensive) setups using PCs is pwoer for driving the LEDs can be drawn from the 5V rails of the ATX power supply unit.


    Kind regards

  • Die Grenzen eines analogen Grabbers - und die digitale Lösung

    Hallo zusammen,


    ich habe mein Setup wieder in Betrieb genommen. Die Struktur sieht nun folgendermaßen aus (siehe angehängte Skizze):

    • HTPC Content von Lokalen Festplatten

      • Abspielen über HTPC
      • HDMI zu AV Receiver
      • Interner Grabber (Prio niedriger als USB Grabber)
      • Ausgabe per USB über Arduino (adalight)
      • LEDs sind über Molex Stecker ans PC-Netzteil angeschlossen



    • Bluray oder Online Content

      • Abspielen über jeweiliges Gerät
      • HDMI zu digitalem Grabber, anschließend Output zum AV Receiver
      • Bildsignal per USB an den HTPC
      • Ausgabe per USB über Arduino (adalight)
      • LEDs sind über Molex Stecker ans PC-Netzteil angeschlossen



    Ich grabbe also nicht am Ausgang des AV-Receivers sondern je nach Quelle davor über den digitalen USB-Grabber oder den internen Grabber von Hyperion. Es handelt sich ausschließlich um Content bis 1080p, bisher kein 4K, da fähiger TV, AV-Receiver und Abspielgeräte fehlen.


    Ich werde wahrscheinlich vorerst bei diesem Setup bleiben. Die CPU des HTPCs hat ausreichend Rechenleistung um den Blureffekt und alles weitere zu stemmen. Ich habe bisher kein einziges Mal ein Flickern oder andere Probleme erlebt. Zumindest bei 1080p und ohne HDR o.Ä. funktioniert der Grabber ohne Splitter einwandfrei. D.h. es ist neben dem Arduino nur ein einziges Gerät vonnöten, wenn auch relativ teuer.


    Ich fände es daher sehr gut, falls es der Blureffekt in die offizielle Masterbranch schafft. (@Paulchen-Panther) Eventluell eben nur im Expertenmodus sichtbar und mit einem Hinweis versehen, dass die, sicherlich als Standard zu betrachtende, Raspberry-Pi Lösungen nicht genügend Rechenleistung dafür bieten.


    Nächste Woche habe ich ein paar Tage frei, da findet sich sicherlich Zeit für den ein oder anderen Film. Ich werde dann nochmals berichten.


    Viele Grüße



    edit: Transparenten Hintergrund des png enfernt. Anzeigeprobleme.

  • Die Grenzen eines analogen Grabbers - und die digitale Lösung


    Hey,


    mein Grabber ist angekommen und ich wollte heute selbst etwas herumprobieren. Ich habe dazu den box_blur branch geclont und compiliert. Zunächst ist Hyperion beim Aufruf des WebUI immer abgestürzt. Nach mehreren Versuchen hat es funktioniert. Allerdings tritt nach einiger Zeit ein Memory Leak auf. Ich musste ein Foto des Monitors machen weil Screenshots nicht mehr möglich sind. (siehe Anhang)


    Es handelt sich um Ubuntu 19.10, außer TeamViewer ist keine zusätzliche Software installiert. Hardware ist ein AMD A10-6800K ohne dedizierte GPU.


    Ein LED Test steht noch aus, weil ich alles wieder verkabeln muss. das Grabben und Blurren in 1080p funktioniert mit der Leistungsfähigen Hardware natürlich prima.


    Grüße


    edit: Mich würde es nicht stören, falls ich für das funktionierende Setup den ohnehin vorhandenen MiniITX HTPC einschalten müsste und Hyperion einen Arduino füttern würde. Das ist aktuell mein Vorhaben. Die Blurring Funktion scheint bisher sehr gut.

  • Die Grenzen eines analogen Grabbers - und die digitale Lösung

    Mein Grabber ist noch nicht geliefert, kann daher leider im Moment nicht testen.


    Aber Tester scheint es ja ohnehin deutlich mehr zu geben als Programmierer. :D Mich freut, dass Bewegung in der Sache ist.


    Aus den vorhergehenden Posts abgeleitet möchte ich nochmals folgende Frage stellen. Lohnt es sich ggf. Mal zu testen, ob wir uns nicht nur im Kreis drehen. Falls der Blur Effekt so viel CPU-Zeit benötigt, dass die Bildverkleinerung erhöht werden muss und dadurch das Rauschen erst richtig schlimm wird erscheint mir das nicht so zielführend. (siehe Post von TPmodding)


    Gibt es vielleicht eine Möglichkeit das Rauschen der Bildverkleinerung zu reduzieren? Ich habe jetzt nicht in den Code geschaut, weil ich mich noch nicht zurechtfinde, wie das bisher gemacht wird. (@Paulchen-Panther, wo finde ich das?)


    (Ich denke es werden RGB-Mittelwerte einzelner Pixel berechnet. Wäre es möglich, bspw. keinen Mittelwert zu berechnen sondern einfach einen fest definierten Pixel auszuwählen? Bspw. bei der Verkleinerung eines 2 x 2 Pixel feldes immer den oben links. Dann ist die Entscheidung immer eindeutig. Farbverfälschungen erwarte ich kaum, die Pixel haben wahrscheinlich beinahe die selben RGB Werte und falls nicht fallen wenige falsche bei der Auswertung der LED-Zone dann sicher auch nicht ins Gewicht.)

    edit: Ich fürchte das kursiv geschriebene ist Quatsch. Eine Eindeutigkeit müsste ja im Standbild auch bei Mittelwertbildung gegeben sein. Woher kommt das Rauschen im Standbild dann?


    Wie gesagt, mir fehlt im Moment der Grabber um das Flackern von FreshGer nachvollziehen zu können. Bei der stark rauschenden Raspberry Pi Kamera war es definitiv da. Bei meinem alten Setup aus HTPC --> Arduino --> LEDs (Adalight, kein Hyperion) hatte ich egal bei welchem Ausgangsmaterial nie ein Flackern der LEDs, sodass ich nicht sicher bin ob das Quellmaterial wirklich das Problem darstellt.


    Was meint ihr?


    Grüße

  • Die Grenzen eines analogen Grabbers - und die digitale Lösung

    Weil die Kameralösung bisher noch zu viele andere Probleme bereitet und ich eigentlich davon weg möchte. Bzw. schon weg bin und den Testaufbau daher wieder abgebaut hatte. Der größte Charme der Kameralösung besteht aber nach wie vor darin, dass die Contentquelle egal ist und somit 8K, HDR sowie geräteinterne Wiedergabeapps funktionieren.

  • Hyperion mit 4k Grabber

    Hallo,


    bei diversen Tests gestern und heute habe ich festgestellt, dass auf einem RPi3 die CPU Last sehr merkwürdig ausfällt. Direkt nach dem Booten kann diese für hyperiond alle möglichen Werte zwischen 50% und 2xx% betragen. Klickt man etwas in der Konfig herum, ändert sich das manchmal, manchmal bleibt es für eine Stunde auf dem ursprünglichen Niveau.


    Es ist nicht so, dass die Konfig unmittelbaren Einfluss hätte. Manchmal steigt die CPU-Zeit bei Deaktivierung von Hyperion sogar auf mehr als das Doppelte an. Ein Muster ist für mich nicht erkennbar.


    Hast du hierzu noch Beobachtungen machen können? Ggf. liegt irgendwo ein Bug vor.



    edit:
    Die hohe CPU-Auslastung kann ich jetzt auf mehrere LED-Instanzen zurückführen. Ich hatte zu Testzwecken mehrere erstellt. Wenn ich alle außer eine entferne liegt die Grundauslastung beim RPi3B (kein B+) bei folgenden Werten:


    • Hyperion im Webinterface deaktiviert: ~35 - 40 %
    • Hyperion im Webinterface aktiviert, 720p Quelle, Verkleinerungsfaktor 4: ~60 - 67 %
    • Hyperion im Webinterface aktiviert, 720p Quelle, Verkleinerungsfaktor 3: ~70 - 76 %


    Das sieht jetzt dann doch wieder ganz konsistent aus. Die Bildverarbeitungsoptionen, Schwarze-Balken-Erkennung o.Ä. scheinen keinen nennenswerten Einfluss zu haben.