TrickSpeed - Verständnisfrage

  • jrie I would suggest optimizing the code.

    if (audio_clock != (int64_t) AV_NOPTS_VALUE
    && video_clock != (int64_t) AV_NOPTS_VALUE) {
    int diff;
    diff = video_clock - audio_clock - VideoAudioDelay;

    2 times the same code.

    Or make PR, I'll look further myself.

    vdr-2.6.4+(SoftHDDevice GT1030)+ss2 express HD+Behold TV H7+IPTV+PVR150MCE
    https://github.com/ua0lnj/

    Edited once, last by lnj (January 1, 2025 at 4:39 AM).

  • 2 times the same code.

    Yes, I saw it, too. But had not enough time.

    Or make PR

    Done.

  • 2 times the same code.

    In trickspeed and in stillpicture we are in a recording and all data are already available.
    Does that imply it is safe to assume audio clock and video clock have always valid value?
    If so, we could easily simplify the code by putting trickspeed and stillpicture code into that part of xxxSyncDecoder().

  • When you start playing, synchronization occurs immediately, slow playback is used after that. But I have never done video editing, maybe other cases are possible. Is trick speed possible with time-shift recording, or is it the same video playback?

  • it is safe to assume audio clock and video clock have always valid value?

    Not in case of audio only or video only.


    The only possibility I see for deduplication is:

    int calculate_video_audio_diff(void) {
       if (audio_clock != (int64_t) AV_NOPTS_VALUE && video_clock != (int64_t) AV_NOPTS_VALUE) {
           return video_clock - audio_clock - VideoAudioDelay;
       } else {
           return AV_NOPTS_VALUE;
       }
    }

    but I am not sure, if that makes sense.

  • 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.

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • 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...

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • 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?

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

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

    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?

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • 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.

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!