Springen auf Schnittmarke

    kls

    Ich bin gerade dabei in meinem Plugin softhdodroid das Audio/Video sync zu verbessern. Dabei habe ich folgendes Problem gefunden.

    Wenn ich im Edit Modus auf eine Schnittmarke springe, dann wird die Marke brav als I-Frame als Stillpicture angezeigt. Danach bleibt das Bild stehen weil der VDR ja dann

    im Pause Modus ist. Wenn ich dann aber den Stream weiterlaufen lasse dann startet der Stream leider nicht an und mit dem I-Frame sonder 2 Frames später (sieht man am PTS).

    Das ist dann aber kein I-Frame und mein Dekoder wartet bis zum nächsten I-Frame bis er wieder ein Bild ausgibt. Damit springt das Bild (es steht ja noch das I-Frame von der Schnittmarke an)

    und der Ton muss auch erstmal neu syncronisiert werden. Besser wäre es mit dem I-Frame der Schnittmarke den Stream loslaufen zu lassen.


    Ist meine Beobachtung richtig und ist das gewünscht das der Stream dann mit eine B- oder P-Frame losläuft ? Oder verliere ich hier irgendwo 2 Frames, der Stream startet ja mit einem Clear.

    Zumindest mit den Devices, die ich bisher verwendet habe (dvbsddevice, dvbhddevice, rpihddevice, softhddevice) war das nie ein Problem.

    Wenn du den I-Frame nach der Pause nochmal haben möchtest, könnte es vielleicht helfen, in dvbplayer.c in cDvbPlayer::Goto() die Zeile


    playMode = pmStill;


    in


    readIndex = Index - 1;


    zu ändern.

    Wenn der Code angeschaut wird, könnte ja gleich tiefer untersucht werden. Wenn PlayVideo das erste Mal nach Playmode == 0 aufgerufen wird, kommt regelmässig kein I-Frame. Unter MPEG war das kein Problem. Da gibt es viele I-Frames im Stream. Bei HEVC sind die Abstände aber schon recht groß. Das vergrössert die Umschaltzeiten. Teilweise werden Packete übergeben die nicht mal einen PES start code haben.

    Siehe https://github.com/ua0lnj/vdr-…2Bcuvid/softhddev.c#L2496.


    Unschön ist auch das grosse Packete in Teilen kommen. Es muss immer gewartet werden ob das nächste Packet PTS Daten beinhaltet. Das hat Johns schon dokumentiert: https://github.com/ua0lnj/vdr-…2Bcuvid/softhddev.c#L2708

    Zitat von kls

    probier bitte mal, ob mein Vorschlag bei dir was bewirkt

    Wenn ich deine Änderung mache, dann kommt beim weiterlaufen lassen nach einem Sprung auf eine Schnittmarke jetzt nochmal das I-Frame der Schnittmarke.

    Das ist prima und jetzt gibt es auch keine Bildsprünge mehr. Nur nun tritt ein anderes Problem auf: An einigen Schnittmarken läuft der Stream dann nicht ab der Schnittmarke los an der er steht sondern an der nächsten Schnittmarke. Das ist natürlich dann nicht ok. Da muss wohl doch noch mehr geändert werden.


    Im übrigen muss ich mich Zillerbaer anschliessen. es wäre besser wenn alle Streams mit einem I-Frame beginnen würden. Das wird von den Codecs zwar eh so erzwungen, aber dann ist schon jede Menge Audio vorhanden was zu entsorgen ist bevor AV Sync erreicht ist. Und da der VDR ja eh die Streams analysiert um die I-Frames für die Index Datei zu finden wäre es super wenn das so implementiert werden könnte.

    Ich habe das jetzt mit softhddevice probiert und kann auch bestätigen, dass mit dieser Änderung die Wiedergabe nach dem Anspringen einer Schnittmarke sauber an exakt dieser Stelle losläuft. Vorher war es tatsächlich so, dass teilweise der Ton schon lief und das Bild eine zeitlang stillstand, oder das Bild sofort weiter nach hinten sprang. Ich gehe also davon aus, dass diese Änderung richtig und wichtig ist und auch auf allen Devices positiv wirken dürfte.

    Zitat von jojo61

    Nur nun tritt ein anderes Problem auf: An einigen Schnittmarken läuft der Stream dann nicht ab der Schnittmarke los an der er steht sondern an der nächsten Schnittmarke.

    Das konnte ich nicht nachvollziehen. Kannst du ein Testbeispiel zur Verfügung stellen, bei dem das auftritt?


    Anbei der Fix als Diff.

    Zitat von zillerbaer

    Wenn PlayVideo das erste Mal nach Playmode == 0 aufgerufen wird, kommt regelmässig kein I-Frame.

    Falls der Fix vdr-2-6-0-fix-dvbplayer-diff dieses Problem nicht behebt, kannst du mir bitte sagen, was genau ich tun muss, um es zu reproduzieren?

    Zitat von zillerbaer

    Unschön ist auch das grosse Packete in Teilen kommen.

    PlayVideo() sollte eigentlich immer vollständige PES-Pakete bekommen. Wann ist das denn nicht der Fall?

    Zitat von kls

    Das konnte ich nicht nachvollziehen. Kannst du ein Testbeispiel zur Verfügung stellen, bei dem das auftritt?

    Ich habe ein wenig suchen müssen bis ich drauf kam. Ich habe ein Testvideo mit 4 Schnittpunkten. Vom 1. bis zum 2. und vom 3. bis zum 4. ist damit dann der Film.

    Wenn ich nun zum 1. Springe läuft der Film dort normal los. Wenn ich aber zum 2. Springe dann läuft der Film los und springt sofort zum 3. Schnittpunkt weil er ja die "rausgeschnittenen" Teile bei der wiedergabe überspringt. Das passiert nur mit deinem Patch weil er ohne den Patch ja schon nach dem Schnittpunkt losläuft und deswegen gar nicht bemerkt das er springen müsste.

    Wenn ich das überspringen der rausgeschnittenen Teile im Setup abschalte dann funktioniert es auch an der 2. Schnittmarke. Aber ich denke es wäre evtl. besser im Edit Modus dieses Überspringen abzuschalten. D.h. wenn das OSD mit den Schnittmarken aktiv ist nicht zu springen.


    PS: Was zillerbaer wohl meint ist das beim umschalten auf einen anderen Kanal (also von PlayMode 0 auf PlayMode 1) der neue Stream dann i.d.R. nicht mit einem I-Frame beginnt.

    Zitat von kls

    Ich gehe also davon aus, dass diese Änderung richtig und wichtig ist und auch auf allen Devices positiv wirken dürfte.

    Für die TT6400 kann ich bestätigen das sich diese Änderung positiv auswirkt.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Gefällt mir 1
    Zitat von jojo61

    Was zillerbaer wohl meint ist das beim umschalten auf einen anderen Kanal (also von PlayMode 0 auf PlayMode 1) der neue Stream dann i.d.R. nicht mit einem I-Frame beginnt.

    Ja, bei live TV, Aufnahme Wiedergabe, Pause in Widergabe, etc..

    Zitat von kls

    Falls der Fix vdr-2-6-0-fix-dvbplayer-diff dieses Problem nicht behebt, kannst du mir bitte sagen, was genau ich tun muss, um es zu reproduzieren?

    Auch mit vdr2.6.0 + vdr-2-6-0-fix-dvbplayer-diff wir nur per Zufall mit einem I-Frame begonnen. Ich loge im softhddevice-drm die Packete ab start und ob es ein i-frame ist. Hier ein Bsp. für H264:


    und Mpeg2:

    Zitat von kls

    PlayVideo() sollte eigentlich immer vollständige PES-Pakete bekommen. Wann ist das denn nicht der Fall?

    Das ist immer der Fall. Es kommen bei Wiedergabe regelmässig unvollständige Packete:

    Edit: In softhddevice-drm schaue ich ob ein PTS im Header steht. Wenn es einen Pts gibt ist es ein neues Packet.

    Zitat von jojo61

    Wenn ich nun zum 1. Springe läuft der Film dort normal los. Wenn ich aber zum 2. Springe dann läuft der Film los und springt sofort zum 3. Schnittpunkt weil er ja die "rausgeschnittenen" Teile bei der wiedergabe überspringt. Das passiert nur mit deinem Patch weil er ohne den Patch ja schon nach dem Schnittpunkt losläuft und deswegen gar nicht bemerkt das er springen müsste.

    Das verhält sich bei mir auch so, aber unabhängig von diesem Patch. Wenn "Setup/Replay/Pause replay when jumping to a mark" auf "no" steht und "Skip edited parts" auf "yes", dann verhält es sich so - auch schon vorher.

    Zitat von zillerbaer

    Ja, bei live TV, Aufnahme Wiedergabe, Pause in Widergabe, etc..

    Bei "Pause in Wiedergabe" wird lediglich dem Device gesagt, dass es "anhalten" soll. Die Daten werden ohne besondere Behandlung geschickt, sie sollten also beim Device mit oder ohne Pause genau gleich ankommen.


    Bei "live TV" wird das, was vom Sender kommt, sofort und ohne weitere Behandlung an das Ausgabedevice geschickt, auch um möglichst schnelle Umschaltzeiten zu erhalten.


    Bei der Wiedergabe einer Aufnahme sollte es eigentlich immer mit einem I-Frame losgehen, denn die Aufnahme startet ja erst bei einem I-Frame. Vorher kommt allerdings immer eine PAT/PMT - vielleicht meinst du das?

    Zitat von kls

    Bei "live TV" wird das, was vom Sender kommt, sofort und ohne weitere Behandlung an das Ausgabedevice geschickt, auch um möglichst schnelle Umschaltzeiten zu erhalten.

    Leider werden dadurch die Umschaltzeiten eher länger. Der decoder wirft eh alles weg bis zum ersten I-Frame aber das Audio muss zusätzlich noch aufwändig neu syncronisiert werden. Weil das ja auch noch zu entsorgen ist was vor dem I-Frame kommt.



    Zitat von kls

    Wenn "Setup/Replay/Pause replay when jumping to a mark" auf "no" steht und "Skip edited parts" auf "yes", dann verhält es sich so - auch schon vorher.

    Bei mir war das ohne den patch anders, aber ist auch egal und mit dem Patch ist es definitiv wichtiger das es sauber anläuft.

    Zitat von zillerbaer

    Es kommen bei Wiedergabe regelmässig unvollständige Packete:

    Das Längenfeld im PES-Header ist 16 Bit groß, ein PES-Paket kann also maximal 65535 Byte lang sein. Wenn längere Pakete (ohne Läagenangabe) kommen, dann teilt VDR sie in Pakete mit maximal dieser Größe auf, damit sich das Ausgabedevice auf das Längenfeld verlassen kann.


    Wenn du magst, kannst du ja mal *cTsToPes::GetPes() so ändern, dass es ein PES-Paket mit leerem Längenfeld (!PesHasLength(data)) komplett zurückgibt. Der Parameter &Length ist ja 'int' und kann das verkraften. Die Frage ist halt, ob alle Ausgabedevices mit PES-Paketen ohne Längenangabe zurecht kommen.

    Zitat von kls

    Vorher kommt allerdings immer eine PAT/PMT - vielleicht meinst du das?

    Ja, bei Wiedergabe ist immer nur ein Packet vor dem I-Frame.

    Zitat von kls

    Die Frage ist halt, ob alle Ausgabedevices mit PES-Paketen ohne Längenangabe zurecht kommen.

    Die Sichtweise ist immer noch die der alten FF-Karten. Die modernen Ausgabeplugins müssen dadurch den Stream noch einmal parsen. Diese Informationen sind in vdr aber schon vorhanden und sollten an das Ausgabeplugin übergeben werden. Das ist doppelte Arbeit und Rechenzeit. Den Umgang mit dem Stream sollte vdr machen und die Ausgabeplugins erhalten das komplette Datenpacket mit Format, Höhe und Breite. Das geht in diesem Thread aber zu weit.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden