Low latency live streaming segment duration issue

[aelgend]

On dash.js version 4.7.4, I am trying to simulate low latency live streaming on different network conditions. The issue I am seeing is a lot of stalling happening (PLAYBACK_WAITING/BUFFER_EMPTY events getting fired) when having segment durations over 2s. Since I have 0.5s chunks, I believe that such stalling shouldn't happen as often since the buffer should be updated regularly.

I am trying to understand why such behavior is happening. It seems to me that the frag_duration flag I use in the ffmpeg command doesn't have any effect on playback.

I am targeting a liveDelay of 2s and playBackRate of ±0.3. The following is the ffmpeg command I am using:

ffmpeg \
-re -i video.mp4 \
-c:v libx264  \
-b:v:0 200k -s:v:0 320x180 -r:v:0 30 \
-b:v:1 600k -s:v:1 480x270 -r:v:1 30 \
-b:v:2 800k -s:v:2 640x360 -r:v:2 30 \
-b:v:3 1500k -s:v:3 768x432 -r:v:3 30 \
-b:v:4 2500k -s:v:4 1024x576 -r:v:4 30 \
-b:v:5 4000k -s:v:5 1280x720 -r:v:5 30 \
-map 0:v -map 0:v -map 0:v -map 0:v -map 0:v -map 0:v \
-adaptation_sets id=0,seg_duration=2,frag_duration=0.5,streams=0,1,2,3,4,5 \
-use_timeline 1 \
-use_template 1 \
-frag_type duration \
-g:v 60 -keyint_min:v 60 -sc_threshold:v 0 -ldash 1 \
-f dash \
manifest.mpd

I have also attached the mpd file that gets generated while the ffmpeg command is running.
live_mpd.txt

I would really appreciate it if someone could point me in the right direction.

[dsilhavy]

I had a quick look and it looks like your MPD is missing an @availabilityTimeOffset. Without the @availabilityTimeOffset the player does not know how much earlier to start fetching the segment compared to its “common” availability time. From the spec:

The availabilityTimeOffset specifies an offset to define the adjusted segment availability time. The value is
specified in seconds, possibly with arbitrary precision. The offset provides the time how much earlier these segments are available compared to their computed availability start time for all Segments of all associated Representation.

For reference, a stream from the DASH-IF Livesim2: https://livesim2.dashif.org/livesim2/chunkdur_1/ato_7/testpic4_8s/Manifest300.mpd.

Since you are aiming for 0.5 seconds chunks the availabilityTimeOffset should be 1.5 seconds in your case.

[aelgend]

Thanks @dsilhavy for your response. I added the @availabilityTimeOffset to the mpd file by setting -use_timeline to 0. However, now I see a lot of failing requests for the segments/chunks which eventually leads to the stream stopping. Those segments/chunk weren't generated yet based on what I am seeing.

I am using https://gitlab.com/fflabs/originjs as my server and my ffmpeg command speed is above 0.9x so, I am not sure what can be enhanced to prevent this from happening.

This is a screenshot of the ffmpeg command running:

And this is the new mpd getting generate:
live_mpd.txt

Do you have any insights on what I might be doing wrong or how I can improve the process?

[dsilhavy]

No direct insights but some starting points:

• Do you see dash.js using the Fetch API for segment requests and is the Transfer-Encoding header set to chunked? For low latency streaming to work the player and the server need to do chunked transfer encoding
• There is a ffmpeg command builder by Akamai that might help to verify your ffmpeg command: https://moctodemo.akamaized.net/tools/ffbuilder/#
• Try encoding only a single bitrate for now to see if this fixes the problem. It might be a performance issue on the encoding/packaging machine

[aelgend]

I checked and I don't see Transfer-Encoding header at all. However, I also checked the sample live stream in dash.js and used both the default manifest given in the sample as well as the manifest you shared with me from livesim2 and I don't see that header either. I am using Google Chrome.
I tried the other two suggestions as well, but I am still seeing the same behavior.