Discussions

Hi D-ID team,
I’m integrating your streaming API with a WebRTC video pipeline for a conversational avatar app. I’ve instrumented my code to measure latency at each step. Here’s what I observe:
D-ID API call (POST /talks/streams/{streamId}):

The time from sending the request to receiving the response is typically ~1.4 seconds.
Video Render (D-ID to playing):

After the D-ID API responds, there is an additional delay of ~2.1 seconds before the video actually starts playing in the browser (i.e., the video element fires the playing event).

My questions:
What causes this additional delay after the D-ID API responds?

• Is it due to backend processing, WebRTC negotiation, buffering, or something else?
• Is there a way to reduce this delay?
  For example, can I optimise the video stream settings, or is there a recommended way to minimize browser-side buffering?
• Is the D-ID API response sent only after the video stream is fully ready, or is there a staged process?
  (i.e., does the API respond as soon as the stream is available, or only after some initial buffering?)

Technical context:
I keep the WebRTC connection alive between requests.
The delay is measured from the time the D-ID API call finishes to when the browser starts playing the video.
The video is rendered in a element using the WebRTC stream provided by your API.
Sample timings:

OpenAI: ~700 ms
D-ID: ~1410.50 ms
Video Render (D-ID to playing): 2156.40 ms

Any insight into this “Video Render” delay and how to optimise it would be greatly appreciated!

Thank you!

Karthik