22 replies to this topic

[M.Najar]

Hi Developers and Community,

I'm posting this here in the Third-Party Development section as I'm unsure of the best place for a feature request, but I wanted to propose an idea and discuss its feasibility.

I would like to suggest a feature often found on other STBs (like Icone/Senator): a **RAM-based short broadcast delay (Video + Audio together)**.

**Purpose:**
The main goal of this feature is to allow users to synchronize the live satellite/cable broadcast (both video and audio) with an external audio commentary source, such as a radio broadcast or an online stream. Often, these external audio sources are delayed or ahead compared to the TV broadcast.

**How it works on other devices:**
Devices like Icone, Senator, and some others offer a similar feature often called "Video Delay". It allows the user to introduce a small delay (e.g., adjustable up to 30 or 60 seconds) to the TV broadcast being watched. This delay is typically buffered in the device's RAM, not requiring timeshift on an external HDD/USB. The user can usually increase or decrease this delay using dedicated buttons until the TV picture/sound perfectly matches their preferred external commentary.
**Why it would be useful for Enigma2/OpenPLi:**
* Many users prefer listening to specific commentators (radio, online) while watching sports events.
* Currently, achieving this sync requires complex external setups or relying on the external audio source having its own delay controls, which is often not the case.
* Implementing this directly in OpenPLi would provide a seamless and integrated solution.
**Technical Considerations (as I understand them):**
* This would essentially be a very short-term timeshift buffered entirely in RAM.
* Memory consumption would be a key factor, especially on devices with limited RAM (e.g., 1GB or less). Perhaps the maximum delay could be configurable or limited based on available memory.
* Integration with the existing timeshift system and GStreamer pipeline would be necessary.
* User control could be via remote control buttons (e.g., long-press specific keys) or an option within the Audio menu.

**Request:**
Would the OpenPLi team consider the feasibility of adding such a RAM-based broadcast delay feature? I believe it would be a valuable addition for many users who face commentary synchronization issues.
Thank you for considering this request and for your continuous efforts in developing OpenPLi.

Best regards,
Mohamed

[littlesat]

Good idea, but this will never really work as you never will get it properly continuously synched. Also sometimes you need to delay video… may need lots of RAM….

Edited by littlesat, 23 April 2025 - 08:01.

[M.Najar]

Good idea, but this will never really work as you never will get it properly continuously synched. Also sometimes you need to delay video… may need lots of RAM….

[M.Najar]

Subject: Re: Feature Request: RAM-based Video/Audio Delay for external commentary sync

Hi [littlesat],

Thank you for the quick response and for considering the idea.

I understand the concerns regarding perfect synchronization and RAM usage. Perhaps I can clarify the main goal and the core problem I'm hoping could be addressed:

1. **Goal is Broadcast Delay, Not A/V Lip-Sync Fix:** The primary aim isn't to fix internal lip-sync issues within the broadcast itself by delaying only video relative to audio. The goal is to delay the **entire broadcast stream (both video and audio together by the same amount)**. This is needed to match the TV picture/sound to an external audio source (like radio commentary) which often airs several seconds earlier or later than the TV feed.

2. **"Good Enough" Sync vs. Perfect Sync:** We don't necessarily need millisecond-perfect, continuous synchronization with the external source. The main issue is the large initial offset (often 5-20 seconds) between TV and radio. The feature would allow the user to manually adjust the TV broadcast delay (e.g., using remote buttons) at the start of an event to get the timing *acceptably close* (e.g., within +/- half a second) to their preferred commentary. This level of sync is achievable and sufficient for enjoyment.

3. **The Core Problem: Jumps/Resets After Signal Interruption:** The biggest obstacle currently, even when trying to use standard Timeshift for this purpose, is that **any temporary signal loss/return causes the playback to jump forward**, losing the carefully set delay. The most critical part of this feature request is finding a way to **maintain the user-set delay offset** and resume playback smoothly at the correct delayed point after a brief signal interruption, rather than resetting towards the live point. If this "jump" issue could be solved, achieving the desired synchronization becomes practical.

4. **RAM Usage vs. Benefit & Existing Examples:** I acknowledge the RAM constraints, especially on lower-spec devices. However, the fact that this exact functionality (RAM-buffered broadcast delay for external sync) **is successfully implemented** on various commercial STBs, including budget-friendly models like Gosat and more advanced ones like Formuler/Icone, suggests that a memory-efficient solution is practically possible. Perhaps the maximum delay could be user-configurable, limited based on available RAM, or the feature could be optional, primarily benefiting users with sufficient hardware resources who have this specific need.

This isn't just a "nice idea"; it addresses a real-world use case for many sports fans who currently struggle with commentary sync. Solving the "jump after interruption" problem while maintaining a user-set delay would be the key breakthrough.

Thank you again for the discussion and your expertise.

Best regards,

Mohamed

[WanWizard]

Didn't someone already make something for this, to combine live F1 with GrandPrixRadio commentary?

[M.Najar]

Subject: Re: Feature Request: RAM-based Video/Audio Delay for external commentary sync

Hi [littlsat],

Just a further thought regarding the implementation and RAM usage concerns for the broadcast delay feature:

I understand that simply allocating large chunks of RAM continuously could be problematic. However, wouldn't a **circular buffer (ring buffer)** approach be suitable here?

My understanding is that a fixed-size ring buffer in RAM could store the last X seconds of the stream. New data overwrites the oldest data, avoiding continuous memory allocation/deallocation. Playback would read from a point within this buffer offset by the desired delay from the write head.

While calculating the appropriate buffer size based on bitrate and desired maximum delay is still necessary, using a circular buffer might be a more memory-efficient and standard way to implement this kind of short-term delay compared to other buffering methods.

Of course, the core challenge of maintaining smooth playback and handling PTS gaps after signal interruptions remains, regardless of using a ring buffer.

Just wanted to share this technical suggestion in case it clarifies the potential implementation method I had in mind.

Thanks,
[Mohamed]

[M.Najar]

Didn't someone already make something for this, to combine live F1 with GrandPrixRadio commentary?

[M.Najar]

The problem is in the synchronization between the live broadcast and the commentary. The commentary is usually delayed because it comes from the Internet, and the traditional time shift is not practical. If the broadcast is interrupted, it jumps to the live broadcast and loses the delay, which makes it impractical.

[littlesat]

You need to delay the video…. When you need that for multiple seconds it ears RAM..
Indeed we had something for formular1 but as always after 5 min or so after long time you get it synchronized it get de-synchronized. You can put hours in development… but it will never be really comfortable. This is not the first idea it is asked here… and also not the first one who tried to get it synchronized (for a few minutes). With a delay you just get it kind of synchronized. But technically impossible to get it really synchronized… due to ‘timing’ jitter between two different streams….(sources)

Edited by littlesat, 23 April 2025 - 15:31.

[M.Najar]

Hi [littlsat],

Thank you again for the feedback. I understand the technical challenges with jitter when trying to achieve *perfect, continuous* sync between two independent live sources.

However, my primary goal (and I believe the goal of many users needing this) is slightly different and perhaps simpler: **I want to apply a *fixed, stable delay* to the incoming broadcast stream itself (Audio+Video together), and critically, have playback *resume at that same fixed delay* after a temporary broadcast interruption.**

For example, if I manually set a 5-second delay using a potential new feature or even existing timeshift, I want playback to always remain consistently 5 seconds behind the actual live point being received by the tuner. My main concern is *not* syncing with an external source, but simply maintaining this chosen fixed delay reliably.

**Implementation Idea & Addressing RAM Concerns:**
Perhaps implementing this using a **circular buffer in RAM** with a **user-configurable (or limited) size** (e.g., starting with a modest default like 50MB, potentially allowing ~40 seconds delay for typical HD streams) could be a feasible approach? This would:
* Keep RAM usage predictable and potentially manageable even on lower-spec devices (for shorter delays).
* Offer faster access compared to HDD-based timeshift.
* Be suitable for the short, fixed delays needed for this purpose.

**The Core Problem Remains: Resumption After Interruption:**
While RAM buffering might be a good implementation method, the core problem we face right now (with current timeshift, and apparently also with plugins like 'ip audio+') is that **after a signal loss and return, the playback *jumps forward* towards the live point**, losing the user-set delay. It doesn't resume playback at `[current live point] - [chosen delay]`.

So, the main request remains: **Is it possible to improve the timeshift/delayed-playback *resumption logic* within Enigma2/GStreamer so that it reliably respects the existing delay offset after a stream interruption, regardless of whether the buffer is in RAM or on HDD?**

Solving this "jump forward after interruption" issue seems key to enabling stable delayed viewing. Is modifying this resumption behavior something the team might consider investigating?

Thanks for your time and insights.

Best regards,

[Mohamed]

[littlesat]

That exactly 5 sec delay is technically not possible as both stream use different time references it cannot be synchronized at all… when you think it is possible to get something really working you’re thinking about a hoax…. It is not only interruption in stream that breaks the ‘law’..it sounds like a good idea but will simply never really be workable.

Edited by littlesat, 23 April 2025 - 17:08.

[M.Najar]

That exactly 5 sec delay is technically not possible as both stream use different time references it cannot be synchronized at all… when you think it is possible to get something really working you’re thinking about a hoax…. It is not only interruption in stream that breaks the ‘law’..it sounds like a good idea but will simply never really be workable.

[M.Najar]

Thanks a lot

[Huevos]

The problem is the audio from the radio is several seconds ahead of the tv signal so you can't get the video signal earlier. The delay needs to be added on the radio.

[Huevos]

Look at SportSync radio.

[M.Najar]

Thank you for your reply and for sharing your insights on the challenges of synchronizing streams with different time references. I appreciate the technical explanation regarding clock drift and the difficulties in achieving perfect, long-term sync between truly independent sources like DVB and an external internet radio stream.

However, I want to clarify that my core requirement, and the primary problem I'm hoping to see addressed, is focused solely on the DVB stream itself – specifically, the ability to apply a configurable delay to the DVB broadcast (its own audio and video, processed together) and to have that delay robustly maintained or re-established after interruptions.

To be very precise, I am NOT primarily asking for a system that automatically and perfectly synchronizes the DVB video with a separate, external, independently clocked audio source.

Instead, my need is simpler (though perhaps still challenging in its own right):

I want the GStreamer pipeline handling the DVB playback to be able to delay the entire DVB media stream (its native audio and video components) by a user-defined amount (e.g., 5 seconds). So, the outputted DVB picture and sound are consistently 5 seconds behind what's being broadcast live.

Crucially, if the DVB stream experiences an interruption (like a softcam decryption stall or brief signal loss) and then resumes, the system should automatically work to re-establish that same 5-second delay for the DVB A/V output. The playback should not just 'catch up' to the live point as quickly as possible, nor should it resume with an arbitrary or minimal delay. It should actively buffer and manage the resumed stream to restore the configured delay.

In this scenario, we are operating within the context of a single primary source (the DVB transport stream) and the GStreamer pipeline's own clocking and buffering mechanisms. The challenge here is not about reconciling two different external clock domains, but about how GStreamer (or the application using it, like Enigma2) manages its internal state and buffering to enforce a consistent, pre-defined latency on its output, especially after data starvation and resumption.

Having this stable, predictable, and resilient delay on the DVB stream itself is the fundamental feature I'm seeking. While this could subsequently make manual synchronization with an external source (which the user would manage) more feasible, the immediate goal is robust delay control for the primary DVB broadcast.

Could you please clarify if this specific scenario – applying and maintaining a resilient delay to the DVB stream's own audio and video – is also what you consider technically unfeasible or a 'hoax'? My understanding was that this might be achievable within GStreamer using appropriate buffering strategies and element configurations, potentially with a dedicated delay element.
Thank you for your time and for helping me clarify my request."

[Huevos]

Looks like you want a personal feature.

[littlesat]

Timeshift can do a delay. No need for gstreamer. But the result will be within a few minutes it is already out of sync. And due to frames in the dvb stream you can’t do it exactly.

[M.Najar]

Timeshift can do a delay. No need for gstreamer. But the result will be within a few minutes it is already out of sync. And due to frames in the dvb stream you can’t do it exactly.

[M.Najar]

Thank you for the ongoing discussion. I need to clarify a crucial aspect of my timeshift usage that might have been misunderstood.
My primary use case for timeshift is not to create very long delays (e.g., many minutes for syncing with external radio commentary). Instead, I rely on timeshift to introduce a very short, precise delay of only a few seconds – typically just 5 to 10 seconds – to the live DVB broadcast.
The core problem I am experiencing is that even this very short, intentionally created delay is completely lost or drastically altered immediately after a temporary interruption in the DVB descrambling process
For example:
I activate timeshift and pause for 5 seconds, then resume playback. I am now watching the DVB stream with a 5-second delay.
A CA-related interruption occurs in the live broadcast.
When the signal and descrambling are restored, my 5-second timeshift delay is often:
Completely gone: Playback jumps directly to the live broadcast point.
Significantly changed: The delay might become 1 second, or some other unpredictable value, instead of remaining close to the original 5 seconds.
I understand the challenges of maintaining millisecond-perfect synchronization over long periods due to clock drift and DVB frame structure, as you've explained. However, my expectation is that for such a short, actively managed delay of only a few seconds, the system should be much more resilient in re-establishing approximately the same delay after a brief interruption. The current behavior of losing or completely scrambling this short delay makes timeshift unusable for my needs