softhdcuvid jetzt mit VAAPI und HDR support

    Zitat von tecfreak

    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.

    Zitat von Grillbert

    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.

    Ich habe das aktuelle git vom sofhdvaapi (ohne libplacebo) mal auf meinem Nuc (Broxton laut vaainfo) und vanilla VDR 2.4.1 getestet.

    Erst hat es Deadlocks bei fast jedem Umschalten gegeben, aber das lag am streamdev-client. Nachdem ich streamdev von https://github.com/ciminus/vdr-plugin-streamdev/ kompiliert habe, waren die Deadlocks nämlich komplett weg. Das alte softhddevice hat die Deadlocks interessanterweise nicht getriggert.


    HD funktioniert super :)


    SD funktioniert auch gut, aber +/-1 eine Minute springen klemmt fast immer.


    Bei Radio-Sendern gibt es keinen Ton.


    Hier das Log, beim Umschalten auf Radio.

    Und hier das Log, wenn es bei SD-Sendern beim Springen "klemmt". Der VDR ist erst wieder benutzbar, nach dem Log-Eintrag "video: audio/video difference too big"

    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.

    Radiosender haben keine vpid


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    So, hier mit -DDEBUG das Log für einen Radiosender, konkret 1LIVE;ARD WDR:12265:HC34M2S0:S19.2E:27500:0:1101=deu@3:0:0:28475:1:1093:0

    jsffm hat es auf den Punkt gebracht: Radio ==> VPID==0.


    Und hier das Log für die Aufnahme, die beim Sprung +1 Minute hängt:

    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.

    Zitat von jojo61

    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.

    Als ich mich damals intensiv mit softhddevice beschäftigt habe, bin ich auch auf dieses Problem gestoßen und nach vielen Experimenten zu dem Schluss gekommen, dass softhddevice da einen Designfehler hat.

    Das Konzept nur Video "wegzuschmeißen" funktioniert bei softhddevice manchmal nicht.

    Ich glaube, dass es manchmal unerläßlich ist, auch Audio "wegzuschmeißen" (vielleicht reicht Stille einfügen ja auch).

    Andere Player wie z.B. xine machen das auch und haben trotztdem keine Audioknackser.

    Dass bei softhddevice Audio der Taktgeber ist plus der Sync-Mechanismus von softhddevice ergibt in gewissen Situationen ein nicht lösbares Problem.

    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 ?

    Zitat von jrie

    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.

    Zitat von zillerbaer

    Wozu brauchst Du Stille und was willst Du stabilisieren?

    Wenn ichs richtig verstanden habe, ist das Problem, dass Radiosender kein Bild haben.

    Man könnte in dem Fall doch den fehlenden Videostream durch ein "Standbild" ersetzen und dann Bild und Ton gleichzeitig ausgeben, oder?

    Aber ich habs wahrscheinlich nicht richtig verstanden :(

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    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.

    Zitat von jojo61

    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 ?

    Man kann sich das bei xine abgucken.


    Einfache Player nehmen Audio auch als Taktgeber, schlauere Player haben einen eigenen Taktgeber.

    Da bei softhddevice Audio als Taktgeber dient, hat man beim Syncen nur eingeschränkte Möglichkeiten.


    Auch reufer hat in Bezug auf das rpihddevice irgendwo hier mal geschrieben, dass nur über Video zu syncen nicht immer hilft.


    Ideal wäre es, aus softhddevice einen "schlauen Player" zu machen. Nur wer will sich die ganze Arbeit machen ...

    Zitat von jojo61

    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.

    Zitat von jojo61

    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.



    Zitat von jojo61

    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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden