Beiträge von FreshGer

    Basierend auf den Gedanken von @GnaGetier habe ich noch etwas konkreteres gefunden: MPlayer kann sich des v4l2-Inputs bedienen und bietet u.a. einen Filter zur Rauschunterdrückung.


    Links:


    Den von Mplayer genutzten Filter zur Rauschunterdrückung Namens hqdn3d, gibt es alternativ auch für AviSynth: „High Quality DeNoise 3D is an AviSynth 2.5 port of the MPlayer filter of the same name. It performs a 3-way low-pass filter, which can completely remove high-frequency noise while minimizing blending artifacts.“
    http://avisynth.nl/index.php/Hqdn3d


    Mit Hilfe des angesprochenen Loopbacks könnte man das so manipulierte Video wieder als v4l2-Device einreihen und Hyperion vorwerfen.

    meine RPi-Kamera bietet den Sharpness-Parameter. Vielleicht schaffe ich es gegen später Screenshots zu machen um den Effekt darstellen zu können.


    Das ist doch aufjedenfall ein Versuch wert. Wir wissen doch noch garnicht, wie brauchbar die Control ist. Außerdem halte ich die Anpassung an der Stelle für gerade richtig, da wir hier auch schon an Helligkeit und Kontrast schrauben können ohne Performanceverlust. Sprich, so abwegig find ich meinen Vorschlag immer noch nicht.. xD


    das ganze auf ein input wie einer kamera zu begrenzen macht keinen sinn...


    Würde ich auch nich tun. Wir wissen ja noch garnicht, ob es neben Kameras nicht auch einen HDMI Grabber (in der großen weiten China-Welt) gibt, der die Control unterstützt. Also würde es hier lediglich auf Inputs (aller Art) beschränkt werden, die die Control mitbringen.


    Der Auszug aus der Doku bezog sich auf Video4Linux2 im Ganzen und nicht „for Cameras only“.

    Ich glaube ich habe etwas gefunden, um das v4l2-Bild verschwommen darzustellen: https://medium.com/@petehousto…era-on-linux-a364e8b7d1f8


    Hier hat eine Kamera, die per v4l2 angebunden wird, (neben Brightness, Contrast und Saturation) einen Sharpness-Parameter. Setzt man den runter, würde das Bild sicher verschwommener! :)


    In der Doku (https://linuxtv.org/downloads/v4l-dvb-apis-new/media.pdf) heisst es:


    Der HDMI Grabber muss diese Option halt unterstützen. —> Und damit wären wir wieder beim Thema Hardwaretest.


    Vielleicht kann ja jemand, der neben dem Y&H Grabber einen anderen digitalen HDMI Grabber (z.b MYPIN) bestellt hat, mal mit v4l2-ctl --list-ctrls überprüfen, ob dieser die Sharpness-Option unterstützt.

    @TPmodding: Sowas sollte der richtige Ansatz sein. Das Quellmaterial ist ja ganz offensichtlich in dunklen Szenen ein Problem (da unruhig) und müsste etwas „aufgehübscht“ werden.


    Ich hatte auch schon geschaut, ob es eine Art Rauschunterdrückung (wie es der Fernseher intern macht) für v4l2 gibt - aber nichts gefunden. Der Unschärfe-Effekt würde aber sicher ähnliches bewirken.


    Ich weiss nicht ob das auch ein möglicher Ansatz wäre, aber ich teile trotzdem mal meine Gedanken: Eventuell ist es auch mit der schon vorhandenen Glättungsfunktion realisierbar. Vielleicht könnte diese „Farbwerte kurz vor Schwarz“ geringer Gewichten. Quasi mit einer Art Faktor bei der Berechnung der Durschnittsfarbe des Zeitraums. Oder mittels eines smootheren Übergangs in die nächste berechnete Durschnittsfarbe das Flackern beheben.


    Oder besteht das Problem evtl. zusätzlich auch noch darin, dass eine LED nie den gesamten Farbraum abdecken kann, da eine LED auch im abgedunkelsten Zustand (kurz vor aus) noch locker über RGB(50,50,50) liegt? Das würde zumindest auch erklären warum es zwischen schwarz und dunkelgrau einen harten Übergang gibt.

    ich muss mit meiner Helligkeit deutlich höher auf 165 oder 170, damit das Flackern bei mir komplett verschwindet...


    @snikcers, und welche Kontrast und Gamma-Werte hast du hierbei gesetzt? Bin dahingehend auch noch etwas am optimieren. Letztendlich ist glaube ich auch einfach das Quellmaterial (selbst wenn es digital übertragen wird) nicht ganz sauber in dunklen Szenen - egal ob vom Sat-Receiver oder Streaming-Dienst. Mir fällt das am TV natürlich nicht mehr auf seitdem ich dort das Bildrauschen per Bildverbesserer korrigiere.

    Dagegen würde sprechen, dass es ja immer funktioniert, wenn die Signalquelle zuerst eingeschaltet wird.


    Ich habe ein 10A Netzteil. Bei 132 LEDs habe ich eine max. Stromstärke von theoretisch bis zu 8.7A. Der Raspberry pi 4, der USB Grabber sowie der HDMI Splitter werden zusätzlich darüber mit Strom versorgt. Das hört sich in der Tat knapp an, wenn ich so darüber nachdenke. Aber ich habe bis jetzt eigentlich nichts negatives bemerkt.

    @snikcers, die „Signal Erkennung“ habe ich bei der USB Aufnahme nicht aktiv. Ich weiß nicht, ob der Grabber deaktivert wird, jedoch bewirkt in einer solchen Situation der Befehl „v4l2-ctl --list-ctrls“, dass meine vom Startupt-Skript gesetzten Anpassungen der Helligkeit und des Gamma-Wertes wieder greifen. Das heißt sie sind schon irgendwie da, greifen jedoch dann nicht.


    Ich habe mich gerade mal informiert, wass ich mit udev machen könnte: „udev überwacht und wertet hotplug-Ereignisse aus“. Meinst du ich könnte das USB-Gerät als solches mit ihrer ID identifzieren und beim „plug in“ (warum auch immer der Grabber sich abhängen sollte) mein Skript starten?


    Das ist mein Ergebnis von „lsusb“
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 002: ID 1bcf:2c99 Sunplus Innovation Technology Inc.
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    Ich kann ja mal schauen, ob ich weniger Geräte habe, wenn das Signal mal wieder fehlt.

    Ich habe momentan das Problem, dass meine v4l2 brightness und contrast Anpassung nicht angenommen werden wenn das Skript läuft während keine Signalquelle anliegt. Zusätzlich verlier ich die Anpassungen wenn eine Zeit lang kein Signal anliegt, nachdem es schon funktioniert hat. Hat da jemand eine Lösung?


    Mir fällt da spontanerweise nur ein minütlicher Cronjob ein, der die v4l2 Settings erneut überschreibt...

    Also der erste Link scheint ja die selbe Capture Card zu sein wie die von Amazon, die schon einige erfolgreich implementiert haben. Die 1080p Variante ist älter, keine Ahnung wies da mit dem Lag aussieht.


    Ich persönlich könnt schon garnicht 3-4 Wochen darauf warten. xD


    Mein rPi 4 hat 4gb Ram - ich kann nachher mal gucken, wie viel er davon tatsächlich belegt.

    @xkuyax, wenn du Bock hast auf Experimente dann bestell Dir den. Bei den günstigen kannst aber davon ausgehen, dass Du zumindest Lags haben wirst, wenn v4l2 überhaupt ganz läuft. @esprit1711 hat dahingehend Erfahrungen gesammelt.


    Ich würde einfach den Y&H kaufen.


    Der Raspberry Pi 3 ist schon mit der Verarbeitung in 3 Facher Bildverkleinerung überfordert. Hol Dir nen rPi 4.


    Das Setup wird zwar etwas teuerer, aber dafür läufts deutlich besser als mit den AV-Convertern.

    Gern teile ich noch meine aktuellsten Erkenntnisse. Für alle die noch Flackern in dunklen Filmszenen haben: Es ist besser im Linux die v4l2 Helligkeit hochzuschrauben (z.B auf 150 statt 128) und nachträglich per höherem Contrast und Gamma-Werten die Farbe wieder rauszukitzeln. Ist die Quelle heller, kommt es seltener zu Entscheidungsschwierigkeiten in dunklen Szenen.


    Bitte hierbei nicht verwechseln mit einem Flackern, welches bei manchen im schlechtesten Fall auch dann noch auftritt wenn man den Film pausiert. Dies ist völlig unabhängig davon. Hier hilft jedoch wie schon erwähnt oftmals ein Levelshifter.


    Hier meine aktuellen Einstellungen, die bei meinem APA102c echt gut passen:

    @snikcers auch wenn du offensichtlich die Lösung für dein Flackern gefunden hast, hänge ich nochmal meine Config an. Ja ich habe auch einen Levelshifter.


    Ich verwende sie derzeit mit folgenden Anpassungen des Grabbers an meinem APA102C Streifen:
    pi@raspberrypi:~ $ v4l2-ctl --list-ctrls
    brightness 0x00980900 (int) : min=0 max=255 step=1 default=128 value=135
    contrast 0x00980901 (int) : min=0 max=255 step=1 default=128 value=131
    saturation 0x00980902 (int) : min=0 max=255 step=1 default=128 value=161
    hue 0x00980903 (int) : min=-32 max=31 step=1 default=0 value=0


    Ich werd aber nochmal das alte Hyperion ausprobieren, da mir der APA102C zu rot ist. ;) Gerade das Einstellen der Farben ist ne echte Herausforderung meiner Meinung nach.
    Das mit dem auskommentieren des "standard" probiere ich mal aus. Wie bist du denn darauf gekommen?

    Noch ein Update von mir:


    Da ich mit dem Kaltweiß und allgemein den Farben meines WS2801 Led-Streifens unzufrieden war bin ich auf APA102C umgestiegen, da diese einen deutlich geringeren Blauanteil haben sollen.


    Mit dem Ergebnis bin ich nun deutlich zufriedener.


    Doch dann begann es wieder: Das Flackern in dunklen Szenen. :/


    Ich kürz mal zur Lösung ab - es stellt sich heraus, dass unsere neue Y&H HDMI Grabber Geheimwaffe mit 23,976 Bildern pro Sekunde nicht gut klar kommt. Ich hatte meinem Apple TV vorher gesagt er solle die Bildrate automatisch dem Material anpassen. Bei Filmen und Serien ist dies oft diese krumme Zahl. Ich habe es also wieder widerwillig auf starre 60Hz gestellt, wodurch das Flackern wieder verschwand (und der Film zwangsläufig Frames auslässt - als Pille die ich wohl lieber schlucken muss).


    Kann sich das einer erklären? Im Webfrontend hab ich das in der Live-Video-Vorschau nicht nachvollziehen können.