Play live video delay

[Lachrista]

1、Cannot play when the first frame data is I-frame 2、There is a delay in playing the video in real time, almost 2 seconds delay, but I can't find out where the problem is.

[samirkumardas]

1. Rather it should start quickly if it get first frame as I-frame. Please be assured you provided data was valid. If you have any demonstration URL, let me know.

2. Look likes server side latency. Usually it takes few seconds to encode video to h264 from the time of capturing. In jMuxer side, it can incur max 0.5 second delay.

[Lachrista]

1.The first question will not be discussed for the time being, I will go looking for the reason again. 2.In jMuxer side, If the dts is shortened, the delay will be resolved with a high probability, but the time spent per frame is shortened， causing inconsistency in playback.

[samirkumardas]

Do you have static or variable fps? Can you share your jmuxer initialisation code?

[Lachrista]

static static

var ws; var socketURL = 'ws://192.168.2.134:554/ms/webstream/ch_100'; var url = '/ms/webstream/ch_100';

var jmuxer = new JMuxer({ node: 'h264player1', mode: 'video', flushingTime: 1, fps: 25, debug: true });

ws = new WebSocket(socketURL);

ws.onopen = function(event){ ws.binaryType = 'arraybuffer'; ws.send(url); }; ws.onmessage = function(event){ var data = new Uint8Array(event.data, 88, event.data.byteLength-88); jmuxer.feed({ video: data }); }; ws.onclose = function(event){ console.log("The server disconnects automatically."); }; ws.onerror = function(event){ console.log("error"); };

[samirkumardas]

So frame duration is 40ms. Is this correct?
Look likes your fps is wrong. In case of live streaming, usually fps is variable. In case of dynamic fps, you must provide chunk duration from server with steaming data to minimise latency.

If you provide wrong fps, it will make latency longer gradually over the time.

[Lachrista]

In fact, I have found that fixed fps may be the main cause of delay, but I can't calculate the frame rate of the real-time stream. I can only calculate the dts based on the timestamp of each frame, so the dts drop is a dynamic value, but even In this way, it will still delay, and even lead to the flower screen.

[snowfrogdev]

@samirkumardas First, let me thank you for this wonderful little library. I have been struggling for almost a month with trying to get the raw h.264(main) feed from my Tello drone to display in the browser. jmuxer is the best solution I have found so far.

I am also experiencing a bit of a delay, but really not all that much (about 300 ms) and would like to cut down on that, if at all possible. If I could get it down to around 100 ms it would be awesome. I'm interested in what you said:

In case of live streaming, usually fps is variable. In case of dynamic fps, you must provide chunk duration from server with steaming data to minimize latency.

If you provide wrong fps, it will make latency longer gradually over the time.

Can you explain how to do that. At the moment, I'm pretty much just passing along the buffers I'm receiving over UDP straight to jmuxer. Here are the options I have set:

const jmuxer = new JMuxer({
  node: 'player',
  mode: 'video',
  flushingTime: 1
});

Anything you can suggest that will help me shave off a bit of delay will be appreciated.

[samirkumardas]

Thank you @Neoflash1979. Glad to know it that you've found it helpful.

1. First, be sure the delay is not the network latency or server side latency.

2. 300ms delay sounds quite good to me. I am assuming you do not provide chunk duration during buffer feed so it is running on static fps. Since you have't provided any frame rate at the time of jmuxer instantiation, it could be a cause of making some delay because jmuxer consider fps 30 by default. Therefore, you can define your frame rate during jmuxer instantiation if you know it exactly Or try changing a different fps.

  const jmuxer = new JMuxer({ 
        node: 'player',
        mode: 'video',
        fps: 25,
        flushingTime: 1
   });