[gelöst] Frames ohne PTS (bitte um Hilfe)

  • Ich baue gerade diverse Prüfungen ein, um Fehler in Aufnahmen zu erkennen. Unter anderem betrachte ich dazu den PTS der Frames. Das klappt bei allen Kanälen, die ich bisher probiert habe, wunderbar (SD, HD, DVB-s, DVB-T, H.264, H.265, UHD). Nur bei RTL (SD, Astra)


    RTL Television,RTL;CBC:12187:HC34M2S0:S19.2E:27500:163=2:104=deu@3;106=deu@106:105;110=deu:0:12003:1:1089:0


    kommen immer wieder Frames, die keinen PTS haben. Es fehlt dann auch genau der PTS-Wert, den man für diesen Frame erwarten würde (es kommt also nicht davor oder danach ein Frame mit diesem Wert). Da ich mal davon ausgehe, dass jeder Frame auch einen PTS haben muss, frage ich mich, wie das sein kann.

    Der beiliegende Patch baut eine Ausgabe ein, wenn ein Frame ohne PTS kommt. Zum Testen eine Aufnahme auf RTL starten und nach kurzer Zeit kommen Ausgaben auf stderr.

    Meine Vermutung ist, dass cMpeg2Parser::Parse() einen Frame irgendwie "zu früh" meldet, und der PTS erst "weiter hinten" liegt.

    Vielleicht hat ja der eine oder andere hier, der sich besser mit den Untiefen von Mpeg2 auskennt, Zeit und Lust sich das mal anzuschauen...

  • Ich bekomme alle paar Minuten bei RTL auch die Meldung "frame without PTS"

    Umgebung Test System: Ubuntu 20.04 im LXC Container, OctopusNet SATIP Server, vdr-plugin-satip, headless vdr 2.5.3 mit o.g. Patch

  • Hast du mal in einer Aufnahme nachgeschaut ? Ich brauche in markad auch die PTS und habe mir mal ein paar RTL Log Files angeschaut und seltsamerweise fehlt es im TS File nicht.

  • VDR kopiert die TS-Pakete ja genau so, wie sie empfangen werden, in die Aufnahmedatei. Ich gehe also mal davon aus, dass der PTS in der Datei ist. Der Fehler liegt vermutlich irgendwo im Bereich cMpeg2Parser::Parse() oder TsGetPts() und davon aufgerufene Funktionen.

  • Ich habe mal die TS Daten mit geschrieben, die dort ankommen, sieht so aus, kein Adaption Field im TS header, direkt Daten, die nicht mit dem PES packet_start_code_prefix anfangen.


  • Fehler gefunden!

    In diesem speziellen Fall folgte auf das erste TS-Paket eines neuen Video-Frames sofort ein (oder mehrere) Audio TS-Paket(e), und erst dann das Video TS-Paket mit dem Picture Start Code. Das führte in cMpeg2Parser::Parse() bei der Abfrage

    Code
          if (tsPayload.AtPayloadStart() // stop at any new payload start to have the buffer refilled if necessary
             || tsPayload.Eof()) // or if we're out of data
             break;

    zum vorzeitigen Abbruch der Schleife, denn AtPayloadStart() reagiert auf jede PID. Wenn ich an dieser Stelle noch abfrage, ob das betreffende TS-Paket zu der gerade bearbeiteten PID gehört und nur dann abbreche, wird auch dieser "Problemframe" richtig erkannt.

    Der Fehler war also schon die ganze Zeit drin, hat sich nur bisher nicht nicht wirklich negativ ausgewirkt.

    Ich werde jetzt AtPayloadStart() so ändern:


    bool AtPayloadStart(void) { return AtTsStart() && TsPayloadStart(data + index) && TsPid(data + index) == pid; }


    Das greift dann auch bei den anderen beiden Parsern, falls dort der gleiche Fall auftreten sollte.


    Danke an alle, die sich das vielleicht mit angeschaut haben.

  • War schwierig zu finden, der code ist nicht einfach komplett zu überschauen.

Jetzt mitmachen!

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