Radio-Aufnahmen mit VDR-2.8.1

Kann ich nachvollziehen, schau ich mir an.

Ich kann das bei mir auch mit Radio-Aufnahmen über SAT und VDR 2.8.1 mit softhddevice 2.4.8 reproduzieren.
Ich habe dann noch anstatt softhddevice das neue vaapivideo als Ausgabe-Frontend getestet und da tritt das Problem nicht auf.
Mit vaapivideo (bei MLD 6.5 aktuell Version 1.5.5) kann ich bei einer Radio-Aufnahme auch Springen sowie Schnittmarken setzen und diese bearbeiten.
Das Problem liegt also vermutlich bei softhddevice.

habt Ihr das Radio-Plugin aktiv, und wenn ja mit Pes- oder Stillpicture-Funktion?

Die Ausgabedevices reagieren z.T. empfindlich auf Audio-only. Mit softhdodroid kann ich unter vdr-2.8.1 Radioaufnahmen auch ohne radio-Plugin abspielen. Und auch Spulen und Springen ist möglich. Wir haben da aber schon vor längerer Zeit die Funktion GetSTC so angepasst, dass bei fehlenden Videodaten die PTS nicht vom Video, sondern vom Audio abgefragt wird.

int64_t GetSTC(void)
{
   if (MyVideoStream->HwDecoder && hasVideo) {
           return VideoGetClock(MyVideoStream->HwDecoder);
   } else {
           return AudioGetClock();
   }
   // could happen during dettached
   Warning(_("softhddev: %s called without hw decoder\n"), __FUNCTION__);
   return -1;
}

Das macht softhddevice z.B. nicht:

int64_t GetSTC(void)
{
   if (MyVideoStream->HwDecoder) {
    return VideoGetClock(MyVideoStream->HwDecoder);
   }
   // could happen during dettached
   Debug(3,"softhddev: %s called without hw decoder\n", __FUNCTION__);
   return AV_NOPTS_VALUE;
}

Bei dem Plugin von rell gibt es einen guten Ansatz

int64_t cSoftHdDevice::GetSTC(void)
{
    if (IsDetached())
        return AV_NOPTS_VALUE;
    switch (m_playbackMode) {
        case NONE:
            return AV_NOPTS_VALUE;
        case AUDIO_AND_VIDEO:
        case VIDEO_ONLY:
            return m_pRender->GetVideoClock();
        case AUDIO_ONLY:
            return m_pAudio->GetHardwareOutputPtsTimebaseUnits();
    }
    abort();
}

der aber m.E. in der Praxis bei Radioaufnahmen wirkungslos bleibt, denn vdr spielt diese m.E. mit dem normalen Playmode pmAudioVideo ab. Spezielle Playmodes wie

pmAudioOnly,      // audio only from player, video from decoder

waren für Plugins wie mp3 gedacht.

Quote from Dr. Seltsam

der aber m.E. in der Praxis bei Radioaufnahmen wirkungslos bleibt, denn vdr spielt diese m.E. mit dem normalen Playmode pmAudioVideo ab. Spezielle Playmodes wie

pmAudioOnly,      // audio only from player, video from decoder

waren für Plugins wie mp3 gedacht.

NONE, AUDIO_AND_VIDEO, VIDEO_ONLY und AUDIO_ONLY werden durch das Plugin gesetzt und haben erstmal nichts mit dem playmode von VDR zu tun.

Die Logik dahinter ist: Sobald PlayVideo() aufgerufen wurde, werden Video-Daten erkannt und bei PlayAudio() eben Audio. Dadurch ergeben sich dann die o.g. Modi.
Bei Radio sollte der VDR nur PlayAudio() aufrufen, weshalb im Ergebnis dann AUDIO_ONLY gesetzt wird.

Edit: Bzw. genauer gesagt, die o.g. (internen) Modi hängen davon ab, ob seit Streamstart jeweils ein Video- und/oder Audio-PTS aufgetreten ist.

was ist, wenn zuerst PlayAudio vom vdr kommt und danach PlayVideo? Wird dann kurzzeitig die Audio-PTS genommen, oder gibt es eine Wartezeit mit Erkennung im Sinne von "wenn bis jetzt kein PlayVideo kam, dann kommt es auch nicht mehr und es muss audio_only sein"?

Früher bei mpeg2 konnte man sich glaube ich darauf verlassen, dass es radio ist, wenn das erste Paket ein Audiopaket war. Aber das ist heute ja nicht mehr so.

Quote from Dr. Seltsam

was ist, wenn zuerst PlayAudio vom vdr kommt und danach PlayVideo?

Das spielt keine Rolle, da der interne PlaybackMode erst gesetzt wird, wenn Audio- und Video synchronisiert werden kann bzw. wenn innerhalb des Threshold (450ms) nur Video oder Audio über PlayVideo()/PlayAudio() gesendet wurden und damit der Stream als audio- oder video-only erkannt wird. Diese 450ms hat man quasi Zeit zu entscheiden, ob der Stream audio und/oder video hat. Dafür muss man voraussetzen können, dass von VDR im Regelfall innerhalb dieser Zeit bei Audio+Video für beide Arten via Play*() ein PES Paket kommt.

Hier ist die Logik dahinter: https://github.com/rellla/vdr-plu…evice.cpp#L1353

I've never tried recording radio. I'll add this to my queue.

Ich gehe dann mal davon aus, dass das kein Problem im Core-VDR ist.

Für softhddevice gibt es eine einfache Lösung analog zu #4

--- a/softhddev.c	2026-06-26 14:03:11.722367754 +0200
+++ b/softhddev.c	2026-07-14 13:53:50.105256809 +0200
@@ -101,6 +101,7 @@ static enum VideoHardwareDecoderMode Con
 static pthread_mutex_t SuspendLockMutex;	///< suspend lock mutex
 
 static volatile char StreamFreezed;	///< stream freezed
+extern volatile char SoftIsPlayingVideo;		///< activates audio-video sync
 
 extern int SysLogLevel;			///< VDR's global log level
 int LogLevel = 0;			///< our local log level
@@ -3002,8 +3003,14 @@ int SetPlayMode(int play_mode)
 */
 int64_t GetSTC(void)
 {
-    if (MyVideoStream->HwDecoder) {
-	return VideoGetClock(MyVideoStream->HwDecoder);
+    if (SoftIsPlayingVideo) {
+        if (MyVideoStream->HwDecoder) {
+	          return VideoGetClock(MyVideoStream->HwDecoder);
+        }
+    }
+    else {
+        if (MyAudioDecoder)
+            return AudioGetClock();
     }
     // could happen during dettached
     Debug(3,"softhddev: %s called without hw decoder\n", __FUNCTION__);

Übrigens funktioniert bei mir die Fortschrittssanzeige bei Radioaufnahmen auch in vaapivideo nicht

Ich hole mal lnj dazu, damit er das übernehmen kann. Und auch zorkkann vielleicht etwas ähnliches einbauen

Schaue ich mir Mal an.

I'll take a look.

Quote from Dr. Seltsam

Ich hole mal lnj dazu, damit er das übernehmen kann. Und auch zorkkann vielleicht etwas ähnliches einbauen

vaapivideo ist gefixt.

Hui, das sieht aufwändig aus. Respekt!

Has anyone tested radio playback with these updates?

I recorded a minute and a half of DVD-T radio.
Yes, the radio recording plays. But with softhddevice about half a minute before the end, the progress bar stops and doesn't go to the end. Once the sound is finished, digital noise comes from the buffer, and playback doesn't stop until I press the stop button. I have the same problem with vaapivideo: although the progress bar shows correctly, playback doesn't stop until I press stop.

The plugin-radio was disabled.

How does this happen with softhdodroid?

I need to understand whether this is a problem with the output plugin or with the VDR core.

Quote from lnj

Has anyone tested radio playback with these updates?

I recorded a minute and a half of DVD-T radio.
Yes, the radio recording plays. But with softhddevice about half a minute before the end, the progress bar stops and doesn't go to the end. Once the sound is finished, digital noise comes from the buffer, and playback doesn't stop until I press the stop button. I have the same problem with vaapivideo: although the progress bar shows correctly, playback doesn't stop until I press stop.

You are right! VDR decides a recording is finished when the playback clock stops moving, but for radio vaapivideo kept re-decoding the last frame VDR repeats at EOF, so the audio clock never went quiet. my fix: on replay, vaapivideo now recognises that repeated tail packet and drops it, so the clock stalls and VDR stops the recording by itself.

Here is my commit message: github - vaapivideo

Quote from lnj

Has anyone tested radio playback with these updates?

I recorded a minute and a half of DVD-T radio.
Yes, the radio recording plays. But with softhddevice about half a minute before the end, the progress bar stops and doesn't go to the end. Once the sound is finished, digital noise comes from the buffer, and playback doesn't stop until I press the stop button. I have the same problem with vaapivideo: although the progress bar shows correctly, playback doesn't stop until I press stop.

The plugin-radio was disabled.

How does this happen with softhdodroid?

same behavior

Ist zu lösen, einfach bei mir abgucken. Offensichtlich nutzt kein Mensch Radioaufnahmen, wenn das seit 15 Jahren keiner reportet hat.

I made this in the test branch. The progress indicator doesn't work correctly when rewinding to the beginning. The trick modes also don't work very well.