[VDR 2.8.3] Schneller umschalten

Hallo kls ,

beim Messen der Umschaltzeiten bin ich auf zwei Stellen in device.c gestoßen, die unnötig Zeit kosten. Der Patch dazu hängt an und ist klein.

1. Der Transfer-Player wird zu spät angehängt. SetChannel() startet ihn, einhängen tut ihn aber erst die Hauptschleife im ncäshten Durchgang. Bis dahin wirft cTransfer::Receive() alles weg. Je nachdem, was die Hauptschleife gerade treibt, sind das 300–900 ms, zum Beispiel beim Zeichnen der Kanalanzeige oder bei SVDRP beim Schlafen in cRemote::Get().

Bei SVDRP CHAN gibt's obendrauf ein doppeltes Umschalten: HasProgramme() sieht den gestarteten, aber noch nicht eingehängten Player und denkt, es läuft nichts. Also schaltet die Hauptschleife gleich noch mal auf denselben Kanal.

Die Lösung ist ein cControl::Attach() direkt nach dem Launch(). Deine Reihenfolge aus 2.8.3 bleibt dabei, wie sie ist, und für einen schon eingehängten Player tut Attach() einfach nichts.

2. Der TS-Puffer wacht zu selten auf. cTSBuffer weckt den Leser erst ab 10 % Füllstand. Das erreicht Live-TV so gut wie nie, also greift jedes Mal der 100-ms-Timeout. Mit 10 ms geht's flotter, und mehr CPU-Last war nicht messbar.

Messwerte: Beim Umschalten per SVDRP, Web-Oberfläche oder epgsearch sind die ersten Videodaten im Schnitt rund 0,6 s früher beim Ausgabegerät, auf demselben Transponder nach 155 statt 816 ms. Beim Umschalten per Fernbedienung sind es rund 85 ms, weil dort meist Tuner oder CAM das Tempo bestimmen.

vaapivideo macht Punkt 1 schon seit 1.9.0 per cStatus::ChannelSwitch()-Hook, und softhddevice-drm-gles ( rell) zieht gerade nach. Im Core wäre das für alle Ausgabe-Plugins erledigt, und wir könnten unsere Workarounds wieder rauswerfen.

Was meinst du?

Quote from Dr. Seltsam

Hallo zork ,

der Teil 1 des Patches hat leider eine unerwünschte Nebenwirkung beim iptv-Plugin.

Schaue ich mir an, das Plugin kann ich hier auch testen.

Quote from Dr. Seltsam

Hallo zork ,

der Teil 1 des Patches hat leider eine unerwünschte Nebenwirkung beim iptv-Plugin.

Die Nebenwirkungen kommen aber von iptv, schau mal in den Thread.

Quote from kls

Auf meinem Raspberry Pi 5 mit softhddevice-drm-gles v1.6.8-unknown und satip v2.4.1 merke ich damit keine spürbare Beschleunigung des Umschaltens, was aber auch an SatIp liegen könnte. Auf dem Wohnzimmer-VDR mit softhddevice v1.0.14 und direktem Sat-Empfang mittels DigitalDevices-Tunern ging das Umschalten auch vorher schon schnell, gefühlt geht es mit diesem Patch vielleicht noch einen Tick schneller.

Dass du fast nichts merkst, liegt daran, wie umgeschaltet wird.

Gemessen mit vaapivideo-Tracing (-t), Durchschnitt über eine Serie von Umschaltungen per svdrpsend. Gleicher Transponder, 2.8.2 → 2.8.3 mit Patch: receiver thread ended 87 → 31 ms, erstes Video-PES 207 → 114 ms. Keyframe und CRTC lasse ich weg, die schwanken je nach GOP-Phase um hunderte ms.

Die 0,6 s gibt es, wenn die Umschaltung von außen kommt (SVDRP, live, Timer) — dann hängt der Transfer-Player bis zum nächsten Durchlauf der Hauptschleife, und solange wirft cTransfer::Receive() alles weg. Mit der Fernbedienung ist das anders, da bleiben ~85 ms aus dem TS-Buffer-Timeout, das merkt man wahrscheinlich nicht.

Bei einem Transponderwechsel dominiert sowieso das Tunen (erstes PES 865 → 840 ms), bei dir auf dem Raspberry kommt noch der RTSP-Aufbau dazu. Am besten merkt man es auf lokalen DVB-Karten.

Zusammengefasst: kleine Änderung, kostet zur Laufzeit nichts, bringt richtig was, wenn von außen geschaltet wird (ein Durchlauf der Hauptschleife weniger). Würde mich freuen, wenn du die Änderungen übernimmst.