Karte bsw. gültig bis 2019, neue Karte geschickt bekommen, mit neuer Karte bezahlt, alte Karte wird dann bei der Bank deaktiviert und läuft nun auch nicht mehr im Tan-Leser.
Geht wenigstens die neue Karte im Kartenleser?
Posts by zillerbaer
-
-
Bei der DKB nutze ich mehrere Konten mit einer Girokarte + ChipTAN QR. Nicht jedes Konto braucht eine eigene Karte. Die Bank kann mehrere Konten in einem Einlogaccount zusammen legen. Das habe ich aber auch erst nach drei Telefonaten erfahren.
-
Android und sicher. Davon kann keine Rede sein. Abgesichert ist nur die Abhängigkeit vom Gockel. Die Daten liegen für jede App offen rum.
Da hilft nur beten.
-
Das erinnert mich an "fix sometimes wrong audio PTS":
https://github.com/j1rie/softh…7e290d8e833caf25ae9106666Den Ansatz halte ich für richtig. Nur würde ich in audio.c die Schreib, Lese und Auswerte Zugriffe auf den Ringbuffer mit einem Mutex absichern.
-
Evtl. liegt es ja wirklich am Audio und dein Mutex verbessert es. Bin gespannt ob du Erfolg damit hast. Dann übernehme ich es
Den Mutex kannst Du schon einbauen. Die PTS von Audio stimmt ab und zu nicht.
Einen zweiten Punkt hab ich noch gefunden. Wenn ein Audio Packet in den Ringbuffer geschrieben wird wird die PTS gesetzt. Die ist aber für das erste Sample im Packet. Beim Ermitteln der Audio PTS wird die aber für das letzte Sample angenommen. Ich füge beim Setzen der PTS jetzt die Zeit die das Packet beinhaltet zur PTS hinzu.
-
Ich hoffe du siehst nun warum ich stille einfügen möchte.
Mmmh. Stille einfügen würde ich nicht. Warum ist der Decoder so langsam? Da seh ich das Hauptproblem. Wird in SW decodiert? Die Startschwelle könnte mit AudioStartThreshold * 6 verzögert werden.
Das ganze passiert auch im laufenden Programm wenn der Audiotakt leicht zu schnell ist.
In x86 Systemen sind zwei Taktgeber. Einer auf der Soundkarte und einer auf der Videokarte. Soweit auseinander sollten die aber nicht liegen! Wenn Du das Problem wegwerfen von einem Frame und danach gleich wieder verdoppeln meinst, die Hauptursache hab ich gefunden. Es gibt 3 Threads die auf den AudioRingBuffer zugreifen. Die Zugriffe habe ich mit einem Mutex abgesichert und es lief viel stabiler. Ich hab's leider noch nicht im git. Bin noch am Testen.
Wenn ich das AudioStartThreshold * 4 < n abschaltet dann braucht man zwingend das AudioVideoReady zum starten des Audio, und das kommt aber nicht bei Radio sendern. Deswegen habe ich es erstmal wieder eingebaut.
Da bin ich am Überlegen den PlayMode zu nutzen.
-
Ich schaue mal ob ich eine einfache Lösung finde um Audio "Stille" einzuschleusen. Nur so wird es langfristig stabil. Hast du evtl. eine Idee ?
Wozu brauchst Du Stille und was willst Du stabilisieren?
-
Das Konzept nur Video "wegzuschmeißen" funktioniert bei softhddevice manchmal nicht.
Dem ist nicht so. Da wird beim Start der Wiedergabe auch Audio weg geschmissen. Nach dem Start sollte alles so synchron laufen das nix mehr "entsorgt" werden muss. An der Problematik sitze ich auch gerade für softhddevice-drm.
Edit: Da wird auch audio verworfen.
-
Ich habe mir neulich einen 42-Zoll Grundig im Rewe für 199 € gegönnt, hat Mediatheken, Netflix, Amazon und was weiß ich noch alles.
Hast Du mal darüber nachgedacht wie die Software im TV für den Preis geschrieben und gepflegt werden soll? Ich würde mit dem Fernseher niemals online gehen auch wenn es sehr bequem ist.
-
Ich werde in jedem Fall erstmal weiter an einem Ausgabeplugin arbeiten was meine Wünsche realisiert
Das mache ich auch. Um Streaming kommt man aber nicht mehr herum. Beispiel Ski WC. Im TV wird eine Zusammenfassung gebracht und der komplette Wettkampf läuft im Stream. Meinen Ansatz Mediaplayer mit dem ich das Abdecken wollte habe ich aus o.g. Gründen beerdigt. Vielleicht spendiere ich softhddevice-drm Playerfunktionen.
Gerade die Geschichte mit den Ausgabeplugins, in unsinniger Vielfalt und größtenteils ungepflegt,
VDR wird nun mal nicht im Team entwickelt sondern in eine Ansammlung von Einzelkämpfern.
Meiner Meinung nach ist der VDR (auf Client-Seite) auf dem Stand des alten Pentium im Scovery-Gehäuse stehen geblieben.
Ja, das bedaure ich auch sehr.
-
Ja, VDR ist veraltet. Was VDR attraktiv macht ist die Netzwerkfähigkeit. Auch wenn das hauptsächlich Plugins machen. Es steht eine Kiste die eine fette HDD hat auf der Videos und Musike ist und mit einem kleinen Raspi hat man alles in allen Räumen. Als schlimmer empfinde ich das VDR nur PES oder TS weitergibt. So parsed VDR den stream und das Ausgabeplugin dann noch einmal. Wenn man einen Player schreiben will muss das Material in PES/TS gewandelt werden und das Ausgabeplugin muss sich da wieder alles rausfummeln. Das sind in meinen Augen alte Zöpfe aus FF-Karten-Zeit die fallen sollten. Wenn es einfacher wäre plugins zu schreiben würden sicher mehr dran arbeiten.
Es wäre auch eine Überlegung wert auf eine Multimedia-Lib wie FFmpeg umzusteigen. Das würde vieles vereinfachen. Man muss heute nicht mehr alles selbst schreiben und pflegen.
-
wäre das dann nicht nur ohne HW Beschleunigung ?
Neee, es geht um mit HW Beschleunigung. In SW sollte SD jetzt schon funktionieren.
wird wohl "demnächst" auch im offiziellen ffmpeg auftauchen.
Klingt gut.
-
ffmpeg sollte imho das von hier sein: https://github.com/Kwiboo/FFmp…4l2-request-hwaccel-4.0.4
Die FFmpeg Version arbeitet nicht mit linux 5.3-rc6 zusammen. Libreelec nutzt ein heavy patched 5.1er Kernel. Da werden wir noch warten müssen.
-
VDR brauch dann aber noch immer ein v4l2 m2m Ausgabeplugin
So weit ich das verstanden habe wird ffmpeg benutzt. So sollte softhddevice-drm damit klarkommen.
-
In der Doku zum Plugin steht: analog Audio und HDMI ist möglich.
Mit softhddevice-drm kann jedes alsa device benutzt werden. Die Beschränkung auf o.g. Ausgänge gibt es da nicht.
-
Rockchip und RaspberryPi laufen doch schon. RK3399 soll ja auch 4K/HDR können. Die Treiber fehlen halt noch.
-
Nur gibt es kein VDR-Ausgabeplugin für Amlogic
Das ist in Arbeit. Nur ist der V4l Treiber noch nicht im mainline Kernel drin. 5.3 wird mpeg unterstützen. H264 und HEVC ist noch nicht in der pipe.
-
wenn es ein VDR V4L2 M2M Plugin gibt wird es dann neben RPi auch Allwinner, Rockchip, AML, IMX und Snapdragon unterstützen.
Ohne HW deinterlacer muß es eine Mischform mit ffmpeg bleiben. Mal sehen wie sich die v4l Schnittstelle in FFmpeg entwickelt.
-
Softhddevice, Vaapidevice, Softhdcuvid, ...
... alle haben Johns als Ursprung. Das ist halt mit forks so. Ob die wieder zusammen geführt werden ist fraglich aber schön wäre es schon.
Das Decodieren an sich ist ja nur die halbe Wahrheit - problematisch, weil plattformabhängig, ist auch die synchronisierte Ausgabe der decodierten (ob nun mit oder ohne Hardwareunterstützung) Audio- und Videoframes. V4L scheint da ein vielversprechender Weg zu sein, aber wann das für die neue Himbeere kommt ist fraglich.
Die Ausgabe per DRM funktioniert eigentlich recht gut. Problematisch sind die unterschiedlichen FB Formate.
Die v4l Entwickler sind momentan dabei sich eigene Standarts zu erarbeiten. Auch da ist der Zoo recht gross(plane, mplane, statefull, stateless, ...). Aber immer noch besser als wenn jeder Hersteller sein eigenes Süppchen kocht.
-
Quote
The end result should be that we start to adhere to more standard Linux libraries rather than the vendor specific MMAL.
Das hört sich doch sehr vernünftig an! Den Sonderweg OMX/MMAL hab ich nie gemocht. Wenn jeder Hersteller seine eigenen Bibliotheken hat muss für jedes Board extra geschrieben werden. Wenn Standarts wie v4l oder ffmpeg genutzt werden ist der Aufwand die Hardware zu unterstützen gering.
