Ich finde es total klasse, das es bewegung bei dem Thema gibt.
Das installieren war jetzt auch nicht so schlimm, schade ist natürlich das es bei HD+ im Moment bei mir kein Bild gibt.
Trotzdem vielen Dank an alle die geholfen haben, das wir jetzt schon so weit gekommen sind.
Gruß
speed
Ich hab jetzt probehalber Libreelec und am VDR vdr-Plugin-vnsiserver installiert und nach wenigen Minuten kann ich am Raspi - leider via Kodi - VDR schauen (auch verschlüsselte Sender). Wow!
Also prinzipiell funktioniert das (gut?) mit der Hardware.
Ich freu mich schon auf eine „native VDR-Lösung“. Wenn die Beteiligung so rege bleibt, sollts ja bald soweit sein.
Ich hab jetzt probehalber Libreelec und am VDR vdr-Plugin-vnsiserver installiert und nach wenigen Minuten kann ich am Raspi - leider via Kodi - VDR schauen (auch verschlüsselte Sender). Wow!
Wenn Du genau hinschaust wirst Du feststellen das auch LE keinen HW Deinterlacer hat. Was LE kann kann auch softhddevice-drm. Da gibt es keinen Unterschied!
Warum bekomme ich den kein Bild bei den HD+ Sendern nur Ton, aber kein Bild.
Da fehlt mir wohl ein kleine Info, kann mich mal jemand aufklären 
Warum bekomme ich den kein Bild bei den HD+ Sendern nur Ton, aber kein Bild.
Da fehlt mir wohl ein kleine Info, kann mich mal jemand aufklären
HD+ habe ich nicht. Ich teste 1080i auf ServusTV. Es dauert etwas aber beim Umschalten aber es läuft dann. Teste mal den Sender! Dann kannst Du im Makefile DEBUG einschalten und mir die Ausgabe auf der Konsole zukommen lassen. In Handauflegen und Ferndiagnose bin ich nicht gut.
du hast keine Glaskugel wo du alles siehst ?
du hast keine Glaskugel wo du alles siehst ?
Die ist kaputt. Nach den Film über Mr. Slowhand will ich mal LSD testen. Soll farblich sehr interessant sein.
Kann ich bestätigen, geht gut 
Nach den Film über Mr. Slowhand will ich mal LSD testen.
Aber der hatte es doch mehr mit dem Alk 
Beides cool
Wenn Du genau hinschaust wirst Du feststellen das auch LE keinen HW Deinterlacer hat. Was LE kann kann auch softhddevice-drm. Da gibt es keinen Unterschied!
Bitte wiederum nicht als Kritik (an Dir) auffassen.
Softhddevice-drm ist sicherlich die Zukunft für den raspi4, aber ich als eher Laie, habs nicht hingebracht.
Du wirst wohl recht haben und LE macht alles in SW, aber das Bild war da und verdammt gut qualitativ;
CPU-Auslastung habe ich freilich nicht geprüft. War nur schon mal begeistert, wie einfach und schnell das ging.
Mal ne andere blöde Frage: eigentlich sollte softhddevice-drm - wenns mal ganz fertig ist - doch die eierlegende Wollmilchsau unter den Ausgabeplugins sein.
Sollte dann mit Nvidia, Intel, Ryzen und Raspis (ARM) zurechtkommen, oder irre ich da?
Könnte man deine (zillerbaer) und lnjs Kräfte bündeln und EIN softhddevice bauen, das "alles" kann?
Oder sind die beiden Streams doch zu verschieden?
Stimmen die Eigenschaften deines drm-Plugins noch in dieser Aufstellung von Alexander - Abschnitt "6.2 Unterstützte Ausgabeplugins"?
Aber der hatte es doch mehr mit dem Alk
Erst zum Schluss, sozusagen zum Abgewöhnen. Vorher alles was Spass macht.
Du hast recht, jetzt sollten wir uns aber wieder dem Thema zuwenden.
Softhddevice-drm ist ausgerichtet auf ARM Devices. Aktuell werden Allwinner, Rockchip und Raspberry unterstützt. Abhängigkeiten zu X etc sollen weitestgehend vermieden werden und nur Linux Typische Schnittstellen unterstützt werden. Proprietäre Schnittstellen wie vdpau etc. sollen vermieden werden. Momentan wird MMAL als proprietär noch unterstützt wird aber mit einem Treiber für HW Deinterlacer wegfallen. Ist halt historisch so gewachsen.
Eine Integration in John's Softhddevice war mal geplant. Seit der Zeit hat sich aber alles nur auseinander entwickelt. Das sich das umkehrt ist wohl unwahrscheinlich.
Mit dem Softhddrm habe ich nix zu tun. jojo61 nennt sein plugin Softhddrm. Ist bissel unglücklich gewählt.
Ok, danke für die Erläuterungen!
Dann könnte man deins quasi auch "softhddevice4arm" nennen und Jojo61s "softhddrm" wär dann quasi für alle "großen" x86/x64-CPUs (AMD, Intel), richtig?
Ich nutze dzt. (siehe Signatur) noch das softhddevice-openglosd-ffmpeg2.8 unter Ubuntu 18 und würde dann (mit Ubuntu 20) wohl softhddrm nehmen, wenn obiges stimmt und mit meiner HW gut läuft.
Dann könnte man deins quasi auch "softhddevice4arm" nennen und Jojo61s "softhddrm" wär dann quasi für alle "großen" x86/x64-CPUs (AMD, Intel), richtig?
softhddevice-drm gab es zuerst! softhddrm ist später entstanden und beinhaltet auch Code von mir! Wie jojo61 sein Plugin ausrichtet entscheidet er. Ist halt freie Software!
Mit dem Softhddrm habe ich nix zu tun. jojo61 nennt sein plugin Softhddrm. Ist bissel unglücklich gewählt.
Ja die Namesgebung ist nicht so einfach. Die Version softhdcuvid und softhdvaapi orientiert sich am decoder und softhddrm orientiert sich am Ausgabe API. Ursprünglich wollte ich auch noch eine Version für den Raspi machen, habe das aber zwischenzeitlich aufgegeben weil er für meine Ideen einfach zu langsam ist.
Beim Raspi kann man nur sinnvoll Videos ausgeben wenn man auf dem ganzen Weg vom Stream zum Display nur Hardwareresourcen nutzt. D.h. Hardwardekoder für den Stream und HardwareAPI (drm) für die Ausgabe. Es gibt praktisch keine Möglichkeit das Bild zwischendurch zu bearbeiten. Dafür ist der Raspi bzw. die GPU zu langsam. Ich hatte eine Version mit einem opengl shader fertig zur konfertierung von YUV nach RGB auf X. Doch schon hier gab es Probleme mit der performance. Das ganze geht halt nur wenn man drm nutzt und das in Hardware machen lässt. Und dafür gibt es hier eine exzellente Entwicklung von zillerbaer
Ich finde die Idee das ganze softhddevice4arm zu nennen sehr gut zumal mit v4l2m2m ja auch ein "universal" decoder genutzt wird.
mfg
jojo61
Ich finde die Idee das ganze softhddevice4arm zu nennen sehr gut zumal mit v4l2m2m ja auch ein "universal" decoder genutzt wird.
Der Direct Rendering Manager ist der zentrale Teil des Plugins. Neben der Enscheidung auf Abhängigkeiten zu X zu verzichten, ist das der prägente Teil meiner Philosophie. Ich sehe keinen Grund eine Namensänderung vorzunehmen.
Richtig, das Packet ist i.O. Die PES Header Erzeugung stimmt nicht. Der Mediaplayer spielt das Video ja ab.
Bleibst Du daran, oder ist das Thema damit für Dich erledigt?
Bleibst Du daran, oder ist das Thema damit für Dich erledigt?
Das sehe ich eigentlich als erledigt an. Die Art Transport Stream wie er von vdr kommt wird unterstützt. Ich halte die Schnittstelle von vdr für veraltet. Momentan wird der Stream von vdr untersucht und da diese Informationen nicht weiter gegeben werden macht das Augabeplugin das noch einmal. In meinen Augen nicht nötig. Aus diesem Grund habe ich den Mediaplayer auch direkt integriert. Aus vorliegenden Daten ein TS zu basteln und dann wieder zu parsen halte ich für Quatsch. Der Mediaplayer spielt die Files ohne Probleme ab.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
