Posts by jojo61

    Hallo,

    im aktuellen git kommt es beim deta zu diesem Fehler und Absturz VDR,

    Code
    1. checkCudaErrors() Driver API error = 0219 "CUDA_ERROR_INVALID_GRAPHICS_CONTEXT" from file <video.c>, line 1602.

    Ja stimmt und mit placebo geht es auch nicht mehr. Ist wohl kaputt gegangen beim umstellen auf egl. Da schaue ich mal nach.


    mfg

    jojo61

    Murry ja ich denke den opengl patch kann man allemein im skindesigner aufnehmen. Ich hatte nur Fehler in der Reihenfolge von close und delete von OSDs gefixt. Das sollte überall richtiger sein.


    Aber ganz sauber ist der skindesigner damit noch nicht. Es gibt immer noch abstürze mit dem softhdcuvid.


    mfg

    jojo61

    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

    Code
    1. video: fatal i/o error

    Wenn du das im Log hast dann gab es einen fatalen Fehler mit dem Window und das Plugin stellt seine arbeit ein.

    Könnte schon sein das cecremote da mit hineinspielt. Versuche es halt erst mal ohne zusätzliche Plugins. Dann kannst du es besser einkreisen.


    mfg

    jojo61

    avak Ehrlich gesagt versteh ich nicht was bei dir Faul ist. Er stürzt beim kreieren der GL Texturen ab. Genauer gesagt beim Versuch die Texturen an CUDA bekannt zu geben. Das ist also ein Problem mit der installation des NVIDIA Treibers. Nur welches kann ich dir so nicht sagen.

    Versuch mal einen anderen Treiber 430.xx oder so.


    sorry wenn ich da nicht weiter komme


    jojo61

    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

    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
    1. video.c:542:10: error: conflicting types for 'gettid'
    2. 542 | uint64_t gettid()
    3. | ^~~~~~
    4. In file included from /usr/include/unistd.h:1170,
    5. from video.c:68:
    6. /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' was here
    7. 34 | extern __pid_t gettid (void) __THROW;
    8. | ^~~~~~


    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.

    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.

    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 :-)

    zillerbaer Ja mir ist schon klar das beim starten Audio weggeworfen wird und dann alles syncron bleiben sollte. Das ist aber nicht immer der Fall. Ich habe manchmal den Effekt das Audio schon losläuft bevor das erste Videoframe kommt. Das Passiert wenn schon Audio geliefert wird und die Schwelle zum starten überschritten wird: AudioStartThreshold * 4 < n in AudioEnque. Damit kommt dann der eigentliche Audio start in AudioVideoReady zu spät und es wird da auch nix mehr verworfen weil AudioRunning schon gesetzt ist. Das hatte ich zwar abgeschaltet aber es nutzt nix weil ich da Audio verzögern müsste. Da ist dann skip negativ. Das kommt daher das Video zu spät ist und ich dann entweder Video Frames verwerfen muss oder Audio "stille" einschieben muss. Zum Video verwerfen habe ich aber keine Frames im Puffer also müsste Audio Stille eingeschoben werden. Und das gibt es derzeit halt noch nicht.


    Das ganze passiert auch im laufenden Programm wenn der Audiotakt leicht zu schnell ist. Da alles auf Audio syncronisiert wird, muss man dann Video Frames verwerfen um hinterher zu kommen. Nur müssen dafür auch Frames da sein.


    Ich hoffe du siehst nun warum ich stille einfügen möchte.


    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.

    jrie Ja da sind wir uns einig das da ein Designproblem vorliegt. Audio wegwerfen ist einfach. Aber das ist nur nötig wenn das BIld vor läuft.

    Das ist eher selten der Fall und wir durch duppen von Bildframes behoben. Das geht recht stabil.


    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 ?

    Hallo

    das ganze verstehe ich auch nicht. Bei mir sieht das so aus. Warum bei die die cudart nicht genutzt wird ist mir ein Rätsel.

    Wohin zeigt den die libcudart.so bei dir. Das ist doch ein Symlink.

    Ich habe nun mal einen fix eingecheckt und hoffe damit geht es wieder. Nur leider sind damit dann wieder die a/v sync Probleme da.

    Das Problem ist das der Ton zu früh losläuft und dann das Bild den Ton nicht mehr einholen kann. Deswegen hatte ich es so prgrammiert das

    der Ton erst dann loslaufen darf wenn das erste Frame vom Bild kommt. Das killt dann aber Radio. Den Ton zu verzögern ist gar nicht so einfach.

    Den Thread einfach anhalten bringt nichts weil dann das Audiodevice eine Bufferunderrun bekommt und damit die Sync auch futsch ist. Also müsste ich stille "einschleusen" und das ist gar nicht so einfach je nachdem ob es AC3 oder Stereo gerade läuft.

    Im Original PLugin wird dann einfach ein Frame verworfen um wieder näher an den Ton heran zu kommen. Aber irgendwie klappt das nicht immer weil gar nicht genug Frames zum verwerfen da sind. Da muss ich wohl nochmal nachdenken was ich da tun kann.


    jetzt ist es zumindest erst mal wieder so wie vor meiner Änderung. Hoffe es hilft.

    sg75 Übersetze mal mit DEBUG. Ich hatte am a/v Sync änderungen gemacht und es könnte daran liegen. Ausserdem habe ich gesehen das bei einigen SD Sendern kein PTS kommt.


    Haben denn die Radio Sender irgendein Bild oder kommt da wirklich nur Ton ? Derzeit muss unbedingt ein Bild kommen bevor der Ton aktiviert wird. Da könnte das Problemliegen.

    Hallo zusammen,
    ich verfolge hier die Entwicklung und frage mich ob es irgendwelche qualitativen Vorteile bietet (außer UHD) die Ausgabe von Yavdr Ansible (Standardinstallation) auf meinem Gemini Lake Intel System auf das Ausgabeplugin aus diesem Thread umzustellen...
    Vor allem: Sind die letzten Versionen alltagstauglich?

    Man sagt zwar "Never Change a Running System", aber nachdem mein neuer Verstärker jetzt wie mein TV UHD-tauglich ist, juckt es schon ein bisschen wieder zu basteln...

    Das bringt nur etwas wenn die GPU leistungsfähig genug ist mit libplacebo zu skalieren. Ansonsten lohnt es sich nur wenn man UHD haben will.

    Ob der vaapi Teil schon alltagstauglich ist müssen andere hier sagen. Ich nutze derzeit den cuvid Teil im alltag.

    Funktioniert das ganze eigentlich auch mit AMD GPUs?

    Im Prinzip sollte das auch mit AMD funktionieren. Allerdings waren meine letzten Tests mit AMD negativ. Und im Moment habe ich keinen funktionierenden Rechner mit AMD Karte. Wenn sich das VAAPI mit Intel etwas stabilisiert hat dann schaue ich mal wie es mit AMD läuft.

    Die Version ohne libplacebo habe ich mit AMD nicht getestet evtl. geht es damit ja besser.

    Ich hatte doch mal einen patch für den skindesigner veröffentlicht. Hast du denn angewendet ?