Kann ich nachvollziehen, schau ich mir an.
Bevor hier alle plugin Entwickler nacharbeiten, stelle ich die Frage ob das Verhalten des VDR richtig ist. Es ist sicher richtig am Ende der Audiostreams auf den letzten PTS zu warten, aber ich denke es ist falsch derweil das letzte Audiopaket zu wiederholen. Das muss dann im Ausgabeplugin künstlich abgefangen werden und erfordert Aufwand der nicht nötig wäre.
kls wie siehst du das ?
Ich habe das hier nicht weiter verfolgt, wegen
Ich gehe dann mal davon aus, dass das kein Problem im Core-VDR ist.
ich denke es ist falsch derweil das letzte Audiopaket zu wiederholen
Du beziehst dich wahrscheinlich auf das hier in dvbplayer.c:
if (dropFrame) {
if (!eof || (playDir != pdForward && dropFrame->Index() > 0) || (playDir == pdForward && dropFrame->Index() < readIndex)) {
ringBuffer->Drop(dropFrame); // the very first and last frame are continuously repeated to flush data through the device
dropFrame = NULL;
}
}was erstmals in https://git.tvdr.de/?p=vdr.git;a=c…a37d76043892988 eingebaut wurde. Gibt es eine bessere Lösung für das Problem?
Gibt es eine bessere Lösung für das Problem?
Ich bin etwas verwirrt. Ich dachte du erkennst das ende des Ausspielen des Streams am konstanten PTS (siehe #17). Jetzt habe ich beim debuggen gesehen das GetSTC nur aufgerufen wird wenn im OSD der Fortschrittsbalken angezeigt wird. Wie erkennst du denn nun das Ende des Ausspielens wenn du nicht GetSTC aufrufst.
Bei einem Stream mit Video scheint ja dann auch das letzte Frame wiederholt zu werden ohne das es Probleme gibt, das wundert mich nun auch etwas.
Was haltet ihr davon, wenn man das direkt in dvbplayer.c fixt:
if (dropFrame) {
- if (!eof || (playDir != pdForward && dropFrame->Index() > 0) || (playDir == pdForward && dropFrame->Index() < readIndex)) {
+ if (!eof || !DeviceIsPlayingVideo() || (playDir != pdForward && dropFrame->Index() > 0) || (playDir == pdForward && dropFrame->Index() < readIndex)) {
ringBuffer->Drop(dropFrame); // the very first and last frame are continuously repeated to flush data through the device
dropFrame = NULL;
}Bei reinen Audio-Aufnahmen gibt es kein Standbild – das wiederholte letzte Frame schickt hier nur das letzte Audio-Frame erneut raus. Neu: Wenn das Gerät kein Video wiedergibt (DeviceIsPlayingVideo()), werfen wir das letzte Frame weg statt es zu wiederholen. Der VDR stoppt am Ende wie bisher von selbst.
Hi,
Was ist mit Radiosendern mit wenig Video? Gibt doch teils Standbild oder wechselnde Bilder/Werbung?
MfG Stefan
Jetzt habe ich beim debuggen gesehen das GetSTC nur aufgerufen wird wenn im OSD der Fortschrittsbalken angezeigt wird.
Das wäre mir neu. GetSTC() wird doch auch ohne Fortschrittsanzeige aufgerufen.
// Handle hitting begin/end of recording:
if (eof || SwitchToPlayFrame) {
bool SwitchToPlay = false;
uint32_t Stc = DeviceGetSTC();
if (Stc != LastStc || playMode == pmPause)
StuckAtEof = 0;
else if (!StuckAtEof)
StuckAtEof = time(NULL);
else if (time(NULL) - StuckAtEof > MAXSTUCKATEOF) {
if (playDir == pdForward)
break; // automatically stop at end of recording
SwitchToPlay = true;
}
LastStc = Stc;
int Index = ptsIndex.FindIndex(Stc, playMode == pmStill);
if (playDir == pdForward && !SwitchToPlayFrame) {
if (Index >= LastReadFrame)
break; // automatically stop at end of recording
}
else if (Index <= 0 || SwitchToPlayFrame && Index >= SwitchToPlayFrame)
SwitchToPlay = true;
if (SwitchToPlay) {
if (!SwitchToPlayFrame)
Empty();
DevicePlay();
playMode = pmPlay;
playDir = pdForward;
SwitchToPlayFrame = 0;
}
}Was haltet ihr davon, wenn man das direkt in dvbplayer.c fixt
Da das eigentliche Problem aber davon unabhängig ist (Buffer flushen braucht's mit und ohne Video) wäre das höchstens ein Workaround, keine Lösung.
Was ist mit Radiosendern mit wenig Video? Gibt doch teils Standbild oder wechselnde Bilder/Werbung?
Wenn der Sender auch Video hätte, wäre es kein Radiosender. Ich kenne keinen einzigen echten Radiosender, der Standbilder oder Werbung mit ausstrahlt. Hintergrundbilder kommen allenfalls vom radio-Plugin
(Buffer flushen braucht's mit und ohne Video)
wahrscheinlich habe ich irgendwas nicht richtig verstanden, aber ... buffer flushen (flush = "spülen") kenne ich im Zusammenhang mit dem Leeren eines Buffers. Aber hier scheint das Gegenteil beabsichtigt zu sein - der audio buffer soll durch frame-Wiederholung nicht leer laufen. Aber warum?? Am Ende einer Wiedergabe kommt doch eh pmNone, was einen Clear mit Leerung der buffer auslöst
Das Ganze wurde 2009 eingebaut, weil es, wenn ich mich recht erinnere, Probleme gab, bis zum Ende einer Aufnahme abzuspielen. Kurz vor Erreichen des Endes blieb die Wiedergabe stehen, weil offensichtlich das Ausgabedevice auf weitere Daten gewartet hat. Möglicherweise war das ja nur ein Problem bei Full-Featured Karten und besteht bei Software-Ausgabedevices gar nicht (mehr). Vielleicht kann ja mal jemand den Mechanismus stillegen und schauen, wie es sich dann verhält. Ich hätte nichts dagegen, das ganz auszubauen, wenn es nicht (mehr) gebraucht wird.
Ich erinnere mich, das war aber 2022: Abspielen der letzten 25 Sekunden der Aufnahme: VDR reagiert nicht auf Eingaben, Bild verlangsamt
2022 hatte ich schon lange keine FF Karte mehr ...
Das war aber ein anderes Problem und wurde in Version 2.6.2 behoben:
2022-11-30: Version 2.6.2
...
- When checking whether a recording is still active, VDR no longer checks whether the
index file is being written, but rather checks for the presence of a '.timer' file.
The cutter now writes a dummy '.timer' file with timer ID '0' to make this work
for recordings that are currently being edited.War es dieser Patch?
War es dieser Patch?
Falls sich die Frage auf #32 bezieht: nein, es war dieser.
Nein, ich meine das was Du in #30 beschreibst
Dann siehe Link in #22.
kls hättest du einen Patch der das Wiederholen des letzten Frames ausbaut ? Mein eigenen Versuche das auszubauen funktionieren nicht 
Probier's mal hiermit:
--- dvbplayer.c 2026/05/30 12:27:12 5.16
+++ dvbplayer.c 2026/07/22 06:48:59
@@ -631,10 +631,10 @@
}
if (dropFrame) {
- if (!eof || (playDir != pdForward && dropFrame->Index() > 0) || (playDir == pdForward && dropFrame->Index() < readIndex)) {
+// if (!eof || (playDir != pdForward && dropFrame->Index() > 0) || (playDir == pdForward && dropFrame->Index() < readIndex)) {
ringBuffer->Drop(dropFrame); // the very first and last frame are continuously repeated to flush data through the device
dropFrame = NULL;
- }
+// }
}
// Get the next frame from the buffer:Ich hab's mal auf meinem RaspberryPi getestet und damit hat es auch ohne die Frame-Wiederholungen einwandfrei bis zum Ende gespielt (und bei schnellem Rücklauf bis zum Anfang).
Auf meinem Wohnzimmer-VDR (mit softhddevice) hat es dazu geführt, dass bei schnellem Rücklauf bis zum Anfang es etwa ein bis zwei Sekunden dauert, bis die normale Wiedergabe nach dem Erreichen des Anfangs beginnt (ohne diesen Patch ging das sofort). Bei der normalen Wiedergabe bis zum Ende blieb diese ohne diesen Patch mehrere Sekunden lang am Ende eingefroren, bis sie sich dann beendete. Mit diesem Patch war das Verhalten so wie beim schnellen Rücklauf zum Anfang, also etwa ein bis zwei Sekunden Verzögerung bis zum tatsächlichen Beenden der Wiedergabe. In Allen Fällen wurde aber alles komplett bis zum letzten Frame abgespielt.
Aus meiner Sicht wäre es also durchaus denkbar diese ganze "dropFrame"-Sache zurückzubauen. Jetzt wäre interessant, was Benutzer anderer Ausgabedevices (insbesondere FF-Karten) damit beobachten.
Mit mit dem softhdcuvid plugin verhält es sich auch so wie du beschrieben hast. Auch eine Radio Aufnahme beendet sich nun korrekt.
Sitze zwar nur remote davor, aber mit softhddevice-drm-gles scheint die Radio-Aufnahme bis zum Ende abzuspielen. Vorher wurde ca. 8s vorher schon gestoppt. Warum auch immer. Mehr habe ich aber nicht getestet. Bin aber auch der Meinung, dass VDR keine doppelten Pakete als "workaround" sende sollte. Da muss es eine andere Lösung geben.
Don’t have an account yet? Register yourself now and be a part of our community!