TrickSpeed - Verständnisfrage

rell · Oct 24th 2024

So, auch ich bin wieder einen Schritt weiter. FFMpeg hat leider keine decodierten frames zurückgegeben. Das lag daran, dass ffmpeg durch das vorherige replay die Anzahl der benötigten frames - bevor das fertige ausgegeben wurde - hochgesetzt hat, da schon mal B-Frames aufgetaucht sind. Macht Sinn. Macht aber keinen Sinn, wenn nur I-Frames kommen. ffmpeg liefert dann "no picture", ergo kein frame.

Wenn ich den Decoder aber mit dem ersten gesendeten Trickspeed schließe und einmalig neu öffne, gibt es den ffmpeg-internen Zähler noch nicht, und ich kann dann auch ganz normal packets senden und frames abrufen, ohne auf die gesendet Anzahl der packets zu achten. Den flush nach einem erhaltenen Frame brauchts trotzdem - zumindest beim Rücklauf. Mal sehen, wie ich das alles zusammenbringe. Danach schaue ich mir an, was ihr oben so herausgefunden habt.

Dr. Seltsam · Oct 24th 2024

Quote from jrie

Aber noch nicht auf Nebenwirkungen getestet.

Bei softhdodroid: Pause - Slow forward - Play funktioniert damit. Leider geht die Zeitlupe rückwärts sowie das Spulen vor- und rückwärts nicht mehr (Bild bleibt stehen). Das kann aber auch an den Filmen liegen - Spulen geht von jeher nicht bei jeder h264-Aufnahme. Bei mir reicht schon die Änderung in dvbplayer.c, damit Play nach einer Zeitlupe wieder sauber anläuft.

Der Ansatz ist interessant, ich werde das weiter untersuchen

jrie · Oct 25th 2024

Quote from Dr. Seltsam

Bei mir reicht schon die Änderung in dvbplayer.c, damit Play nach einer Zeitlupe wieder sauber anläuft.

Ist bei mir auch so. Ich hatte alles Verdächtige umgestellt, aber die Änderung in dvbplayer.c reicht.

Quote from Dr. Seltsam

Leider geht die Zeitlupe rückwärts sowie das Spulen vor- und rückwärts nicht mehr

Bei mir geht das.

Diff

--- dvbplayer.c 2024-10-12 13:32:46.000000000 +0200
+++ dvbplayer.c.NEU2    2024-10-24 01:20:03.152487970 +0200
@@ -746,6 +746,8 @@ void cDvbPlayer::Play(void)
         if (!(DeviceHasIBPTrickSpeed() && playDir == pdForward))
            Empty();
         }
+     if (playMode == pmSlow && playDir == pdForward)
+        resyncAfterPause = true;
      DevicePlay();
      playMode = pmPlay;
      playDir = pdForward;

Display More

greift ja auch nur für Play nach SlowForward.

Mit der Änderung geht es auch mit vdr-plugin-xine sowie vdr-plugin-softhdcuvid.

Auch vdr-plugin-xineliboutput geht weiterhin.

Wenn die anderen Player Plugins (dvbsddevice, dvbhddevice, rpidevice, softhdevice-drm und softhdevice-drm-gles) damit auch besser funktionieren bzw. zumindest nicht beeinträchtigt werden, sollte der Patch wohl in den VDR.

Da müsste man mal einen Aufruf zum Testen machen.

Es gibt noch einen kleinen Schönheitsfehler, nämlich je nachdem, wo man nach der Zeitlupe weiterspielt, springt er machmal ein kleines bischen zurück.

Das ist aber viel besser als ohne den Patch, nur nicht ganz perfekt.

jrie · Oct 26th 2024

Quote from jrie

Es gibt noch einen kleinen Schönheitsfehler, nämlich je nachdem, wo man nach der Zeitlupe weiterspielt, springt er machmal ein kleines bischen zurück.

So ist es besser:

Diff

--- dvbplayer.c.orig    2024-10-24 01:35:48.046359743 +0200
+++ dvbplayer.c.NEU4    2024-10-26 01:22:33.452430346 +0200
@@ -740,20 +740,32 @@ void cDvbPlayer::Pause(void)

 void cDvbPlayer::Play(void)
 {
+  bool resyncAfterSlowForward = false;
   if (playMode != pmPlay) {
      LOCK_THREAD;
      if (playMode == pmStill || playMode == pmFast || (playMode == pmSlow && playDir == pdBackward)) {
         if (!(DeviceHasIBPTrickSpeed() && playDir == pdForward))
            Empty();
         }
+     if (playMode == pmSlow && playDir == pdForward)
+        resyncAfterSlowForward = true;
      DevicePlay();
      playMode = pmPlay;
      playDir = pdForward;
-     if (resyncAfterPause) {
+     if (!resyncAfterSlowForward) {
+        if (resyncAfterPause) {
+           int Current, Total;
+           if (GetIndex(Current, Total, true))
+               Goto(Current);
+           resyncAfterPause = false;
+           }
+        }
+     else {
         int Current, Total;
-        if (GetIndex(Current, Total, true))
-           Goto(Current);
-        resyncAfterPause = false;
+        if (GetIndex(Current, Total, false)) {
+           int Index = index->GetNextIFrame(Current, true, NULL, NULL, NULL);
+           Goto(Index);
+           }
         }
      }
 }

Display More

kamel5 · Oct 26th 2024

Quote from jrie

Wenn die anderen Player Plugins (dvbsddevice, dvbhddevice, rpidevice, softhdevice-drm und softhdevice-drm-gles) damit auch besser funktionieren bzw. zumindest nicht beeinträchtigt werden, sollte der Patch wohl in den VDR.
Da müsste man mal einen Aufruf zum Testen machen.

dvbhddevice habe ich kurz mal getestet:

Es sieht so aus, das mit Deinem Patch mehr Störungen auftreten beim Übergang von Zeitlupe vorwärts zum normalen Abspielen. Ohne den Patch sind die Übergänge mehrheitlich smooth.

Deutlich mehr Störungen habe ich beim Übergang von Pause zum normalen Abspielen, hat hiermit aber nichts zu tun.

Grüße

kamel5

jrie · Oct 26th 2024

Funktionieren denn Sprünge bei dir? Der Patch macht doch nur einen Sprung zum nächsten I-Frame.

kamel5 · Oct 26th 2024

Quote from jrie

Funktionieren denn Sprünge bei dir?

Wie meinst Du das?

Springen mit Grün und Gelb, ja das funktioniert ohne Probleme.

Quote from jrie

Der Patch macht doch nur einen Sprung zum nächsten I-Frame.

Ja, keine Ahnung was da dvbhddevice und der Treiber von der Karte machen. Auf jeden Fall ist der subjektive Eindruck beim Übergang von Zeitlupe vorwärts zum normalen Abspielen ohne den Patch meist ohne Ruckeln.

Grüße

kamel5

kamel5 · Oct 26th 2024

Quote from kamel5

beim Übergang von Zeitlupe vorwärts zum normalen Abspielen ohne den Patch meist ohne Ruckeln.

"Meist ohne Ruckeln" bedeutet, je länger man die Zeitlupe laufen läßt, umso eher ist der Übergang ohne Ruckeln.

Um es nochmal etwas genauer zu beschreiben:

Mit Patch scheint der Ruckler etwas kleiner zu sein, tritt aber gefühlt häufiger auf.

Ohne Patch ist der Ruckler größer, aber weniger häufig.

Grüße

kamel5

jrie · Oct 26th 2024

Quote from kamel5

Mit Patch scheint der Ruckler etwas kleiner zu sein, tritt aber gefühlt häufiger auf.
Ohne Patch ist der Ruckler größer, aber weniger häufig.

Und ist jetzt eins von beiden gefühlt weniger schlimm, oder nimmt sich das nichts bzw. würde jemand anders eine ander Präferenz haben?

kamel5 · Oct 26th 2024

Quote from jrie

Und ist jetzt eins von beiden gefühlt weniger schlimm, oder nimmt sich das nichts bzw. würde jemand anders eine ander Präferenz haben?

Schwer zu sagen, wobei mich der größere Ruckler ohne Patch schon manchmal stört, andererseits mehr kleine Ruckler ist halt auch nicht so optimal.

Im Endeffekt könnte ich wohl mit beiden Varianten leben, da ich diesen Übergang eh nur sehr selten benutze, eher den Übergang von Zeitlupe rückwärts zu normalem Abspielen.

Das ist aber nur meine persönliche Meinung, vielleicht gibt es ja noch andere Meinungen dazu.

Ich lasse jetzt den Patch bei mir mal drin, mal sehen, ob sich da noch Erkenntnisse ergeben.

Grüße

kamel5

Dr. Seltsam · Oct 26th 2024

Bei softhdodroid bemerke ich keinen Unterschied zwischen beiden Patches. Ein kleiner Sprung von wenigen 100 ms ist banal und ob der vorwärts oder rückwärts stattfindet ist mir einerlei. Die verschiedenen Plugins werden sich hier sicher unterschiedlich verhalten. Das geht damit los, ob bei Pause sofort (zwischen zwei i-frames) gestoppt wird, oder ob ein i-frame angesprungen wird (oder das abgewartet wird). Manche Decoder können vielleicht nahtlos das nächste b-frame abspielen, andere nicht. Bei SD-Hardwaredekodern wie av7110 (dvbsddevice) oder cx23425 (pvr350) werden einfach alle Video- und Audiopakete an den Hardwaredekoder geschickt, der sie in der richtigen Reihenfolge zusammensetzt und die A/V-Synchronität herstellt. Die Pause wird da einfach über ein Firmwarekommando gesetzt und gelöst. Ich vermute, dass es bei dvbhddevice ähnlich ist. Wenn der Ton separat über alsa ausgegeben wird, ist die Verarbeitung viel aufwändiger.

Die Frage ist, ob kls das Setzen des Wertes von resyncAfterPause im dvbplayer durch Plugins irgendwie implementieren kann.

kls · Oct 26th 2024

resyncAfterPause wurde eingebaut, um stotternden oder asynchronen Ton zu vermeiden, wenn die Audio-Spur bei pausiertem Video umgeschaltet wird. Alle anderen Übergänge während der laufenden Wiedergabe sind Sache des Ausgabedevices.

Dr. Seltsam · Oct 26th 2024

Quote from kls

Alle anderen Übergänge während der laufenden Wiedergabe sind Sache des Ausgabedevices.

Da das Ausgabeplugin weder einen eigenen Player implementiert noch eine Remux durchführt (was auch viel zu aufwändig wäre) hilft das leider nicht weiter.

Vielleicht kann man die GetIndex- und GoTo-Funktion des dvbplayers im Plugin irgendwie über ccontrol ansprechen - das übersteigt aber meine Fähigkeiten. Anstelle des resync reicht es vielleicht, wenn das Plugin einen Clear() macht.

kls · Oct 26th 2024

Wo genau ist denn eigentlich das Problem (sorry, hab den Thread nicht im einzelnen verfolgt)?

Ich sehe hier bei rpihddevice und softhddevice nichts, was nicht funktionieren würde.

Dr. Seltsam · Oct 27th 2024

Moin Klaus,

es geht um eine unsaubere Wiedergabe durch A/V-Asynchronität beim Wechsel von Zeitlupe vorwärts (speed 2, 4 oder 8 ) zurück zu Play.

Devices, bei denen sowohl Audio als auch Video an einen Hardwaredecoder geschickt werden (FF-Karten SD und HD, rpihddevice) kommen damit zurecht, weil der Hardwaredecoder intern alles Notwendige abwickelt. Für die meisten Ausgabedevices erfolgt die Tonausgabe aber separat über alsa, das seine eigenen Puffer hat, die recht groß bemessen sein müssen, damit es im laufenden Betrieb nicht zu underrruns kommt. Softhddevice hat da einige Probleme gehabt, die aber letztendlich gelöst werden konnten. Dabei ist zu berücksichtigen, dass softhddevice auch die Videoframes selbst erstellt und deshalb mehr Möglichkeiten hat. Andere devices wie softhdodroid (und vermutlich in ähnlicher Weise auch softhddevice-drm) haben eine sehr hardwarenahe Videoverarbeitung. Für amlogic-Boxen werden die Videopakete mehr oder weniger direkt an den Kernel geschickt. Der Ton läuft getrennt über alsa, und es erfordert etwas mehr Aufwand, Bild und Ton zu synchronisieren. Beim Spulen und bei Wechsel von Zeitlupe rückwärts zu Play löst vdr ein Clear aus. Die "Wiedereinsprunggenauigkeit" anhand der mittels GetSTC ermittelten PTS ist dann gut.

Anders sieht es nun aus, wenn von Zeitlupe vorwärts (Freeze und anschließend Trickspeed 2, 4 oder 8 ) zu Play gewechselt wird. An dieser Stelle löst vdr keinen Clear aus. Als dvbplayer.c geschrieben wurde, war das wohl auch nicht notwendig, weil der AV7110-Dekoder das alleine über seine ioctl's hingekriegt hat. Bei softhdodroid stehen wir vor dem Problem, dass beim Beginn der Zeitlupe ja irgendwas mit dem Ton gemacht werden muss. Die Verarbeitung weiterer Audiopakete können wir aussetzen, aber was ist mit denen, die noch im alsa buffer sind? Wenn wir die clearen, ist der buffer leer und nach dem Wechsel zu Play dauert es einige Sekunden, bis der buffer wieder ausreichend gefüllt ist. Clearen wir ihn nicht, kommen bei Play erstmal alte Audiodaten, die nicht zum Bild passen. Wir könnten einen sauberen synchronen Wiederanlauf hinkriegen, in dem wir mit Clear() Video und Audio zusammen zurücksetzen. Aber dabei entsteht ein Sprung von mehreren Sekunden.

Mit den beiden Patches für den dvbplayer hat jre Lösungen vorgeschlagen, die zumindest einen resync bei Wechsel von Zeitlupe vorwärts zu Play machen, evtl. sogar über GetIndex/GoTo wieder an der letzten Stelle exakt ansetzen. Innerhalb des Ausgabeplugins können wir das so aber nicht implementieren, ohne gleich einen eigenen Player zu verwenden - das ist zumindest mein Verständnis.

Könntest Du Dir denn vorstellen, einen setup-Parameter "Resync after Slow speed" unter Einstellungen - Wiedergabe aufzunehmen, mit dem man das von jre reingepatchte Verhalten konfigurierbar machen kann? Als Standardmethode wird sich das wahrscheinlich nicht eignen, weil die verschiedenen Ausgabeplugins halt Hardware mit unterschiedlichen Eigenheiten ansprechen.

MarkusE · Oct 27th 2024

> setup-Parameter

Oder das Ausgabeplugin kann einstellen, welches Verhalten es benötigt

jrie · Oct 27th 2024

Quote from Dr. Seltsam

nach dem Wechsel zu Play dauert es einige Sekunden, bis der buffer wieder ausreichend gefüllt ist.

Bei einer Aufnahme geht das eigentlich sehr schnell. Die Daten sind ja alle schon da.

Quote from Dr. Seltsam

Aber dabei entsteht ein Sprung von mehreren Sekunden.

Die Frage ist, warum.

Quote from kamel5

Ohne Patch ist der Ruckler größer

scheint das zu bestätigen.

Auch vdr-plugin-xine hat das Problem.

Mein Verdacht ist, dass der VDR bei Play Daten schickt, die ca. 3 Sekunden weiter vorne sind als das letzte Zeitlupen-Bild.

jrie · Nov 1st 2024

Quote from kls

Alle anderen Übergänge während der laufenden Wiedergabe sind Sache des Ausgabedevices.

Was soll das Ausgabedevice machen, wenn der VDR falsche Daten liefert?

Ich habe in softhddevice printf's eingebaut, die mir die eingehende Audio pts zeigen.

Dann habe ich einen Film mit gleichmässiger Bewegung genommen und Pause->Zeitlupe vorwärts-> Play getestet, dabei habe ich versucht das Play immer an derselben Stelle zu drücken. Da ich bei jeweils 3 Versuchen mit bzw. ohne Patch dieselbe pts bekommen habe, ist mir das offenbar geglückt.

Die pts ohne Patch ist 298080 größer als die mit Patch. Das sind genau 3,312 Sekunden.

Wie könnte man im VDR die pts anzeigen, die ausgeliefert werden? So als Doppelcheck. Oder geht das mit dem Index? Da ist ja auch noch ein Puffer.

Wenn man davon ausgeht, dass softhddevice normalerweise gut funktioniert, kann man annehmen, dass die Debugausgaben richtig sind.

Das bedeutet, dass der VDR da einen Fehler macht.

Die letzte Version des Patches: dvbplayer.c.6.diff.txt

rell · Nov 11th 2024

Nachdem ich mein Trickspeed jetzt relativ zufriedenstellend laufen habe, steige ich mal in euer Problem oben mit ein.

Es ist hier auch so, dass es Probleme mit folgender Reihenfolge gibt:

Play->Pause->SlowForward->Play

Wenn ich in softhddevice-drm-gles die audio und video pts ausgebe, dann sind beide ca. 3s auseinander. Der Patch von RE: TrickSpeed - Verständnisfrage behebt das Problem.

Folgende Abfolge macht aber auch Probleme:

Play->Pause->SlowForward->Pause->Play

Habt ihr das mal getestet?

Meine Vermutung: softhddevice setzt durch das DeviceMute SkipAudio, was dem VDR durch die Rückgabe von size in PlayAudio() signalisiert, dass die Audiopakete angenommen worden sind. Die landen aber nicht im Ringbuffer. Bei Mute ist das schon richtig, weil die PTS ja weiterlaufen soll und dem VDR vorgetäuscht wird, dass die Audiopakete verarbeitet wurden. Bei Trickspeed ist das aber schlecht.

Kann es sein, dass VDR bei einer Aufnahme weiter Audiopakete sendet, solange welche verfügbar sind (bei einer Aufnahme ja eigentlich so gut wie sicher)?

Das Device sagt dem VDR, dass die Pakete verarbeitet wurden und der aktuelle audio pts läuft dem Video davon, das ja in Zeitlupe läuft...

Beim erneuten Play (nach einer Zeitlupe) ist nun der audio pts dem video pts voraus und muss wieder synchronisiert werden. So meine Theorie. Der Patch oben korrigiert das (bei einem Play direkt aus Trick) und müsste noch um ein Play aus der Pause nach einem Trick ergänzt werden.

Oder aber man kriegt das im softhddevice in den Griff, wofür mir aber aktuell die Idee fehlt. Ein von VDR getriggertes resync mit einem Goto() wäre deutlich einfacher - dann würde sich auch der Player darum kümmern.

Zurück zu meiner konkreten Frage: Klappt bei euch Play->Pause->SlowForward->Pause->Play ?

rell · Nov 12th 2024

Mit sowas wäre auch der Fall Play->Pause->SlowForward->Pause->Play erschlagen:

Diff

diff --git a/dvbplayer.c b/dvbplayer.c
index c36fac70..da26d155 100644
--- a/dvbplayer.c
+++ b/dvbplayer.c
@@ -261,6 +261,7 @@ private:
   cFrame *playFrame;
   cFrame *dropFrame;
   bool resyncAfterPause;
+  bool resyncAfterSlowForward;
   void TrickSpeed(int Increment);
   void Empty(void);
   bool NextFile(uint16_t FileNumber = 0, off_t FileOffset = -1);
@@ -317,6 +318,7 @@ cDvbPlayer::cDvbPlayer(const char *FileName, bool PauseLive)
   playFrame = NULL;
   dropFrame = NULL;
   resyncAfterPause = false;
+  resyncAfterSlowForward = false;
   isyslog("replay %s", FileName);
   fileName = new cFileName(FileName, false, false, isPesRecording);
   replayFile = fileName->Open();
@@ -749,12 +751,23 @@ void cDvbPlayer::Play(void)
      DevicePlay();
      playMode = pmPlay;
      playDir = pdForward;
-     if (resyncAfterPause) {
+     if (!resyncAfterSlowForward) {
+        if (resyncAfterPause) {
+           int Current, Total;
+           if (GetIndex(Current, Total, true))
+              Goto(Current);
+           }
+        }
+     else {
         int Current, Total;
-        if (GetIndex(Current, Total, true))
-           Goto(Current);
-        resyncAfterPause = false;
+        if (GetIndex(Current, Total, true)) {
+           int Index = index->GetNextIFrame(Current, true, NULL, NULL, NULL);
+           Goto(Index);
+           }
+        resyncAfterSlowForward = false;
         }
+     if (resyncAfterPause)
+        resyncAfterPause = false;
      }
 }
 
@@ -797,6 +810,8 @@ void cDvbPlayer::Forward(void)
             // run into pmPause
        case pmStill:
        case pmPause:
+            if (playMode == pmPause)
+               resyncAfterSlowForward = true;
             DeviceMute();
             playMode = pmSlow;
             playDir = pdForward;

Display More

Jetzt muss ich noch schauen, was der Grund dafür ist, dass z.B. bei slow backward der Zeitstempel im replay OSD anfangs zu schnell zurückläuft und sich erst nach ein paar Sec die richtige Zeit anzeigt. Das Bild passt...

TrickSpeed - Verständnisfrage

Participate now!

Share