[softhddevice-drm]

    Zitat von rell

    Soweit ich es durchblicke, liegt das eigentliche Problem darin, dass nur 0 oder EAGAIN als Rückgabe von avcodec_send_packet() behandelt werden.

    Genau das soll ja so sein. Bisher wurde jeder Fehler wie EAGAIN behandelt und das kaputte Packet mehrfach zum Decoder geschickt. Jetzt wird bei einem kaputtem Packet dieses Packet verworfen und das nächste Packet genommen. Ist das auch kaputt wird es auch verworfen. Der Decodethread soll weiterlaufen!


    Edit: Kannst Du mal ein bt full machen um rauszukriegen voher das segfault nach Strg-C kommt?

    [softhddevice-drm]

    ist möglicherweise dasselbe. Damals hatte ich mit gdb festgestellt, dass frame hier NULL ist. Die Zeile ist natürlich mittlerweile die 908.

    Falls noch benötigt, mache ich morgen nochmal ein bt.

    Aber das ist doch kein segfault? Ich versuchs nochmal...

    Einmal editiert, zuletzt von rell ()

    Jetzt wirds kompliziert, diesmal ein segfault:

    Sollte passen, auf die gleiche Weise hatte ich es auch gefixt, du warst nur schneller ;)

    Hi zillerbaer ,

    ich habe mal einen branch hochgeladen, der die meisten meiner Probleme löst.

    Der erste Fix versucht mein Problem mit dem FilterHandlerThread in den Griff zu bekommen.

    Der zweite ist ein Fix für folgenden Abbruch, der ab und zu auftauchte:

    Und die letzten beiden sind eher Kosmetik.

    Magst du mal drüber schauen, ob dir das plausibel erscheint?


    Danke Andreas


    PS: Ab und zu verabschiedet sich VDR mit einer Gleitkommazahl Ausnahme. Ich habe es noch nicht mit gdb abgefangen, aber könnte es sein, dass eine Division by zero auch als floating point exception zurückgegeben wird? Da sind nämlich ein paar im Code, wo die 0 nicht abgefangen wird und evtl. ein Problem machen könnte. Aber das ist ganz schwer zu reproduzieren.

    Zitat von rell

    ich habe mal einen branch hochgeladen, der die meisten meiner Probleme löst.

    Das verschlimmbessert nur den Code. Investier die Zeit lieber in Deinen Server, damit der keinen Müll mehr sendet! Wenn ein Frame verlangt einen FB mit size 0 anzulegen stimmt was grundsätzlich nicht und vdr sollte abbrechen. Es wäre interessant unter welchen Bedingungen der Decoder ein Frame mit size 0 ohne Errorcode rausgibt. Das sollte dann in FFmpeg korrigiert werden. Fehler sollten vermieden werden und nicht später abgefangen.

    Zitat von rell

    PS: Ab und zu verabschiedet sich VDR mit einer Gleitkommazahl Ausnahme.

    Das kann ich hier nicht nachvollziehen. Zwei vdr's laufen bei mir im productiv mode. Ich habe aber nur noch 64bit Systeme. Ein core wäre da gut.

    Wie fütterst du deine VDR?

    Am Server könnte ich wohl Zeit investieren, aber da weiß ich gar nicht, wo ich anfangen soll. Der Weg vom Multiswitch über die Sundtek-Sticks, VDR und streamdev-server ist doch ziemlich lang und ehrlich gesagt habe ich noch keine gravierenden Fehler gefunden, die das verursachen. Ich habe "nur" folgende Meldungen im Log, weiß aber nicht, ob die nicht eigentlich "normal" für einen Server sind:

    Ich wüsste auch nicht auf Anhieb, wie ich die abstellen kann. Sollte jemand eine Idee haben, gerne her damit.


    Ich bleibe aber grundsätzlich bei meiner Meinung, dass man auch beim Client - und wenn es streamdev-client nicht macht, dann softhddevice - voraussetzen muss, dass sich VDR nicht gleich verabschiedet - ob jetzt mit segfault oder abort - wenn mal ein Paket kommt, das nicht in die Reihe passt.

    Ohne es probiert zu haben, glaube ich nicht, dass sich z.B. Kodi/vnsi in diesem Fall beenden würde.

    Was passiert z.B. bei schlechtem Empfang (Gewitter)? Ist doch nervig, wenn man den VDR hier immer neu starten muss, wenn mal Schrott dabei war?

    Tatsache ist, dass VDR für mich nicht benutzbar ist, wenn es so bleibt. Ist aber auch kein Problem, da ich mir meine Version halt dann selber patche.

    Wirklich benutzbar ist es auch ohne Abbrüche noch nicht, weil man sich das Bild mit dem Deinterlacer nicht wirklich lange ansehen kann, aber das wird an etwas anderem liegen - verdächtige Logs gibt es hierzu nicht. Ich werde mir jetzt mal meinen H6 aufsetzen und schauen, ob es da besser ist.


    Das alles kann natürlich auch am Code für den Deinterlacer oder an ffmpeg liegen, ist evtl. sogar wahrscheinlich - aber da will ich mich nicht reindenken, und wenn es bei anderen funktioniert ist das doch wieder unwahrscheinlich... Ich prüfe mal, ob es da neue Versionen der Patches gibt.


    Es wäre interessant zu wissen, wieviele Nutzer denn aktuell softhddevice-drm produktiv und mit welcher Hardware im Einsatz haben. Wenn es jemand mit H3 (nahezu) perfekt am Laufen hat, weiß ich wenigstens, dass das Problem irgendwo bei mir liegt.


    Gruß

    Andreas


    PS: Die floating point exception werde ich vorerst mal ignorieren. Die hatte ich bisher 2x, aber wenn ich mich richtig erinnere ist da immer ein segfault oder Abbruch vorausgegangen. Ich würde trotzdem nicht ausschließen wollen, dass irgendwo mal durch 0 geteilt wird, weil fehlerhafte Daten kamen... Ob man sich dafür absichert, ist ein anderes Thema.

    JoeBar

    Solltest du einen VDR mit gles im Einsatz und ein paar Minuten haben, würde mich ein Log mit GL_DEBUG interessieren - am besten mit einem "schwergewichtigen" Skin, z.B. metrixhd oder estuary4vdr. Mich interessieren die Zeiten, die GL so auf einem H6 braucht ;)

    Danke Andreas

    Zitat von rell

    Wie fütterst du deine VDR?

    Der Haupt VDR mit Rockpro64 hat eine DD Cine angestöpselt. Alle Clients werden von dem über streamdev versorgt. Der Client im Arbeitszimmer basiert auf einem AW H5. Der ist weitgehend baugleich mit dem H3. Unterschiedlich sind nur die 4 ARM Kerne.

    Zitat von rell

    Was passiert z.B. bei schlechtem Empfang (Gewitter)?

    Im Winter hatte ich es hier 2x das auf der Schüssel Schnee lag und kein sauberes Signal mehr kam. VDR ist stehen geblieben ohne Absturz oder Abort. Ich hab mir dann die Weltcup Rennen im Stream auf dem Haupt VDR angesehen. Als die Rennen vorüber waren hat die Sonne den Schnee runterfallen lassen und SAT ging wieder.

    Zitat von rell

    Wirklich benutzbar ist es auch ohne Abbrüche noch nicht, weil man sich das Bild mit dem Deinterlacer nicht wirklich lange ansehen kann,

    Der Deinterlacer arbeitet gut sowohl auf Allwinner als auch auf Rockchip und egal ob 576i oder 1080i. Das Problem bei Dir sind die kaputten Packete. Über die Logs kann ich nicht viel sagen. Die Meldung "changing pids" hab ich auch den Rest kenne ich nicht.


    Wie gesagt wäre es interessant rauszubekommen warum bei Dir AVFrames auftauchen die size 0 haben und FFmpeg keinen Errorcode rausgibt. Da kann ich hier aber wenig helfen da ich hier keine solchen Packete habe. Ich hatte schon mal gefragt ob das auch bei Aufnahmen so ist? Wenn ja kannst Du mir mal ein Schnipsel zur Verfügung stellen?

    Zitat von zillerbaer

    Wie gesagt wäre es interessant rauszubekommen warum bei Dir AVFrames auftauchen die size 0 haben und FFmpeg keinen Errorcode rausgibt. Da kann ich hier aber wenig helfen da ich hier keine solchen Packete habe. Ich hatte schon mal gefragt ob das auch bei Aufnahmen so ist? Wenn ja kannst Du mir mal ein Schnipsel zur Verfügung stellen?

    Ich schau mir meine Aufnahmen mal an bzw. mache eine neue.

    rell ich setz mich heut Abend mal dran, jetzt muss ich mich erst mal nahrungstechnisch für's Wochenende rüsten ;)

    rell Ich hab die version 3 heute nochmal gelöscht und neu runtergeladen und mit GL_DEBUG kompiliert und Dir das syslog unten angehängt.

    Kann es sein, dass sich da was verändert hat? Im Hauptmenü von metrixhd färbt der Menübalken jetzt alles blau anstatt wieder nach dem darüberschalten transparent zu werden.

    Dateien

    syslog7.zip 186,73 kB – 87 Downloads

    Das mit dem Menübalken hab ich auch schon gesehen, ich schaus mir an aber scheint lösbar. Danke fürs log, schaut gut aus! Werds später mal mit lima vergleichen.

    Die Zeiten, die die Mali400 benötigt sind gar nicht sooo viel langsamer. Obwohl panfrost im Ganzen schon schneller scheint.


    JoeBar Kannst du noch sagen bzw. mit welchem git Stand das mit dem blauen Menübalken noch funktioniert hat? Falls nicht, wäre ein bisect cool.

    Kann ich aber auch selber machen, dauert nur ein bißchen, bis ich dazu komme...


    EDIT: Bist du dir sicher, dass der Bug neu ist und nicht immer schon mit GL so war? Hier taucht das bereits im ersten GL commit auf. Ich schau mir mal an, was da alles gemacht wird. Ich vermute, mit CPU Osd ist das nicht so ;) ?


    Gruß

    Andreas

    Einmal editiert, zuletzt von rell ()

    Ich dachte, dass es mal funktioniert hat aber vielleicht war das eben beim CPU OSD.

    JoeBar Probier mal https://github.com/rellla/vdr-…m/tree/drm-atomic-v4-gles

    In der "Trockenübung" funktionierts.


    Gruß

    Andreas

    Beim kompilieren bekomm ich das hier

    hm bei gestoppten VDR läuft es ohne Speicherzugriffsfehler durch ??? Hatte ich so vorher jetzt noch nie.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden