Posts by jochenf

    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,


    Quote

    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

    Hi,


    so ganz habe ich deine Geschichte zwar nicht verstanden, vielleicht trotzdem mal meine Konfiguration, die vielleicht auch bei dir passen könnte.


    Ich habe einen Raspi 4, an diesem ein HDMI USB Grabber, welcher das Bild vom HDMI Ausgang des Recivers bekommt. Auf dem Raspi gibt es zwei Hyperion Instanzen, 1x 256 LED's am TV und 1x128 LED's am PC Monitor. Auf dem PC Windows läuft der "Hyperion Screengrabber" in der Taskleiste. Dieser greift auf das Hyperion am Raspi per UDP Forwarder Port 19445 zu. Auf dem raspi habe ich die Prioritäten der beiden Instanzen so angepasst, dass der USB Grabber für die TV Instanz eine höhere Priorität als Screengrabber am PC bekommen hat. Wenn der Grabber am PC also läuft, bekommt der TV weiterhin das Signal vom USB Grabber. Die zweite "Monitor" Instanz ist so konfiguriert, dass der PC Grabber eine höhere Priorität als der USB Grabber bekommen hat. Die Monitor Instanz schaltet also auf PC um, die TV Instanz läuft weiterhin per USB Grabber. Stoppe ich das Programm auf dem PC, wechselt auch die Monitor Instanz wieder auf den USB Grabber oder geht komplett aus.
    Da ich auf einem anderen Raspi iobroker am laufen habe, kann ich mittels Shell Script und hyperion-remote, wild zwischen den Szenarien wechseln. Also zwischen USB->Monitor, PC->TV oder PC->Monitor einfach per Alexa wechseln.


    Grüße


    Micha

    Hi,


    Quote

    https://de.aliexpress.com/item/4000200256432.html - 1080p 25/30/50/60FPS - Passthrough - USB 3.0 Typ C - ca. 40€ - getestet von jochenf (Frage noch an dich: 8,10 oder 12 bit Fähig?)


    Ja, 10/12 Bit HDR geht, richtig gesätigte HDR Farben nach Anpassung

    Code
    v4l2-ctl --set-ctrl saturation=255

    . Grabber kann nur YUYV, kein MJPEG, daher etwas erhöhte CPU Last. Mit Bildverkleinerung 8x auf dem Raspi 4 aber alles im grünen Bereich. Input-Lag nicht spürbar, wird wohl unter 100ms liegen.


    Quote

    Der hier sieht anhand von Beschreibung und Preis sehr gut (kein 4k) aus https://de.aliexpress.com/item/4000917130635.html


    Der ist ja niedlich, habe ihn mir kurzer Hand mal zum Testen bestellt. 10€ hatte ich gerade noch in der Portokasse drin. Scheint von der Größe zu klein zu sein, um ne Kombination aus D/A Wandler und analog Grabber zu beherbergen. Mal schauen, ob 1080p60 wenigsten entgegennehmen kann, capturen kann er meinetwegen ja ruhig mit 30fps.


    Grüße und ein Lob für den Thread


    Micha

    Hi,


    war dann leider doch nichts. ;( Mit dem LG C8 LLDV Profil kommt der E6 (kann eh nur bis 4k30 DV) leider nicht klar. Apple TV erkennt das DV geht und ich kann manuell z.B. 4k24 DV auswählen, mein TV erkennt dann aber kein HDR, geschweige denn DV mehr. Zeigt aber trotzdem das selbe entsättigte Bild, was der Grabber bekommt.


    Naja, einen Versuch war es wert.


    Grüße und Danke für den Denkanstoß.


    Micha

    Hi,


    Danke für die schnelle Rückmeldung. Das 8 - Custom Profil scheint bei mir was ganz anderes zu sein, da beschwert sich die "Forrest Gump" BluRay, dass ich mir einen 4k Fernseher kaufen soll, kein Witz. ;)


    Wäre es möglich, dass du mir die EDID von deinem Profil 8 irgendwie zur Verfügung stellen könntest?


    Grüße


    Micha


    Edit: hat sich erledigt, gibts bei hdfury zum Download

    Hi,


    freut mich, dass es bei dir klappt. Was hast du für einen TV? Mit meinem LG OLED E6V habe ich es nicht hinbekommen. Wird mit dem Sony A1 LLDV Profil, was bei meinem Vertex ja Profil 5 ist, nicht mehr als DV fähig erkannt, der Apple TV bieten dann nur noch HDR als Ausgabeformat an. Mit dem Oppo, der auch LLDV können sollte, kommt zwar am Ausgang des Vertex DV an, der LG schaltet aber auf normales HDR, weil er vermutlich mit dem LLDV Profil nichts anfangen kann. Am Grabber liegt damit ein zwar flaues, aber farbkorrektes Bild an.


    https://hyperion-project.org/t…er.3649/page-9#post-25268


    Grüße


    Micha

    So,


    habe das Ganze gerade mal erfolglos getestet.


    Setup:


    OPPO 203 -> Yamaha RX-A1060 -> hdfury Vertex -> China HDMI Grabber + LG OLED 65E6V


    Wenn ich im Vertex beide Ausgänge auf das "Sony A1 LLDV V2" Profil stelle, habe ich an beiden Ausgängen ein Bild ohne Farbverfälchung. Der Grabber zeigt, wegen nicht vorhandenen Tonemapping, natürlich ein entsättigtes Bild an. Mit v4l2-ctl ließe sich dies jedoch einwandfrei hinbiegen.
    Mein LG erkennt jedoch kein DV im Signal mehr, er schaltet auf normales HDR um. Der Vertex gibt DV laut OSD jedoch auf beiden Ausgängen korrekt aus. Ich vermute also, dass der LG mit dem LLDV Profil nicht umgehen kann. Mit einen Sony TV könnte das Ganze meiner Meinung nach jedoch funktionieren. Ob vielleicht auch mein AV Reciver bei der Geschichte reinkrätcht, kann ich auf Grund meiner wüsten Verkabelung leider nicht verifizieren.


    Grüße


    Micha

    Hi,


    in irgeneinem Threat hat fir3drag0n was zu Dolby Vision low-latency geschrieben, finden den Link aber gerade nicht. Wenn ich das richtig verstanden habe, sollte der Vertex oder Integral2 damit kein Problem haben und am downscale Ausgang ein entsättigtes SDR Signal ausgeben, also ohne korrekte Farbraumkorrektur, aber wenigstens ohne Bildfehler. Rein von der Bildqualität dürfte es ja keine Geige spielen ob der TV das Bild als lldv oder richtiges Dolby Vision bekommt. Werde das Ganze die Tage mal mit dem Oppo testen, den müsste ich den lldv Modus zwingen können. Im optimalsten Fall kann dies vielleicht der hdfury per EDID vortäuschen, dass das Endgerät nur das lldv Profil unterstützt und die Quelle in diesen Modus zwingen.


    Grüße


    Micha