Hallo jojo61,
ich möchte hier einen Patch (gegen den aktuellen git-Stand) vorstellen, der primär das Umschaltverhalten betrifft. Im aktuellen Stand ist die Geschwindigkeit ohne FastSwitch ja deutlich verbessert, aber was dabei fürchterlich nervt ist, dass es regelmäßig immer mal wieder beim Umschalten den Effekt gibt, dass das Bild für einen Moment viel zu schnell läuft. (Es ist das gleiche Phänomen, dass -unabhängig vom FastSwitch- auftritt, wenn man aus dem Standbild die Zeitlupe vorwärts aufruft und wieder auf Play (Normalgeschwindigkeit) geht. Man kann das mit FastSwitch auchgut reproduzieren, wenn man auf einen Radiokanal geht, einen Moment wartet und noch bevor Ton kommt wieder auf einen TV-Sender wechselt).
Noch ungeklärt ist, warum das unter VDR*ELEC sehr viel häufiger beim Umschalten auftritt als in einer chroot-Umgebung. Mit aktiviertem FastSwitch hat man hingegen das Problem, dass das Bild zwar sehr schnell da ist und anläuft, dann aber stehen bleibt und auf A/V-Synchronität wartet, ehe es weiter läuft. Das nervt auf Dauer auch gewaltig. Also habe ich nach einem Weg gesucht, das zu verbessern.
Der anliegende Patch macht mehrere Sachen:
- In der audio.c wird in AudioEnque ein Bug beseitigt: Die Auskommentierung für skip = AudioSkip; betrifft m.E. nur das Umschalten ohne FastSwitch. Hingegen wird FirstVPTS an mehreren Stellen in video.c verwendet und sollte deshalb m.E. auch für aktivierten FastSwitch auf 0 gesetzt werden.
- Für das Schwarzschalten während des Kanalwechsels kehre ich zurück zur black policy, die jetzt aber ohne Zeitverzögerung sofort anspringt. Das jeweils richtige Setzen (schwarz oder letzter Frame) wird anhand des PlayModes ermittelt und in amlReset() berücksichtigt. Der amlogic-Parameter disable_video wird zum Umschalten nicht mehr benötigt. Gleichwohl muss er offenbar nach jedem Schließen des devices explizit erneut auf 0 gesetzt werden (macht Kodi auch so). Ich meine, dass die black policy einen Tick schneller funktioniert, wenn es darum geht, den neuen Stream wieder einzublenden. Ein weiterer Vorteil ist, dass -zumindest wenn die letzte Aktion keine Wiedergabe war- das Bild auch bei einem ungeordneten Beenden von vdr (Crash oder killall -9 vdr) schwarz wird. Der bisherige Ansatz in StopVideo hat hier nichts bewirkt, da der Code dann gar nicht mehr zur Ausführung kam.
- In der Funktion Trickspeed habe ich zur Klarstellung die speed-Werte je Funktion als Kommentar hinterlegt. (Eventuell kann das stattdessen auch in VideoSetTrickspeed in video.c.)
- Die beiden bools doPauseFlag und doResumeFlag sind m.E. ungenutzt, daher habe ich sie entfernt
- Einigen toten Code habe ich entfernt. AMSTREAM_IOC_CLEAR_VIDEO bewirkt nichts und wird von Kodi auch nicht verwandt. AMSTREAM_CLEAR_VBUF ist schon im 4.9er Kernel in einem Kommentar als nicht mehr vorhanden beschrieben.
- Der Clou ist, dass bei aktiviertem FastSwitch Videodaten in CodecVideoDecode verworfen werden, bis in AudioEnque AudioRunning true ist. Dadurch startet das Bild fertig synchronisiert. Lediglich einen kurzen Schreckmoment braucht es, bis dieses anläuft. Das dauert zwar einen Tick länger als vorher, wirkt aber professioneller und ist immer noch schneller als ohne FastSwitch. Ich habe es auch mit Ausführung von AudioVideoIsReady versucht, aber das Ergebnis war weniger befriedigend. Ebenso die Platzierung - in SendCodecData dauert das Umschalten dann länger. Deshalb habe ich auch den Code für "ohne FastSwitch" von SendCodecData mal in CodecVideoDecode verlegt. Die Logik sagt mir, dass es sinnvoll ist, das so früh wie möglich auszuführen.
- Damit auch die Bildaktualisierung bei StillPicture (Schneiden) funktioniert, musste ich eine neue Variable "inTrickModeStillPicture" einführen. (Beim Schneiden ist weder TrickMode aktiv noch läuft Audio.)
- Anders als in Deinem letzten commit eingebaut habe ich amlSetInt("/sys/module/amvdec_h264/parameters/dec_control", 4); auch für den Kernel 4.9 vorgesehen - analog Kodi.
Wie sagtest Du mal so schön - man kann leicht Opfer seiner eigenen Erwartungshaltung werden . Im Falle des FastSwitch-Umschaltverhaltens bin ich mir sicher, dass es eine Verbesserung bringt. Ohne FastSwitch meine ich, dass es einen Ticken schneller geworden ist. Aber das will ich nicht beschwören.