video delay method

[RJVB]

I've been experimenting with streaming audio via icecast2, and think that the video delay feature is ... quirky. I suppose the feature exists for systems that have a channel delay in either audio or the video transmission channel, and the symptoms I noticed may not be an issue if the delay is on the order of a few hundred ms. With icecast2 you don't control it (AFAIK), and today I had about 23 seconds delay on the audio ... and it took me almost 5 minutes to get that configured correctly for a reasonable playback.

• The direct delay specification clearly uses a positive value to indicate the time video frames have to be delayed, as you'd expect. But the "Delay Video (100ms)" menu action SUBTRACTS from that value.
• Delaying the video doesn't actually do that; the video starts playing immediately. That makes it just about impossible to fine-tune the delay compensation by starting the playback just before a synchronisation mark (something identifiable in the video and audio tracks).
• Idem, speeding up the video does that literally, playing the "delayed" duration at max. speed before settling to normal speed with the audio delayed (which is how the feature should be called instead!). That makes it impossible to watch (local) videos that are short compared to the transmission delay, and also to watch streaming (YouTube) videos when their buffering is not adjusted.
• The delay value is reset to 0 when you stop playback (or start a new playback). (There may be an option to change that, I haven't checked.)

I haven't looked at the code to see exactly how the feature is implemented, but IMHO

• with delayed video, audio playback should be started immediately and the video playback only after the specified duration
• with delayed audio (aka "sped up video"), it's the video playback that should start immediately and the audio playback delayed.

[RJVB]

FWIW, it's great that the feature exists!

[zaps166]

Generally, the code for this is very old and probably most needs to be rewritten with better logic... Negative video delay skips video, positive video delay skips audio. It is visible at playback start and seeking.

The delay value is reset to 0 when you stop playback

There are options for this:

[RJVB]

Negative video delay skips video, positive video delay skips audio. It is visible at playback start and seeking.

that's the thing, if you're dealing with an actual long transport delay (say in the audio), the only thing you see at playback start is that the video starts. In other words, the effect of the delay setting becomes visible only once the audio device finally begins playing back the sound.

I got the impression from the YouTube bandwidth ticket that you handle the video and audio playback separately, so actually delaying the start of the video (for positive delays) might even be easier than skipping content, no? I hope you'll get around to addressing this soon!

There are options for this:

OK, my bad. I thought there were but clearly overlooked them.