softhdcuvid jetzt mit VAAPI und HDR support

Ja AudioStartThreshold * 6 hatte ich schon probiert. Das Problem ist das beim starten einer Aufnahme von der Platte der VDR die Puffer so voll pumpt das das auch nix nützt.

Der Decoder ist nicht zu langsam es wird ja alles in HW dekodiert. Nur es müssen ja auch Video Frames kommen die man wegwerfen könnte, Meistens reicht es ja auch aus ein Frame zu verwerfen. Nur ich habe festgetellt das die PTS differenz zwischen Video und Audio doch immer mal wieder wackelt. UNd dann kommt es dazu das ein Frame verworfen wird nur um gleich das nächste wieder zu verdoppeln. Evtl. liegt es ja wirklich am Audio und dein Mutex verbessert es. Bin gespannt ob du Erfolg damit hast. Dann übernehme ich es

Zitat von zillerbaer

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 warte dann mal auf dein GIT

Habe etwas mit dem AudioStartThreshold rumgespielt und bei AudioStartThreshold * 10 läuft Audio nicht unkontrolliert los bei starten einer Aufnahme und dann schafft es auch AudioVideoReady das sinnvoll zu starten. Danach ist Video leicht vor dem Audio (pts diff ist positiv) und } else if (diff > 55 * 90) { hält das auch so im positiven. Damit funktioniert es ganz gut. Zur sicherheit habe ich mal ne Routine zum einfügen von Stille gemacht um zu sehen ob das dann noch zuschlägt im laufe der Zeit. Ich probiere das erst mal hier aus um zu sehen das es klappt.

Zitat von Hibbelharry

Ich hab mir die Tage für mich eine neue KIste mit Ryzen APU zusammengebastelt, und wollte mir das aus Interesse mal ansehen. Im Moment geht das Plugin nur leider nicht durch meinen Compiler auf Ubuntu 19.10. Neben einigen Warnungen gibt das hier einen harten Fehler:

Code

video.c:542:10: error: conflicting types for 'gettid'
  542 | uint64_t gettid()
      |          ^~~~~~
In file included from /usr/include/unistd.h:1170,
                 from video.c:68:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' was here
   34 | extern __pid_t gettid (void) __THROW;
      |                ^~~~~~

Ubuntu Eoan (19.10) bringt glibc 2.30 mit, ab der gettid eine eigene Deklaration darin hat. Soweit ich das überblicke ist der Fix recht simpel, ich hab gerade fix einen Pull Request gemacht, der das lösen müsste.

Du kannst das gettid in video.c einfach rauswerfen.

Habe nun nochmal einen Fix für das springen in den Aufnahmen eingecheckt. Und für die CUVID Leute ist nun auch mal etwas dabei: Das Bufferhandling wurde überarbeitet und sollte nun deutlich besser laufen.

Derzeit sieht es so aus also ob beim vaapi alle skin Plugins nicht sauber laufen. Ich habe mal mit dem skindesigner getestet und da gibt es Problme beim Skin umschalten (ansonsten läuft es wohl). Den Skinflatplus habe ich nicht aber ich denke der läuft auch nicht. Das könnte daran liegen das ich auf egl umgestellt habe und die Skins die GL Texturen nicht im richtigen EGL Kontext erstellen. Das schaue ich mir nochmal an. Derzeit ist LCARS angesagt

Als Last Resort beim a/v sync schiebe ich nun Stille ins Audio. Wem das auffällt der sollte sich melden. Eigentlich sollte das im normalbetrieb nicht gebraucht werden.

mfg

jojo61

PS: habe noch etwas für den skindesigner nachgeschoben

PIP geht mit VAAPI derzeit nicht. Ich habe mal rumgespielt und finde den Fehler nicht. Könnte aber am FFMEPG liegen. Irgendwie scheint der Vaapidecoder nicht mitzukriegen wenn ich eine Instanz zu und wieder auf mache. Danach beschwert er sich das ich die falschen SurfaceIDs übergebe.

mfg

jojo61

So ich habe noch eine Korrektur für DETA und ATTA eingestellt. Dabei habe ich auch versucht das Umschaltverhalten zu verbessern.

Viel Spaß

jojo61

zork Ich habe deinen pull request akzeptiert. Ich habe nichts dagegen wenn du weitere Bereinigungen machst. Du solltest mich nur darauf hinweisen weil ich nicht immer im github schaue ob da etwas ansteht,

Ich entwickle das plugin weiter und habe mal auf einem Raspi 4 getestet. Das hatte ich ja oben schonmal angedeutet. Mittlerweile läuft das plugin dort auch rudimentär. Nur leider unterstützt ffmpeg auf dem Raspi 4 noch nicht den hevc decoder und deswegen habe ich das erstmal beiseite gelegt und hoffe ffmpeg wird da noch etwas tun. Daneben habe ich untersucht wie ich HDR bei Intel aktivieren kann. Das scheint mir derzeit nur über die drm Ausgabe ohne X zu gehen. Da bastele ich gerade dran rum und versuche erst mal das drm plugin von Zille auf dem NUC zum laufen zu bringen. Da Intel HDR aber nur für Gen10 Grafiken eingebaut hat fürchte ich das ich dazu auch noch den Kernel patchen muss. Das bleibt spannend Zumindest soll YCrCb 420 aber auch mit Gen9 und LSPCON gehen. Das würde für HDR ja reichen.

jojo61

jsffm Bei mir funktioniert hevc_v4l2m2m gar nicht. Zumindest decodiert er nichts. Ob das nun hardware decoding ist oder nicht ist mir erst mal egal.

Kodi liefert ja m.E. mittlerweile sein eigenes ffmpeg mit. Da könnten anpassungen drin sein. Da habe ich aber noch nicht reingeschaut.

Da ich für den Raspi wohl eh drm Ausgabe brauche werde ich erst mal daran weiterarbeiten.

jojo61

Zitat von zillerbaer

softhddevice-drm läuft aktuell auf Raspi (Raspi 4 wohl nicht mehr) und Rockchip. Die Unterstützung von einem NUC ist aktuell nicht vorgesehen. Das Konzept ist das die Video Wiedergabe über DRM passiert ohne X-Server. Die Ausrichtung sind die ARM Devices.

Das ist mir vollkommen klar das dein Plugin nicht für einen NUC gedacht ist. War auch keine Kritik an dem Plugin. Ich werde aber wohl eine drm Ausgabe für HDR am NUC brauchen und da ist dein Plugin eine prima Quelle für Infos wie es geht

hopsi Ich schaue mir das mit den Schnittmarken mal an. Hast du die aktuelle Version ?