[softhddevice-drm]

    Zitat von zillerbaer

    Wenn es stottert muss es ja verdoppelte und verworfene Frames geben. Wie sieht es da aus? Hier passiert verdoppeln und verwerfen nur während des Starts und dem Synchronisieren von Audio und Video. Danach über Stunden nix mehr.

    Ist hier auch so. Keine drops oder dupes. Das ist ja das komische. Entweder sind meine Augen so empfindlich, ich weiß auch nicht. Wenn ich es beschreiben müsste, fühlt es sich an, als ob der Deinterlacer die Frames in der falschen Reihenfolge zusammenbaut. Vielleicht mache ich mal ein Video und stells irgendwo ein...

    Bei deinem Branch habe ich noch gelegentliche Drops, wenn OSD aktiv ist bzw. geöffnet wird... aber nicht schlimm. Ich glaube das liegt an dem separatem drm commit.


    Gruß

    Andreas

    Zitat von rell

    Bei deinem Branch habe ich noch gelegentliche Drops, wenn OSD aktiv ist bzw. geöffnet wird... aber nicht schlimm. Ich glaube das liegt an dem separatem drm commit.

    Nein, das liegt daran das das OSD auf der Primary Plane und das Viedeo auf der Overlay Plane dargestellt wird. In dem 20ms Zyklus in dem ein OSD dargestellt wird wird auf der Overlay Plane kein Page Flip gemacht. Das betrifft nur AW, Rockchip nicht.

    Ich teste es nochmal, aber soweit ich mich erinnere habe ich das bei meinen Änderungen und deaktiviertem gles nicht mehr. Melde mich nochmal.

    Zitat von rell

    Wenn ich es beschreiben müsste, fühlt es sich an, als ob der Deinterlacer die Frames in der falschen Reihenfolge zusammenbaut.

    Auf dem H6 fühlt es sich besser an. Ich belasse es erstmal dabei. Ich denke, den kann ich jetzt produktiv nutzen.


    Was mir am Code noch auffällt, ist, dass man evtl. https://github.com/zillevdr/vd…lob/drm/video_drm.c#L1330 so optimieren könnte, dass man die allocs und frees reduziert, da der thread ja eigentlich ständig in EAGAIN läuft. Ich befürchte zwar, das hilft meinem Problem auf H3 nicht weiter, aber evtl. spielts doch mit rein - vorausgesetzt ständiges alloc/free ist hier relativ teuer?! Wahrscheinlich spielts keine Rolle...

    Hast du mal ein printf da eingefügt?

    Hast recht. Ich glaube, das ist den Aufwand nicht wert.

    Ich habe mal bei den beiden usleep nur 5000 gesetzt. Gefühlt ist es dabei etwas besser, kann mich aber auch täuschen.

    An der Stelle ist die Queue danach wichtig. Da muss immer ein Bild drin liegen wenn es gebraucht wird. Die Queue ist begrenzt auf maximal 3 Bilder. Wenn Du da ein Problem vermutest schau auf den Füllstand der Queue! Ein halbieren der Zeit bringt nur doppelte Last.

    Ich weiß nicht, ob ich da ein Problem vermute. Eigentlich müsste ich doch in jedem Fall einen Framedrop vermeldet bekommen, wenn irgendwas auf dem Weg von DecoderRb->DeintRb->FrameRb verloren geht oder verworfen wird, weil es zu spät dran ist, oder?

    Die Queue hat hier ungefähr jedes 7.-8. Mal wenn der Code vorbeikommt den Füllstand 0 und läuft in das erste usleep(). Aber trotzdem sollte es doch passen, solange kein framedrop geloggt wird?


    PS: Es reicht übrigens, nur einmal zu "schlafen", damit wieder was im Ringbuffer ist. Auch bei usleep(5000). Deswegen steigt die Last also schonmal nicht.

    Zitat von rell

    Ich weiß nicht, ob ich da ein Problem vermute. Eigentlich müsste ich doch in jedem Fall einen Framedrop vermeldet bekommen, wenn irgendwas auf dem Weg von DecoderRb->DeintRb->FrameRb verloren geht oder verworfen wird, weil es zu spät dran ist, oder?

    Ja.

    Zitat von rell

    Die Queue hat hier ungefähr jedes 7.-8. Mal wenn der Code vorbeikommt den Füllstand 0 und läuft in das erste usleep().

    Zitat von rell

    Es reicht übrigens, nur einmal zu "schlafen", damit wieder was im Ringbuffer ist. Auch bei usleep(5000).

    Das Beisst sich! Entweder läuft der Buffer mit vollem Stand oder leer! Wie taktest Du dein SoC? Ondemand? Was ist die niedriegste Frequenz? Es könnt sein das der Buffer voll ist, sleep schaltet und die Taktzahl in den Keller geht. Dann reagiert Dein System zu langsam um in 20ms die nächsten Bilder zur Verfügung zu stellen. Bei Ondemand kann man eine minimal Frequenz schalten. Teste das mal.

    Sorry, ich habe das printf falsch gesetzt. Das hier ist die Ausgabe, wenn ich so patche:

    Sieht das richtig aus? Der governor steht m.E. auf performance.

    Es gibt zwei Queues. Eine vor dem Deinterlacer und eine vor der Anzeige. Du schaust auf die falsche, die vor dem Deinterlacer.

    So sehen die Warteschlangen hier aus. Null ist da nie eine! Die Anzeige Queue ist die wichtigere. Da muss immer mindestens ein Bild sein. Mit 2 bis 3 ist die also immer ausreichend befüllt.


    Worüber reden wir jetzt? Meinen Code oder Deine Abwandlung?

    Das Log ist von meinem, sollte aber nichts ändern. Kannst du mir den Patch schicken, der das Log oben produziert, dann teste ich es hier mit deinem Code und H3 und H6. Wobei der H6 eigentlich gut läuft. Mal sehen, ob man das dann auch am Log sieht. Ich habe das Gefühl, es hat mit der Hardware zu tun...

    Zitat von rell

    Kannst du mir den Patch schicken, der das Log oben produziert

    Wenn ich das so einfüge, habe ich auf H3 auch keine 0. Nur wenn ich es vor das sleep stelle, gibts selbstverständlich mal eine 0.

    Ich schau mir jetzt nochmal den kernel an und dann lass ich es vorerst gut sein. Dann muss es halt der H6 sein.


    EDIT: Falls irgendjemand die Muße und einen H3 hat, kann man das da evtl. gegenchecken...


    Bzgl. der Framedrops mit OSD, die sind weg sobald auf den separaten drm Befehl in VideoOsdDrawARGB() verzichtet und alles in einem Aufwasch in frame2display macht, d.h. ab diesem Commit., hat also noch nichts mit GL zu tun.

    zillerbaer Hier nochmal ein backtrace wegen des Abbruchs bei nicht unterstützem Audio:

    Bis auf meine H3-Bildqualität ist das so ziemlich das einzige Problem, das ich noch habe. Wenn du mal Zeit hast und das ansehen könnstest, wäre super!

    iirc habe ich Probleme, wenn nur ein 1 Kanal da ist oder die Samplerate 24000 beträgt.


    Danke und Gruß

    Andreas

    rell folgendes ist mir mit dem Wechsel auf V5 aufgefallen. Ich teste ja immer noch ob das Schneiden bzw. Schnittmarken verschieben funktioniert, mit den vorherigen Versionen kam immer folgende Fehlermeldung: (Uhrzeit nicht beachten ich bin wieder auf V4 zurück um das zu testen)

    Code
    Mar 15 16:57:46 PineH64 kernel: [ 2971.299087] cma: cma_alloc: alloc failed, req-size: 1024 pages, ret: -12
Mar 15 16:57:46 PineH64 kernel: [ 2971.307492] cma: cma_alloc: alloc failed, req-size: 765 pages, ret: -12
Mar 15 16:57:46 PineH64 kernel: [ 2971.315893] cma: cma_alloc: alloc failed, req-size: 1024 pages, ret: -12
Mar 15 16:57:46 PineH64 kernel: [ 2971.324735] cma: cma_alloc: alloc failed, req-size: 765 pages, ret: -12


    Mit V5 kommt jetzt folgendes...

    Irgendwas hat sich geändert...

    Der einzige Unterschied zwischen den beiden Versionen ist dieser Commit - vorausgesetzt wir reden von den aktuellen Versionen drm-atomic-v4-gles und drm-atomic-v5-gles aus dem Git.

    Deine Meldungen aus v5 habe/hatte ich auch immer mal wieder. Muss fast mal schauen, ob die noch auftauchen.

    Funktioniert denn das Schneiden jetzt?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden