Ich wollte nach dem Ausschlussverfahren Vorgehen, weil im Moment kann es halt theoretisch Kodi selber sein, die Shield, der TV oder der Receiver...
Kodi zeigt auf jeden Fall bei den Streams in den nerd-Statistiken an das sie AC3 sind.
Ich wollte nach dem Ausschlussverfahren Vorgehen, weil im Moment kann es halt theoretisch Kodi selber sein, die Shield, der TV oder der Receiver...
Kodi zeigt auf jeden Fall bei den Streams in den nerd-Statistiken an das sie AC3 sind.
Ok, sowas in der Art war meine Befürchtung. Der Receiver hat durchaus HDMI in, aber kein 4k - und die Erfahrung hat mich leider gelehrt, dass HDCP auch in 2021 immer noch eher Fluch als Segen ist. Aber ja, der steht als nächstes auf der Liste der zu tauschenden Geräte.
@DaVu ne, war nicht aktiviert...
Ah, unter Player war's... Deswegen hatte ich das gestern Abend nicht gefunden. Danke @DaVu, schau ich nachher Mal nach
Die ist in den Grafik-Einstellungen, oder? @DaVu
Ich stehe gerade irgendwie auf dem Schlauch. Mein (oller Pioneer Slimline) AV-Receiver kann sowohl AC3 als auch DTS, und mindestens bei AC3 bin ich mir ziemlich sicher, dass er das normalerweise auch auf dem Display anzeigt...
... tut er aber nicht, fällt mir gerade auf. Ich würde gerne, dass sowohl aus Kodi als auch von der Shield selber beide Formate an den TV (Sony KD-65XF9005) weitergegeben werden. Dieser hängt optisch dann am AV-Receiver (und sollte für Passthrough schon richtig eingestellt sein).
Mag einer mal zum Gegenchecken die richtigen bzw. dafür nötigen Einstellungen teilen bitte?
@JensK Mal schauen wie weit ich komme Ich optimiere erstmal den Status-Quo, dann schau ich mal in Richtung der Machine-Learning Möglichkeiten, erstmal in Sachen Deinterlacing, dann evtl. noch Skalierung.
Lustiger Nebenfind auf jeden Fall:
Vorher lief bei mir Comskip auf nem RPI 3B mit so ca. 20 FPS auf seinen 4 Cores. Der Jetson Nano schafft so in etwa 120 FPS, auf einem Core. Was vorher also ca. 60 Minuten gedauert hat dauert jetzt nur noch maximal 10...
Also das "Template" aus dem er die Crontab erzeugt findet sich hier, Inhalt ist:
${FREQUENCY} su -s /bin/bash -c "TERM=xterm /bin/bash /usr/local/bin/easyepg.process" ${USERNAME} > /proc/1/fd/1 2> /proc/1/fd/2
Er würde also wenn Du den Container neu anlegst wieder das "su -s" dazupacken. Ich hab's aber gerade nochmal bei mir nachgeschaut: Er hat heute nacht wieder ganz sauber die XML-Dateien erzeugt. Das dürfte also kein grundsätzliches Problem sein...
In welcher Datei steckt das Skript drinne, welche Kanäle ich von welcher Quelle lade etc?
Mit den Dateien wirst Du da nicht so weit kommen bzw. viel friemeln müssen, die sind ziemlich verteilt. Aber das Admin-Interface hat einen Punkt Backup/Restore mittlerweile - ich hab den aber noch nicht benutzt um ehrlich zu sein
OK, vom User her passt das, aber:
Mein Container hat nicht umsonst den oben genannten Parameter! Bei jedem Start des Containers wird die Crontab automatisch neu auf Basis dieses Parameters erzeugt. Von Hand geänderte Crontabs gehen dabei verloren. Von Hand ändern ist daher keine gute - und vor allem keine persistente - Idee. Zum Testen natürlich sicherlich OK
Wie bist Du denn in den Container rein gegangen, also als welcher User? Denn:
Mein Container führt den Cronjob als root aus, daher auch das "easyepg" vor dem ">". gehst Du jetzt als normaler User "easyepg" rein und machst "crontab -e" dann legst Du einen zusätzlichen Cronjob für diesen User an. Das könnte evtl. dann wirklich komplett failen.
Und, ehrlich gesagt, mein Container hat doch genau wie das ändern der Cron-Zeiten einen Parameter den Du auch schon übergibst. Eigentlich gibt es keinerlei Grund da irgendetwas innerhalb des Containers machen zu müssen von Hand:
Da shreibste einfach Deine Zeiten rein und gut is...
Aber normal nutzt du sonst nicht den Socket? @darkside40 bin mir nicht sicher, ob das noch so ist, aber es gab da wohl Mal nen Bug mit dem dicken... Daher schreibt mein Container das mit nem sleep dazwischen 2 Mal rein
Die Shield hat ja bekanntermaßen ein ziemlich nettes AI-Upscaling, was aber leider kein interlaced-Material verarbeiten kann. Hier fällt sie einfach in "Optimiert" zurück und das sieht, zumindest für mich, einfach nur nach "Matsche" aus. Mir ist natürlich bewusst, dass meine 576i Magenta-Streams von den Privaten nun auch nicht gerade wirklich gute Qualität haben, aber historisch betrachtet weiß ich, dass ein gutes Deinterlacing halt doch noch so einiges retten kann.
Mittlerweile ist der Jetson Nano (4GB) da und läuft. Die Streams werden von diesem bereits über TVHeadend (via ffmpeg-pipe, da TVHeadend leider nur rudimentär RTSP unterstützt) angefragt. Dafür läuft auf dem Nano ein RTSP-Simple-Server der onDemand die Streams via GStreamer-Pipeline bereitstellt. Vorgeschaltet ist noch ein abgespecktes "Dumpstream", da GStreamer leider mit den MagentaTV Streams so nicht direkt arbeiten kann.
Funktionert rein technisch betrachtet super, lediglich die Umschaltzeiten verlängern sich unweigerlich deutlich - was für mich am Ende aber OK wäre.
Beim reinen Deinterlacing wird es wohl nicht bleiben was der Nano so leisten muss. Das schafft er ganz locker, wie auch das h264 de- und encoding mit insgesamt ca. 10% CPU insgesamt und bei ~40°C. Es ist nur leider so, dass selbst mit dem besten Deinterlacing die Auflösung sehr gering ist. Die Unschärfe die beim "optimierten" Skalieren der Shield entsteht ist vermutlich tatsächlich so gewollt um die sichtbaren Pixel loszuwerden...
Trotzdem bin ich zuversichtlich, dass das noch deutlich besser geht und optimiere fröhlich
@darkside40 schreibst du das dann von Hand auf den Socket?
@Simaryp also mein Container cleared das xml Verzeichnis bei jedem Start, ja.
Warum lässt du denn eigentlich den cronjob stündlich laufen? Das ist doch unnötig viel... Bei mir dauert ein einziger Durchlauf (auf einer zugegeben lahmenkiste) bei etwas über 20 Sendern auch schon so ca 45 Minuten...
So etwas könnte natürlich dazu führen, dass bei dir am Ende quasi nie eine greifbare xml vorhanden ist...
OK, ich hab's...
Ich hatte bisher immer nur die Stream-URL des bestehenden Muxes geändert. Tue ich das, dann geht nur und ausschließlich die URL von MagentaTV, die da schon ewig drin steht (aber halt nur SD ist). Ich hab jetzt mal testweise einen neuen Mux angelegt und siehe da: Es geht dann auch mit einer der anderen URLs in Verbindung mit meiner "Standard-Pipe".
Ehrlich gesagt hatte ich bisher nie ein Problem damit bei bestehenden Muxes die URL zu ändern (und das tue ich gerade auch ziemlich häufig) - ist das grundsätzlich evtl. keine so gute Idee?