Hyperion mit 4k Grabber

  • Hängt mit dem Delay des Displays zusammen, wenn der auch einen entsprechend höheren Delay hat, gleicht sich das gegenseitig aus. Daher befürchte ich, dass bei mir mit einem Monitor statt einem TV der Delay zwischen Ambilight und Bild deutlicher zu sehen ist. Monitore sind normal schneller, haben einen geringeren Input Delay, vor allem Monitore mit schnellen Panels wie TN Panels (hat mein 4K Monitor noch).

  • Hi,


    mal ein kleines Update zu meinem Orange Pi RK3399 Projekt und dem Versuch, das Ganze ohne externen Grabber zu betreiben.


    Das Board wurde glücklicherweise doch schneller geliefert als gedacht. Ich hatte über den Jahreswechsel also bissel Zeit zum Spielen. Leider nur mit mäßigen Erfolg. Für den RK3399 gibt es ein Debian 9 Image, welches den HDMI Input unterstützt. Ich konnte hyperion.ng dafür erfolgreich kompilieren und meine LED's per UDP damit ansteuern. Im ursprünglich angedachten Armbian wird der HDMI Input leider nicht unterstützt. Sobald ich im Webinterface jedoch das interne Video0 Device ausgewählt habe, verabschiedete sich hyperion mit einem Laufzeitfehler. Nach etwas Recherche stellte sich der nur halbherzig implementierte v4l2 Treiber als Ursache heraus. Obwohl ich den Eingang per ffmpeg als Capture Quelle nutzen konnte, liefert der Treiber anscheinend keine korrekte Auflösung und Framerate an v4l2 zurück. Daran verschluckt sich hyperion.ng vermutlich. Das größere Problem, bzw. mein persönliches NoGo ist allerdings, dass sich per v4l2-ctl leider weder Sättigung noch Kontrast anpassen lassen. Der angedachte HDR Workaround scheidet also aus. Versuche ich Farbraum, Auflösung oder Framerate per v4l2-ctl manuell zu setzen, nimmt es video0 nur in 1/10 Fällen überhaupt an oder setzt diese nach wenigen Sekunden selbstständig auf die ursprünglichen Werte zurück.


    Deshalb also leider die Moral von der Geschicht, ohne passende Treiber nützt dir auch die beste Hardware leider nichts.


    Aufgeben werde ich mein Ansinnen aber nicht und den "Markt" im Auge behalten. Mal schauen, was die Zukunft so bringt.


    https://www.cnx-software.com/2…ox-supports-av1-decoding/


    http://www.banana-pi.org/w2.html


    Grüße


    Micha

  • Hi,


    kleines Update von mir. Der Grabber ist heute angekommen und leider durch sämtliche Tests gnadenlos durchgerasselt. ;(


    Das Gerät wird weder von Debian, Raspbian noch OSMC korrekt erkannt. Ein Video0 Device ist nicht existent. Unter W10 wird die Box als USB Display erkannt. Also falsche Amazon Artikelbeschreibung und daher was für den Sondermüll.


    Gut dann wirds also der Y&H. Leider musste ich mit Entsetzen feststellen, dass dieser aktuell nicht über Amazon direkt lieferbar ist und aus China verschickt wird. Es musste also kurzfristig ne Alternative her. Also, getreu der Devise "wer billig kauft, kauft 2x" und dem Motto "Versuch macht klug" werde ich folgender Box mal eine Chance geben.


    https://www.amazon.de/gp/produ…tle_o00_s00?ie=UTF8&psc=1


    Grüße


    Micha

  • Hi,


    folgend ein kleiner Erfahrungsbericht und ein Hilfegesuch bezüglich meines neuen Grabbers.


    Der Grabber wird von v4l2 korrekt erkannt und von hyperion.ng unterstützt. Als Pixelformat wird leider nur YUYV untertützt. Auf Grund der entstehenden Datenmenge habe ich auf dem 4er Raspi jedoch eine CPU Auslastung von etwa 300%. Trotz dessen beträgt die geschätzte Latenz nur etwa 100ms. Stelle ich den Bildverkleinerungsfaktor auf 16, sinkt die Auslastung auf 95%. Bei der Latenz habe ich keinen Unterschied bemerkt. Abgesehen von der zu hohen CPU Last wäre ich mit dem Ergebnis eigentlich zu frieden. Bezüglich blassen HDR Farben bekomme ich mit "v4l2-ctl --set-ctrl saturation=255" ein wunderschön buntes Bild ohne Farbverfälschung die mir mein analoger Grabber produziert hat.



    Nun zu meinen Hilfegesuch. ;) Wie esprit1711 ja schon geschrieben hat, ignoriert hyperion die per "--set-fmt-video" gesetzte Auflösung leider. Es wird von hyperion also ein Bild mit maximaler Auflösung gegrabbt. Welches bei meinen Graber, der ja leider kein mjpeg kann, sicherlich um die 4MB ist. Die hohe CPU Last rührt vermutlich daher. Die nachträgliche Bildverkleinerung in hyperion bringt daher nur eine geringe Performance Verbesserung.
    Mein Wunsch die Grabber Auflösung schon vor der Eigentlichen Bildverarbeitung durch hyperion zu reduzieren, scheitert leider an meinen nicht vorhanden Programmierskills. An der Anpassung, der Auflösung in der "hyperion-v4l2.cpp" hänge ich gerade fest.


    Ergänzung 26.01 14:00:


    Um den weiteren Threat nicht durcheinanderzubringen mal ne kleine Ergänzung. Der Grabber läuft aktuell einwandfrei. CPU Last bei 1280x720/4 etwas 60%. Delay geschätzt bei 100-200ms zur Live Vorschau in Hyperion.Von mir also :thumbup: für das Gerät und :geek: für die gesparten 50€ gegenüber dem Y&H.


    Grüße und vielen Dank


    Micha

  • Hi,


    der User SputnikElf hat in einem anderen Thread, in welchem versucht wird mit Videokameras zu grabben, eine angepasste Version der V4L2Grabber.cpp gepostet. Ich habe diese aus seinem git geclont und selbst ausprobiert. Zumindest in der Kameraanwendung funktioniert es. Aber das dürfte ja keinen Unterschied machen, vielleicht hilft dir das zum Start aus?


    https://github.com/SputnikElf/hyperion.ng
    Es existieren Pullrequests dazu, ob es alles so ins offizielle Hyperion Projekt schafft und wann kann ich dir natürlich nicht sagen.


    Wichtig ist, dass die v4l2 Settings beim Neustart passend zu den eingegebenen Werten im Hyperion.ng Interface gesetzt werden. Siehe dazu folgenden Post. Der Thread ist gegen Ende jedoch insgesamt interessant.


    https://hyperion-project.org/t…ber.837/page-4#post-17671


    Viele Grüße

  • Cool,


    Danke, schaue ich mir gleich mal an.


    Was ich gerade bemerkt habe, dass Hyperion auf dem 4er Raspi auch 90% CPU Last zieht, obwohl der Grabber momentan garnicht dran hängt. Bin außerdem gerade dabei, den Graber mal an meiner Vero4k zu testen, mal schauen was dabei rauskommt.


    Danke


    Micha

  • Bevor ich mir wieder selbst antworte, habe ich diesen Beitrag mal lieber editiert.


    Hyperion läuft bei mir unter Raspbian, die Plattformaufnahme ist nicht aktiv.


    Zum Verständnis, um nicht 2 Sachen durcheinander zubringen.


    Bei meinen Tests weiter oben habe ich noch nicht gewusst, dass der Raspi auch ohne angeschlossen Graber bei "top" schon bei über 90% Auslastung liegt. Bei meinen Experimente mit dem neuen Grabber und Bildverkleinerungsfaktor von 16 komme ich dann auf ca. 98% CPU Last. Mir war also noch nicht bewusst, dass der Grabber eigentlich nur 8% Last zieht.


    GnaGetier empfahl mir bezüglich der weiter oben angesprochenen Probleme, mal den Git von Sputnik zu testen, welcher die Grabber Auflösung auf 1280x720 setzt.


    Ich habe den Git von Sputnik daher mal für den raspi und die vero neu kompiliert. Doch auch dieser lastet den raspi 4 schon zu 90% aus, obwohl noch gar kein USB Grabber angeschlossen ist. Die Last mit Grabber liegt wieder bei über 95%. Im Vergleich zu meiner hyperion Version kann ich nun mit dem Bildverkleinerungsfaktor jedoch auf 4 runtergehen, die 1280x720 bringen also grob 3%.


    Auf der Vero 4k zeigt sich das selbe Bild, hyperion liegt ohne USB Grabber schon bei über 90% CPU Last. Als Ursache der hohen CPU Last habe ich meine Hyperion Config ausgemacht. Starte ich mit einer leeren, liegt die Last im Leerlauf auf beiden Systemen bei um die 10%.


    ---------------------------------------------------------------------------


    Nach Bereinigung meiner Config habe ich nun im Idle (Raspbian, nur Hyperion) ca. 50% CPU Last. Nehme ich die Version von Sputnik und Stelle 640x480 als Auflösung und Verkleinerung 4 ein, liege ich bei rund 65% Last. Damit kann ich sehr gut leben. Nach meinen Beobachtungen liegt die generell recht hohe CPU Last bei mir eventuell an der LED Ansteuerung per udpraw.


    Bezüglich HDR haben sich folgende Anpassungen als ideal erwiesen.


    v4l2-ctl --set-ctrl saturation=255
    v4l2-ctl --set-ctrl contrast=220
    v4l2-ctl --set-ctrl hue=16


    Als Resümee des Ganzen würde ich sagen, dass ich bei halben Preis gegenüber dem Y&H sehr zufrieden bin und das Setup bis zum Erscheinen einer all in one Lösung mit HDMI Input so fahren werde.


    Grüße
    Micha

  • 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.

  • Hi,


    ja, habe auch 2 Instanzen laufen, eine mit 74 LED's und eine mit 256 LED's beide Streifen hängen an je einem ESP8266 und werden per udp raw angesprochen. Das mit der Last bei mehreren Instanzen könnte hinkommen. Die Last von über 50% stellte sich bei mir erst ein, als beide wieder aktiv waren.
    Werde das dann noch mal checken und mit nur einer Instanz beobachten.


    Edit 13:45


    irgendwie stehe ich gerade etwas auf dem Schlauch. Hyperion zieht nunmehr nur noch 35% CPU mit 2 Instanzen, also Livebild vom PC per "Hyperion Screen Capture" an den Monitor plus USB Grabber 640x480/4 auf den TV. Die einzige Änderung die ich gestern gemacht habe, war den hyperion.service aus dem Autostart rauszunehmen und diesen nur bei Bedarf per Alexa zu starten.
    Selbst mit 1080/4 Bild komme ich jetzt nur noch auf 75% CPU Last.


    Grüße


    Micha

  • ich habe den in meinem ersten Beitrag weiter oben verlinkt:
    https://www.amazon.com/gp/prod…sc=1&tag=hyperionpro05-20



    Ich muss morgen nochmal gucken wie man mit hyperion Screenshots machen konnte. dann vergleiche ich nochmal die soll Farben (HDR aus bei Grabber Standard Settings) mit den Farben bei aktiviertem HDR. Das ist aktuell alles Augenmaß^^"


    hi leute, :) @esprit1711 wenn ich den Splitter bestellen möchte, redirected mich das Deutsche Amazon auf die lite version vom verlinkten Splitter.
    gofanco Prophecy Splitter USB Compact Anschlüssen
    funktioniert der genauso gut oder habe ich nachteile?


    10bit & 12bit hdr sollten afaik damit ja funktionieren und die ganzen cec geschichten auch. am schönsten wär ’n passthrough. hab mir vor einigen monaten extra die große version vom denon gekauft mit 3 hdmi outputs, war nur für 1080p auch voll ok. jetzt hoffe ich das deine lösung @esprit1711 bei mir auch gut funktionieren wird. das ganze wird mit dem rpi3, lg 65" oled 2019, denon avrx3500h, ps4 pro und nvidia shield 2019, 136 WS2801 leds arduino mirco adalight getested :)

  • hallo @sophie,
    warum möchtest du genau den?


    Hat dipswitches um das verhalten zu kontrollieren, wurde hier im Forum bereits getestet und soll alle gängigen HDR formate laut Amazon durchreichen. Möchte jetzt ungern splitter durchtesten, sondern direkt einen kaufen der auf jeden fall funktioniert.


    edit:
    Wenn ihr eine andere Möglichkeit kennt, den integrierten splitter von unserem Denon AV-Receiver auf HDMI output 2 nen falschen EDID vorzugaukeln, so das die PS4 Pro und Nvidia Shield beide hdr erkennen, würde ich auch einen anderen Splitter kaufen/anderes Gerät kaufen. Die Idee in moment ist es den Splitter zu kaufen und dann vor dem Denon zu hängen, das erhöht natürlich die Latenz, ist etwas schade.

  • ich habe jetzt die Produktseite von meinem Splitter (PRO-HDRsplit2P) und den, welchen dir Amazon vorschläg (PRO-HDRsplit2P-LT) verglichen.
    Bis auf die großzügigeren Möglichkeiten bei der EDID Konfiguration sind alle angaben absolut gleich. Da es vom selben Hersteller kommt, wird auch grundsätzlich die selbe Technik verbaut sein.
    Ich habe bei meinem Splitter den zweiten Dip Schalter auf ON gestellt, damit dieser der PS4 Pro sagt, dass mein TV nicht 7.1 Sound, sondern 2.1 Sound beherrscht (ist echt irritieren, wenn im Film der komplette Ton da ist, bis auf die Stimmen :D ). Vielleicht muss ich nochmal schauen ob ich etwas an meinem Fernseher falsch eingestellt habe, da hat aber die automatische Erkennung versagt. ist aber nicht so schlimm, da es ja mit dem kleinen Workaround läuft und der Splitter auch sonst seine Arbeit perfekt macht.


    Mit anderen Splittern habe ich leider keine Erfahrung, bin mir aber sicher, dass es auch von anderen Herstellern brauchbare Lösungen gibt.


    Ich war bisschen verwundert, dass dich Amazon auf den anderen Splitter verweist, habe also mal den Grabber in den Warenkorb gepackt und mich eingeloggt. tatsächlich bekomme ich dann die Meldung, dass es nicht an meine Adresse geschickt werden kann. schade, habe es damals über die amazon.com Seite bestellt

Jetzt mitmachen!

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