Btw. kann man das OSD auf ein anderen Layer legen?
Sobald Video startet, habe ich kein OSD mehr. Scheinbar liegt Video über dem OSD!?
Das Video wird auf der Primary plane ausgegeben und das OSD auf der Overlay plane. Mit den vdr skins funktioniert das. Nutzt Du aufwendige Skins? OSD ist momentan einfaches Darstellen von ARGB.
Wie sieht deine /etc/asound.conf aus?
Ich habe gar keine asound.conf. Mit hw: wird direkt auf die HW zugegriffen. Lautstärke regel ich in Software.
Gruss zille
HDMI ist hw:1,0. Der Goggel ist Dein Freund 
Gruss zille
Überhaupt scheint mir die ganze VDR-Community beständig zu schumpfen,
Ja, leider scheint VDR ein bissel "Good Old" zu sein/werden. Da steht die Frage wie gegen gesteuert werden kann. Welche alten Zöpfe müssen fallen um dem Projekt wieder Schwung zu geben. Es wäre sehr Schade wenn das einschläft.
Gruss zille
Da fällt es mir wie Schuppen aus dem Haar.
Apr 2 21:50:00 tinkerboard vdr: audio: can't set channels 0 sample-rate 0Hz
Das Video wird nach dem Audio synchronisiert. Alsa scheint ein Problem zu haben.
Gruss zille
-a hw:0,2 ist der interne Soundchip.
Edit: Die heutigen git Versionen mpp und ffmpeg laufen.
MPP bringt neue header mit. Bau das aktuelle git von ffmpeg doch mal mit den neuen headern. Meine Versionen sind schon ein Paar Wochen alt. Ich mache gerade eine Sicherung des aktuellem Stands dann werde ich die aktuellen git Versionen von mpp und ffmpeg testen.
Gruss zille
Edit: In FFmpeg 3.4 war glaub ich noch die Version mit der alten mpp api drin.
Edit 2: Kannst Du mit einem Sender starten der in Mpeg sendet? Das wird SW decodiert.
Den alten Mist sollte ich mal löschen. Du brauchst die Version von Rockchip
https://github.com/rockchip-linux/mpp
Gruss zille
Welche mpp version hast Du? Du brauchst die Version von Rockchip. Was sagt :
tinker ~ # grep mpp_frame_deinit /usr/include/rockchip/*
/usr/include/rockchip/mpp_frame.h:MPP_RET mpp_frame_deinit(MppFrame *frame);
Gruss zille
Hallo Uwe,
das git von ffmpeg.org nutze ich. Longchair hat da rkmpp eingepflegt. Das Rockchip mpp ist dafür notwendig. Zwischen durch hatte sich bei mpp die api geändert. Das ist mittlerweile in ffmpeg angepasst.
Beim softhddevice-drm habe ich gerade grössere Umbauten gemacht. Auf die Abhängigkeiten von vdpau, vaapi und X brauch ich ja jetzt keine Rücksicht mehr nehmen.
Gruss zille
Auch interessant, da SATA. Was ich noch nicht verstanden habe, ist ob der Mini-PCIe nur USB-basierende Karten akzeptiert oder vollen PCIe Standart bietet. "Mini-PCIe slot for USB, LTE, or mSATA" klingt nicht gut. Eine DD Karte sollte schon sicher funktionieren.
Gruss zille
2 Entwickler wollen Treiber in den Linuxkernel bringen für AllwinnerSoCs
Dann kann ich das Cubietruck, mein erstes ARM Brett'l ja mal rauskramen. Als Client könnt's noch taugen.
Und wenn dann noch der VDR mit allen Plugins/OSDs usw. auf den kleinen Böxchen läuft
Läuft doch auf Rockchip! GL ist ist noch ein Thema. Vorher aber ein vernünftiger Mediaplayer.
Von Rockchip kommen bald gute Boards auf den Markt. Das finde ich sehr interessant. Dann schmeiss ich die x86 Kiste raus.
Gruss zille
Ich habe die Version getestet, leider keine Verbesserung bei den genannten Problemen.
Dann kann ich hier leider nicht viel machen.
Gruss zille
Ein Bier und schon klappt es mit dem Denken. Das HEVC nicht geht kann nicht viel sein. Testet mal bitte einer mit entsprechender Hardware das git:
https://github.com/zillevdr/vd…thddevice-vdpau/tree/hevc
Gruss zille
Was meinst Du damit, Audio-Ausgabe direkt über VDPAU? Dann ginge aber die Ausgabe nur über HDMI
Nein, audio.c regelt alles was alsa ist. Ich schreibe momentan an einem Mediaplayer der das decodieren und ausgeben dem Ausgabedevice (softhddevice) überlässt. MP3 läuft schon gut. Nur decodiert softhddevice aber gibt nix an alsa weiter wenn ich nicht mit -w alsa-no-close-open starte!??? Bei der Fehlersuche habe ich gesehen das bei der Konfiguration von alsa AlsaUseMmap abgefragt wird aber das wird nirgends gesetzt. mmap wird also nie benutzt.
HEVC transcode. werden sie nicht angezeigt.
Da kann ich wegen fehlender Hardware leider nicht helfen. Meine alte GeForce GT 520 kann das nicht und Vdpau Zeugs das HEVC kann kaufe ich mir nicht mehr. Das Tinkerboard kann das gut. Sobald ein ARM Board verfügbar ist das pcie hat und ordentlich mit Treibern ausgestattet ist fliegt das x86 Zeug raus!
Gruss zille
The vpp_support running here. My main issue are inside audio. It's too bad the separation from vdpau. What is necessary for a corporate development?
Regards zille.
Aber leider nicht der vdpau Zweig. Da werde ich mich am WE wohl selbst ransetzen müssen. Wir sollten uns überlegen alles in einem git zusammen zu führen. Im Audio Bereich stehen ja auch Änderungen an. Da könnte das eine vom anderen profitieren.
Gruß zille
Ich muss mich korrigieren. Der Branch vpp_support funktioniert auch mit vdpau.
In den Commits habe ich nichts gefunden, wenn das auch für vdpau gilt, ist alles i.O.
Für vdpau gilt das leider nicht. Lungert irgendwo noch ein git rum in dem vdpau gepflegt wird?
Gruss zille
auf meinem Cubietruck (Debian stretch) laufen
Das Cubie hat SATA. Probier doch mal mit einer HDD aus.
Gruss zille
Mpeg wird SW decodiert, H264 und HEVC in HW.
OSD ist rein Anzeige des RGB von vdr, keine aufwendige Skin.
Mpeg Qualität ist OK. Ein Frame von 288 x 720 auf HD zu scalieren ist halt nicht besser machbar. RPI2 Qualität vergleichbar.
Ich nutze es täglich. Bugs sind noch keine gemeldet worden.
Gruss zille
Ja, läuft als Client mit streamdev.
Ich hatte das tinkerboard vor einigen Wochen mal da und war von der Grafik performance entsetzt ....
Meinst Du damit GL? Das benutze ich noch nicht. Softhddevice nutzt kein X nur DRM. Von den Treibern die ich benutze bin ich begeistert. Cubietruck und Matrix Treiber haben die Qualität nie erreicht.
Die ARM Kerne sind sehr flott unterwegs. Ich bin schon gespannt was die RK3399 können.
Gruß zille
h265 und uhd wird halt langsam immer interessanter.....
HEVC läuft auf dem Tinker Board. UHD wohl nicht. Kann es aber mangels Hardware nicht testen.
Gruß zille
