TrickSpeed - Verständnisfrage

Bei RPI-Trickspeed bin ich etwas weiter:

Der decoder für RPI puffert Pakete, bevor er ein dekodiertes Frame ausgibt - bei H264 sind es z.B. mind. 10.
Das ist bei play forward kein Problem. Bei trickspeed aber schon, da man ja eigentlich gleich das erste gesendete haben will. Bei backward trickspeed sortiert der decoder vor der Ausgabe nach pts und spuckt das mit dem kleinsten pts aus, d.h. die Reihenfolge beim Rückwärtslauf stimmt nicht. Der rockchip decoder z.B. spuckt gleich das Frame aus, das zum packet passt und da fällt es nicht auf.

Die richtige Herangehensweise bei ffmpeg wäre, die Ausgabe des Frames zu erzwingen, in dem man direkt nach dem Senden des letzten erforderlichen packets mit einem Null-Packet den End-of-stream signalisiert und das Frame dann abfragt. Danach muss der decoder geflusht werden und es kann weitergehen. Bei rockchip funktioniert der flush, bei rpi (noch) nicht. Da muss aktuell noch der decoder geschlossen und wieder geöffnet werden, was recht teuer ist aber bei trickspeed wahrscheinlich nicht groß auffällt. Man wird das also hinkriegen.

Das ganze setzt aber voraus, dass softhddevice mit den Daten, die von VDR kommen, ein komplettes AVPacket erzeugen kann, das ohne Referenzen auskommt, also ein I-Frame ist.
In den ersten Posts steht schon, dass wir es mit I-Frames zu tun haben und die Stelle im Code müsste https://git.tvdr.de/?p=vdr.git;a=b…01;hb=HEAD#l522

Sicherheitshalber, Frage nochmal an kls , bei Trickspeed ist sichergestellt, dass VDR immer "PTS-weise" Daten für ein komplettes I-Frame schickt?

Nur dann könnte man nämlich ohne weitere Prüfung in softhddevice dieses Paket an den decoder schicken und mit einem End-of-stream die Ausgabe des Frames forcieren, weil der Dekoder es eigentlich ohne ein weiteres Frame verarbeiten können müsste.

Bei mir rennt der Fortschrittsbalken und die Zeit beim Anlaufen der Rückwärtstricksspeed am Anfang zu schnell zurück, bis sie sich nach ca. 1-2 Sekunden einpendelt und auf die richtige Zeit zurückspringt.

Ist das bei euch auch so? Von softhddevice wird für SetCurrent() und SetProgress() m.E. nur GetSTC() benötigt, was es eigentlich richtig machen sollte.

Mich interessiert nur, ob ich der einzige bin, da ich weiß, wo ich suchen muss. softhddevice, skin oder vdr...

kls Hier mal ein Log, das mein Problem mit dem falschen SetProgress vom vorherigen Post zeigt:

https://paste.debian.net/plain/1347052

Das Log hat folgenden Ablauf:

- Abspielen der Aufnahme (DisplayReplay ist angezeigt)
- Freeze
- TrickSpeed slow back
- Freeze

Es werden sowohl SetProgress/SetCurrent vom Skin als auch DeviceGetSTC (=VideoGetClock) vom softhddevice geloggt. GetFrameNumber ist ein Log in https://git.tvdr.de/?p=vdr.git;a=b…01;hb=HEAD#l967

Beim Rückwärtslauf nimmt Current zuerst sehr schnell ab, obwohl vom softhddevice mit GetSTC immer derselbe PTS kommt. Erst nach einer Zeit fängt sich das Ganze. Ich schließe daraus, dass in FindFrameNumber() (oder FindIndex?) irgendwas nicht passt? Hast du eine Idee?

kls Irgendsowas in der Art scheint da nötig zu sein:

diff --git a/dvbplayer.c b/dvbplayer.c
index ea53e396..93c1ce20 100644
--- a/dvbplayer.c
+++ b/dvbplayer.c
@@ -117,7 +117,7 @@ int cPtsIndex::FindFrameNumber(uint32_t Pts)
       if (++i >= PTSINDEX_ENTRIES)
          i = 0;
       }
-  return Valid ? FrameNumber : FindIndex(Pts); // fall back during trick speeds
+  return (Valid && !UnplayedIFrame) ? FrameNumber : FindIndex(Pts); // fall back during trick speeds
 }

FindFrameNumber setzt die FrameNumber auf die letzte gefundene, wenn i = w-1, aber das scheint für trickspeed nicht zu stimmen. Nach meinem Verständnis müsste man da ins FindIndex fallback. Das wird aber nicht erreicht, weil nur gegen Valid geprüft wird, UnplayedIFrames aber (noch) nicht 0 ist. Habe ich das richtig verstanden?

Ich habe das gestern abend mal angetestet und es scheint soweit zu funktionieren. Ob das die beste Umsetzung ist, weiß ich nicht, da habe ich FindFrameNumber und FindIndex noch nicht ausreichend verstanden.

Patch aus #113 tut, was er soll. Und beim #114er kann ich auf die Schnelle den Unterschied nicht erkennen. Er macht jedenfalls nichts böses Danke!

Da muss ich das tatsächlich auch nochmal gescheit testen.

Wenn ich mich richtig erinnere, schickt der VDR beim normalen Play den stream. Der wird bei Pause dann nicht gelöscht und befindet sich als "schon verarbeitet" im Puffer des Ausgabeplugins. Wenn dann jetzt SlowForward kommt, wird mit Empty/DeviceClear alles gelöscht, was schon gepuffert ist, aber VDR schickt die Daten nicht nochmal ab dem Pause-Zeitpunkt, sondern schickt nur die Daten weiter, die noch nicht geschickt wurden. Dann fehlt ein Stück. Ich hoffe, das ist so richtig erklärt.

VDR darf das Empty() eigentlich nur machen, wenn er selbst danach die Daten von der richtigen Stelle sendet, wo der Stream fortgesetzt werden soll. Evtl. mit ResyncAfterPause?

Der Patch ist also (ungetestet) wahrscheinlich nicht richtig.

Ich habe mir mal vor längerer Zeit die Übersicht aus dem Anhang gemacht, da ist der Patch noch nicht drin, würde aber in die pmPause/pmStill Spalte ein DeviceClear bei Forward() und Backward() einfügen, wenn ich es richtig verstehe.