TrickSpeed - Verständnisfrage

Das war ja mein 2. Vorschlag. Denke aber dran, dass damit diese Decoder Instanz keine weitete Pakete mehr annimmt.

"the decoder has been flushed, and no new packets can be sent to it (also returned if more than 1 flush packet is sent)"

Ich finde den Vorschlag von zillerbaer gut: sende doch einfach das gleiche Packet so lange zum Decoder, bis du das Frame zurück bekommst.

Habe ich nie ausprobiert, ich versuche immer sinnvolle Werte zu verwenden, selbst wenn es heute geht, weiß man ja nie, was nach dem nächsten FFmpeg Update passiert.

rell: Du kannst Dir ja mal anschauen, wie jojo61 es in softhdodroid gelöst hat. Die entscheidende Stelle ist m.E. in video.c in der Funktion CodecVideoDecode. Wenn es sich um einen Rückwärts-Trickspeed handelt oder um die Stufen 1, 3 oder 6 (=Spulen, keine Zeitlupe) wird ein reset des Decoders mit Leerung der Buffer ausgeführt. Es findet zudem mittels usleep eine kleine Verzögerung statt, deren Dauer von der Art des Trickmodus abhängig ist. Und irgendwas wird da auch mit der PTS gemacht.

Was mich interessieren würde: Wie gut funktioniert denn bei Euch die aus der Pause heraus aufgerufene Zeitlupe vorwärts und hier insbesondere der Wechsel zurück auf Normalgeschwindigkeit? Hier haben wir uns bislang die Zähne ausgebissen. Es kommt dabei zu Bildsprüngen, weil eine A/V Asynchronität aufgeholt werden muss, die u.a. dadurch entsteht, dass ab Wechsel zu Pause die Audiopakete verworfen werden und der Audio-Buffer gecleart wird. Von vdr kommt an dieser Stelle aber kein Clear. Ich habe versucht, das ähnlich wie beim Spulen mit einem reset des Videodecoders zu lösen, aber es kam nichts brauchbares dabei raus.

Mir ist klar, dass softhdodroid mit seinen amlogic-spezifischen ioctl ganz anders funktioniert, aber vielleicht kannst Du ja trotzdem die eine oder andere Anregung mitnehmen. Generell ist zu sagen, dass Rückwärtsspulen bei h264 Glückssache ist. Es gibt immer wieder Aufnahmen, bei denen das trotzdem nicht funktioniert. Das ist bei softhddevice so, das ist bei softhdodroid so und scheint senderunabhängig zu sein. Wahrscheinlich heißt es deswegen Trickspeed - weil es so tricky ist

Quote from rell

Wie hast du die "Wartezeit" festgelegt?

Da habe ich einfach durch ausprobieren ermittelt. Allerdings nutzt der softhdodroid ja keinen ffmpeg zum dekodieren. Deswegen ist der vergleich damit eher wie Äpfel mit Birnen. Da wäre ein Vergleich mit dem softhdcuvid wohl besser.

Ich erinnere mich gerade nicht so recht, aber ich schicke da die I-Frames mehrfach durch den ffmpeg dekoder bis ein Frame rauskommt.

Quote from Dr. Seltsam

Was mich interessieren würde: Wie gut funktioniert denn bei Euch die aus der Pause heraus aufgerufene Zeitlupe vorwärts und hier insbesondere der Wechsel zurück auf Normalgeschwindigkeit? Hier haben wir uns bislang die Zähne ausgebissen. Es kommt dabei zu Bildsprüngen, weil eine A/V Asynchronität aufgeholt werden muss, die u.a. dadurch entsteht, dass ab Wechsel zu Pause die Audiopakete verworfen werden und der Audio-Buffer gecleart wird. Von vdr kommt an dieser Stelle aber kein Clear. Ich habe versucht, das ähnlich wie beim Spulen mit einem reset des Videodecoders zu lösen, aber es kam nichts brauchbares dabei raus.

Ich weiss jetzt nicht, ob das auf eurer Hardware anders ist, aber auf "normaler" Hardware habe ich das bereits 2015 gefixt.

Post

RE: Soft-Start bei softhddevice

Ein neuer Patch für die Fehlerbehandlung vom recover nach dem underrun in AlsaPlayRingbuffer().
Gelegentlich hat AudioUsedModule→FlushBuffers(); unerwünschte Nebenwirkungen.
Der Unterschied ist, für erfolgreichen recover mit return 0 raus zu gehen statt mit continue.
Das passt dann auch besser zu den Kommentaren.

jrie

December 2, 2015 at 2:37 PM

improve error handling after recover from underrun in AlsaPlayRingbuffer() for faultless play after pause

jojo61 hat für seine Forks einen Stand benutzt, wo das (und andere wichtige Fixe) nicht drin war.

Mit return 0; statt continue; braucht man die ganzen workarouds nicht mehr.

Der Fix ist eher unintuitiv, da normalerweise in den Beispielen immer continue; steht, aber durch die ganzen Verschachtelungen im Audio Code ist das so nötig.

Bringt leider keine Veränderung.Das Problem tritt auch nicht beim einfachen Wechsel von Pause zu Play und zurück auf, sondern immer nur, wenn dazwischen eine Zeitlupe vorwärts gestartet wurde.

Quote from Dr. Seltsam

Das Problem tritt auch nicht beim einfachen Wechsel von Pause zu Play und zurück auf, sondern immer nur, wenn dazwischen eine Zeitlupe vorwärts gestartet wurde.

Gerade getestet: das tritt auch bei softhddevice auf.

ugly fix for Pause -> SlowForward -> Play:

https://github.com/j1rie/vdr-plug…48419583ee423e9

Noch nicht auf Nebenwirkungen getestet, aber löst das Problem.

Das SlowForward löst ein Mute aus, das verursacht AudioFlushBuffers(), das setzt AudioVideoIsReady auf 0, deswegen spielt dann kein Audio mehr beim Play(). Wenn man bei Beendigung das Trickspeeds AudioVideoIsReady auf 1 setzt, kommt Ton.

Oder so:

int oldspeed;
...
void cSoftHdDevice::TrickSpeed(int speed, bool forward)
{
    Debug(3, "[softhddev]%s: %d %d\n", __FUNCTION__, speed, forward);

    oldspeed = speed;
    ::TrickSpeed(speed);
}

...
void cSoftHdDevice::Play(void)
{
    Debug(3, "[softhddev]%s:\n", __FUNCTION__);
    printf("softhddev Play\n");

    if (oldspeed ==2 || oldspeed == 4 || oldspeed == 8) {
    Debug(3, "[softhddev] Clear: Play after SlowForward\n";
    ::Clear();
    }

    cDevice::Play();
    ::Play();
}

Das gibt aber einen kleinen Sprung.

Wenn man sich mit GetIndex() die Stelle holt, wo man gerade ist und dann mit Goto() dahin springt, müsste es gehen (Goto() müsste man auch noch in VDR's player.h einbauen, GetIndex() gibts da schon).

Mein C++ ist aber zu schlecht dafür.