Beiträge von jochenf

    einfach mal Danke sagen. ;)


    Ja, auch von mir an dieser Stelle einen herzlichen Dank für euer Engagement und den Support, den ihr im Board leistet.


    Das mit einer Hand voll aktiven Entwicklern, bei 187 Forks, war mir gar nicht bewusst.


    Grüße
    Micha

    Hallo


    und auch von mir Danke für die Aufklärung. Da ich nicht jeden Thread mitverfolge, ist das irgendwie an mir vorbeigegangen.


    Zitat

    Ich fande der Thematik wurde hier viel zu wenig Beachtung geschenkt und irgendwie schienen nur wenige Leute ein Problem mit HDR und verwaschenen Farben haben...


    Ja finde ich auch, wenn man bedenkt, dass manch einer hunderte Euro in einen HdFury Diva oder die Kombination Vertex/Integral + X4 investiert hat, um das HDR Problem in den Griff zu bekommen.


    Ich persönlich kann mit dem v4l2-ctl Workaround und meinen Digitalgrabber zwar leben, das komplette Kostrukt aus Raspi, Splitter, Grabber, iobroker und Alexa für die HDR Umschaltung kommt Doc Brown's Eismaschine aus Zurück in die Zukunft III schon recht nah. ;)


    Grüße
    Micha

    Hallo,


    in einigen Beiträgen lese ich immer wieder mal was von HyperHDR.


    Warum wird sowas eigentlich parallel entwickelt und der pfiffige Entwickler nicht einfach mit ins Boot geholt? ;) Oder habe ich da im Board oder auf GitHub vielleicht irgendeine Diskussion verpassst, die die Umstände erklärt.


    Grüße
    Micha

    Hi,


    wenn ich Hyperbian lese, vermute ich, du nutzt das klassiche Hyperion. (boah, miese falsche infos) Dies habe ich mit dem neuen Grabber nie probiert. HyperionNg läuft bei mir noch in einer älteren 2.0.0-alpha.6 Version auf einen Raspbian Buster 10. Den Grabber habe ich am 4er Raspi an einem USB3 Port hängen, an einem 2er USB Port sind mir auch allerdings auch keine Probleme mehr in Erinnerung.
    Bezüglich deines Fehlers mit v4l2-ctl vermute ich, dass dies unabhängig von der Hyperion Version sein sollte. Ich würde also ein Problem in Zusammenhang mit dem USB Port vermuten.Gab es da beim Raspi nicht einen Eintrag in der config.txt, welche den maximalen Strom für den USB Port regelt? Vielleicht auch einfach mal einen aktiven USB Hub zwischenhängen.


    Grüße
    Micha

    Hi,


    Zitat

    Ich denke hier wird es keinen Unterschied machen, ob diese angepasst, oder deaktiviert ist.


    Klar sollte es das, begrenzt den maximalen Strom den die LED's bekommen und damit auch deren Helligkeit.


    Grüße


    Micha

    Hi,


    das Problem hatte ich mit dem USB/HDMI Stick aus dem anderen Thread auch, da war einfach 255 nicht genug. Glücklicherweise läuft mein anderer HDMI Grabber mit 255 bei HDR optimal.


    Daher die Frage , gibt es irgendwie eine Möglichkeit die Farbsättigung noch weiter zu steigern?


    Wenn ich folgenden Thread so beobachte, stehen die Chancen recht gut, dass das Ganze bald mit in Hyperion integriert wird.


    https://hyperion-project.org/t…media-center.10652/unread


    Grüße


    Micha

    Hi,


    müsste doch eigentlich mit einer zweiten Instanz funktionieren. Kannst diese ja identisch zur ersten konfigurieren. Über hyperion-remote müsste du diese per Shell dann starten und stoppen können. Kann das Ganze gerade selbst aber nicht verifizieren, da ich meine SD Karte für was anderes missbraucht habe. Müsste da erst das Image wieder draufschieben. ;)


    Grüße


    Micha

    Ja,


    eigentlich für nen 10er damit das optimale Gerät, die HDR Zielgruppe ist bestimmt eh recht gering.


    Wenn sich die Sättigung in Hyperion (hyperion-remote), abseits von v4l2 beinflussen ließe, wäre das natürlich optimal.


    Das mit der automatischen HDR Umschaltung hatte ich auch mal auf dem Plan, war der Hoffnung mit NodeRed meinem LG TV, Oppo oder Yamaha abzufragen, ob HDR aktiv ist oder nicht.
    Die Dreambox 7 klingt auf alle Fälle recht intressant, werde ich auf alle Fälle im Auge behalten. Obwohl, wenn ich an frühere Ankündigungen von Dream und der letzendlichen Lieferbarkeit denke, wirds wohl nicht vor 2022. ;)


    Grüße


    Micha

    Hi,


    mein "alter" Graber meldet sich als "Device 005: ID 1bcf:2c99 Sunplus Innovation Technology Inc.".


    Bezüglich der Latenz und gefühlten Trägheit habe ich mal noch einige Tests gefahren und muss meine Aussage bezüglich der sehr hohen Latenz etwas revidieren. Das Ganze ist nach meinen erneuten Tests extrem abhängig von gewählter Auflösung/Format in Zusammenhang mit der CPU-Auslastung der Raspis. Das heißt, läuft mein alter Grabber z.B. bei 1280*720/30p/8 YUYV bei 85% CPU Last, ist die gefühlte Latenz minimal. Der neue Grabber mit identischer Einstellung aber MJPG läuft bei etwa 75% CPU Last, die gefühlte Latenz bei vielleicht trägen 0,5s. Gehe ich bei beiden auf 720(640)x480/30p/4 was auch den neuen Grabber in den YUYV Modus zwingt, liegen beide bei etwa 85%, nehmen sich bezüglich der Latenz (20ms) allerdings nichts mehr. Da ich bei meinem Raspi im Vergleich zu euch generell bei auffällig hoher CPU Last liege, erklärt dies vielleicht meine falsche Einschätzung bezüglich der Latenz.


    Da ich dies nicht so einfach auf sich beruhen lassen wollte, habe ich mir mal Testscenrario bezüglich "Latenz-Messung" ausgedacht. ;)


    Da bei mir alle Geräte über den AV Reciver am USB Grabber anliegen, kam mir die Idee, einfach die Windows Stoppuhr für die Messung zu verwenden. Ich führe das Signal meines PC also dem USB Grabber zu. Dazu habe ich auf der rechten Bildschirmseite das Hyperion Vorschaufenster aufgemacht und links die Windows Stopuhr laufen lassen. Dies dann mit dem Handy fotografiert. Mir ist natürlich klar das, noch eine unberechenbare Verzögerung durch Webinterface reinspielt, die ermittelten Werte sind auf alle Fälle wenigstens schon mal ein Anhaltspunkt. Unter oben erwähnten Auflösung 720x480 (old.jpg, new.jpg) liegen beide Grabber danach bei unter 20ms. Die 1280er Messung am neuen Grabber (neu1280.JPG) allerdings bei 75ms. Zusätzlich habe ich festgestellt, dass der Bildverkleinerungsfaktor und die damit einhergehende CPU Auslastung die Latenz anscheinend nur gering beeinflussen. Der Unterschied zwischen Faktor 1 und 180% CPU und Faktor 8 bei 75% CPU am neuen Grabber ist bezüglich der gemessenen Latenz minimal.


    https://drive.google.com/drive…-a1iZK3quI-Au?usp=sharing


    Grüße


    Micha

    Hi,


    Zitat

    Funktioniert bei mir gut, sogar ohne Konfiguration an der Kommandozeile. Mit folgenden Parametern in Hyperion NG läuft er in (meinem Empfinden nach) Echtzeit mit dem Bild mit (auf einem Raspberry Pi 4, die CPU Last liegt bei um die 20%). Ich sehe zumindest keinen Unterschied zu der üblichen analogen Kombi.


    Hast du die Verzögerung mal im Vorschaufenster von hyperion.ng beobachtet? Kann man recht gut bewerten, wenn man im OSD vom BluRay Player, Mediaplayer oder was auch immer bissel rumscrollt. Von Echtzeit ist das Ganze bei mir leider weit entfernt. Bei der CPU Last liege ich auf Grund der bei mir 2 Instanzen auf dem Raspi 4 eh immer etwas drüber.


    @pclin


    Auf deine CPU Auslastung bin ich eh etwas neidig. ;) Schade, dass ich den Odroid N2 wieder verkauft habe, hätte man mal gegenchecken können, ob es die CPU oder doch eher Enigma bringt. Wenn die "one" und deren Fernbedienung nicht so hässlich wären, hätte ich meinen Solo4k sicherlich schon damit ersetzt. ;)


    Grüße


    Micha

    Hi,



    gestartet bin ich mit 1280x720/8, da hatte ich um die 60% CPU, mit /4 um die 85%. Mein "alter" lag bei Verkleinerung von 8 bei über 80% CPU Last, bei /4 dann über 100%. Habe dann mal mit 720x576 und 640x480 und 2er Bildverkleinerung getestet, dabei aber auch keine Wunder erlebt. Ich würde vermuten, dass die CPU-Last hauptsächlich von der Auflösung abhängt, die Hyperion letztendlich verarbeiten muss. Ob ich 1280x720/4 oder 640x480/2 zuspiele, kommt bei der CPU Last aufs gleiche raus. Ich hatte ja die Hoffnung, dass mit MJPEG die CPU Auslastung deutlich sinkt. Da mein Raspi aber eh nichts anderes zu tun hat und ich diesen nur anschalte, wenn Hyperion läuft, kann ich mit 80% CPU eigentlich leben.


    Bezüglich des Lags war ich wirklich enttäuscht, konnte dies gut im Vorschaufenster von hyperion.ng am OSD meines BluRay Players beobachten. Der alte Grabber liegt da geschätzt im zweistelligen Milisekundenbereich.


    Bezüglich HDR bin vielleicht auch von meinem alten etwas verwöhnt, da bekomme ich mit contrast=220, hue=16 und saturation=255 zu 95% ans HDR Bild meines TV's ran. Beim neuen fehlt dann halt etwas, nen blauer Himmel ist mir dann trotz Regler am Anschlag einfach zu blass. Gerade in Verbindung mit der Blauschwäche meiner SK6813 wirds mir dann zu fad.


    Grüße


    Micha

    Hallo,


    da mein Grabber nun endlich auch angekommen ist, mal zu den sehr ausführlichen Infos von pclin mal noch einige Anmerkungen von mir.


    Im Vergleich zu meinem oben genannten Graber, deutlich spürbares Input Lag, geschätzt über 0,5s. Die CPU Auslastung YUYV zu MJPEG ist nur etwa 20% geringer, hätte ich mehr erwartet. Ob ich am Ende mit Bildverkleinerung 4, 6 oder 8 fahre macht bei 45 LED's horizontal eh keinen Unterschied. Bezüglich HDR scheidet der Grabber bei mir dann leider aus. ;( Da die Farbsättigung per default schon auf 180 steht, bleibt leider nicht mehr genügend Headroom um das entsättigte HDR Bild entsprechend nachzubearbeiten, am Ergebniss meines alten Grabbers fehlen bei 255 noch etwa 30%.


    Daher von mir leider keine Empfehlung, von meinen persönlichen HDR Belangen mal abgesehen, sind 0,5 Sekunden Verzögerung einfach zu viel.


    Grüße


    Micha


    ps: wäre für nur 10€ einfach zu schön gewesen

    Hi,


    soviel Arbeit hab ich mir nicht gemacht, ist aber schon cool, was damit alles geht. ;)


    Warum steuerst du die Effekte über Hyperion, kann WLED doch viel besser. Ich schalte per "http://192.168.0.216/win&RD=1&A=255" bei WLED UDP den UDP Empfang aus und steuere die Faben dann mit dem WLED Alexa Device. Die Animationen rufe ich dann über http Request mit WLED auf, oder spreche das iobroker WLED Device direkt an. Für NodeRed gibt es auch ein natives WLED Plugin.


    Grüße


    Micha

    Hallo,


    ja, schwarze Balken Erkennung funktioniert so weit. Habe dies gerade mit Kodi und VLC getestet. Ich nehme natürlich das neue hyperion.ng. ;) Meine derzeitige Konfiguration ließe sich ohne die Möglichkeit, mehrere Instanzen mit verschiedenen LED Anordnungen parallel laufen zu lassen, nicht mit dem "Alten" realisieren. Ich habe damit die Möglichkeit, die 135 LED's am TV und die 72 am Monitor gleichzeitig unterschiedlich zu befeuern. Dank der Prioritäten, die sich in .ng und auch am "Hyperion Screen Capture" (HPSC) definieren lassen, bekommen die TV LED's das Livebild vom USB Grabber und parallel die am Monitor das Bild vom PC. Übers Web Interface oder bei mir Dank iobroker und Alexa kann ich die Quellen auch wild untereinander wechseln wenn ich z.B. mal am TV zocken will.


    Grüße


    Micha

    Hi Foradh,


    da du ja von der Rapsi + "Hyperion Screen Capture" Geschichte als Alternative gesprochen hast, mal eine kurze Rückmeldung dazu.


    Ich habe bei mir Hyperion auf dem Raspi 4 laufen, 2 ESP 8266 per UDP dran und steuere diese 2 Instanzen 1x über den USB Grabber direkt am Raspi und die zweite mit "Hyperion Screen Capture" vom PC. Obwohl der Windows Grabber schon 2-3 Jahre auf dem Buckel hat, funktioniert das Ganze eigentlich einwandfrei. Wenn du nen Raspi vielleicht noch irgendwo rumliegen hast für mich der vielleicht bessere Weg.


    Grüße


    Micha

    Hi,


    da du eh hyperion auf dem Raspi laufen hast und die LED's kabellos mit WLED ansteuerst, ist eigentlich "Hyperion Screen Capture" ideal. Auf dem Raspi erzeugst du einfach ne zweite Instanz, die nur die LED's am PC dranhängend hat. "Hyperion Screen Capture" verbindest du dann per UDP 19445 Forwarder mit dem Raspi. Die Priorität kannst du HSC dann mitgeben.


    https://sabaatworld.github.io/HyperionScreenCap/


    Grüße


    Micha