Passthrough wird m.E. undecodiert nach Synchronisierung mit dem Video weiter geleitet. Header davor damit der AV-Verstärker erkennt was da kommt. Der Rockchip HDMI Treiber konnte als ich mir das das letzte Mal angesehen habe aber nur mit PCM umgehen. Wie der Stand heute ist weiß ich nicht.
Posts by zillerbaer
-
-
Wer Software Bastelei nicht scheut, kann auch ein ARM64 Chromebook nehmen und Linux drauf packen. Mit 8 Kernen und 8 G Speicher sind die ausreichend potent und energetisch unschlagbar. Das Voltkraft Schätzeisen kann bei schwarzem Panel keine Stromaufnahme messen. Ein Lüfter ist gar nicht vorhanden.
-
Dann wird bei mir die Festplatte der Flaschenhals sein. Ich ändere das aber nicht, weil das nur die Entwicklungsumgebung ist. Mit der Produktivumgebung auf der emmc bin ich zufrieden.
-
dass er von USB-SSD startet?
Das bringt nicht wirklich viel. Mein ARM Notebook bootet von einer USB3 HDD um vieles langsamer als von der emmc.
-
Wohl war, aber die braucht man ja nicht, wenn man mit SD-Karte zufrieden ist.
Es heißt CPU ... Processing Unit, nicht Waiting Unit. Mit SD-Karte kann man mal was testen, aber zum Benutzen macht es ohne emmc keinen Sinn.
-
Naja, die notwendige emmc kostet auch nochmal mindestens 22Eus:
-
Nur leider fängt der gdb mein Ctrl-C ab und reicht es nicht an den vdr durch.
Codehandle SIGINT pass continueDas in der gdb Konsole sendet Ctrl-C weiter.
-
Wenn ich das (so wie hier) nicht kenne, finde ich Fragen in "natürlicher Sprache" an die KI komfortabler/schneller.
... und bekommst eine einfache Antwort, die auch falsch sein kann.
-
Könnte man da noch mit zählen, welche Plugins verwendet werden?
Da geht's schon los. Müssen wir uns gegenseitig überwachen? Das ist freie Software! Ich hab softhddevice-drm geschrieben weil ich es wollte und deshalb pflege ich das auch. Später hab ich mich gewundert von welchen Teilen der Welt ich angeschrieben wurde und bin auch ein bissel stolz drauf. Aber niemals würde ich die User überwachen wollen!
-
Die Frage war auch eher rethorischer Natur ;-).
... und ich wollte zum Ausdruck bringen das Du uns mit dem Goggel in ein Haifischbecken zum Fressen wirfst.
-
Wärst du bereit, das zu implementieren?
Für mich ist das ein nicht notwendiges Gimmick. In softhddevice-drm will ich noch einiges implementieren und komm nicht dazu. Ausserdem arbeite ich aktuell an einem ARM Notebook. Mit Prio 255 vielleicht.
-
Ich hab mir den User Counter jetzt noch mal angeschaut und wurde von Goggel aufgefordert irgendwas zu zustimmen. Das nervt schon mal. VDR ist freie Software. Wäre da nicht OSM eine Alternative?
-
Meinungen, Kommentare dazu?
Ich empfinde das als übergriffig. Keine SW sollte aus was für Gründen auch immer nach Hause telefonieren wenn es nicht sein muss. Es sollte mindestens im Menu abschaltbar sein.
Das vdr gern benutzt wird, siehst Du ja hier im Portal.
-
Da könnten die Packete mit if (TrickSpeed) an Stillpicture() weiter gereicht werden.
-
DTS hast du auch angepasst ?
DTS wird von den meisten Decodern nicht benutzt. Im softhddevice-drm ist das immer leer.
In Stillpicture wird in einer Schleife so oft das selbe Packet in den Decoder geschoben bis ein Frame rauskommt. Die Stillpicture funktion wird doch auch bei Trickspeed genutzt, oder?
-
wir von der MLD sind ja auch immer auf der suche welche sourcen die 'besten' sind für ein plugin.
Wie funktioniert das in der open source Welt? Ein Plugin, ein Maintainer. Der kümmert sich um patches. Was nicht gepflegt wird fliegt raus. "Fliegende" Patches im Forum werden ignoriert. Es muß sich ein Maintainer finden der den Code weiter pflegt.
Gruss zille
-
Evtl. muss man hier ein I-Frame abwarten
Es sollte immer mit einem I-Frame gestartet werden! Das beinhaltet ein komplettes Bild. Die anderen Frames haben immer Abhängigkeiten zu anderen Frames weil nur die Veränderungen zu anderen Frames codiert sind.
Edit: Soweit ich das verstehe nutzt Du meine Vorlage und da wird auf das erste I-Frame gewartet.
-
Es geht eigentlich kein Packet ohne PTS in den Decoder. Der Decoder scheint da das Problem zu sein.
-
Im Stream sind die Packete in der Decodierreihenfolge. Das ist nicht zwangsläufig die Anzeigereihenfolge. Das sortieren macht nach dem decodieren der Decoder anhand des PTS. Das scheint bei AML noch zu fehlen. Der PTS steht im undecodierten Packet und wird vom Sender / Encoder festgelegt.
-
Was für ein Kernel benutzt Du? Die Kernelmeldungen sehen bei mir so aus:
Code
Display More[ 0.614733] pci 0000:00:00.0: enabling device (0000 -> 0002) [ 0.614782] ddbridge 0000:01:00.0: enabling device (0000 -> 0002) [ 0.614988] ddbridge 0000:01:00.0: detected Digital Devices Cine S2 V6 DVB adapter [ 0.615046] ddbridge 0000:01:00.0: HW 0001000d REGMAP 00010004 [ 0.615423] ddbridge 0000:01:00.0: using 2 MSI interrupt(s) [ 0.617713] ddbridge 0000:01:00.0: Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-S2 [ 0.618836] ddbridge 0000:01:00.0: Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE [ 0.619945] ddbridge 0000:01:00.0: Port 2: Link 0, Link Port 2 (TAB 3): NO MODULE [ 0.640990] dvbdev: DVB: registering new adapter (DDBridge) [ 0.641080] dvbdev: DVB: registering new adapter (DDBridge) [ 0.750344] random: fast init done [ 0.802691] LNBx2x attached on addr=a [ 0.802729] i2c i2c-9: Attaching STV6110x [ 0.802754] ddbridge 0000:01:00.0: attach tuner input 0 adr 60 [ 0.802783] ddbridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV090x Multistandard)... [ 0.839356] LNBx2x attached on addr=8 [ 0.839389] i2c i2c-9: Attaching STV6110x [ 0.839410] ddbridge 0000:01:00.0: attach tuner input 1 adr 63 [ 0.839436] ddbridge 0000:01:00.0: DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...
