varying segment duration

[pilgrimage1112]

I want to know whether livesim2 supports dynamic changes in media segment duration during playback?If supported, how to solve the overlap problem due to different media segment duration during switching?

[tobbee]

At present, all segment and sample durations are fixed during a session. The master for segment durations is the video segment durations of the input asset. The audio segments are adjusted to start at the same time or within one audio sample duration after the video segment starts. There is never any overlap in timeline between segments. If the total audio duration for audio is longer than video, the last audio segment is truncated to end just at or after the video. If ending after, there is slight shift in audio compared to video in the next loop, but it is tracked so that it is removed as soon as possible, and there is no long-time AV sync drift.

[pilgrimage1112]

Thanks for your answer!! I have a few more questions that I hope to get your answers to.

1. Why does the livesim2 implement the re-fragment that I mentioned in the issue?
2. What is the purpose of re-fragment?
3. Can re-fragmentation dynamically split segments during playback due to network fluctuations, allowing smaller chunks to be transmitted to the client first?

[tobbee]

The way Low-Latency DASH work is to build and send segments before they are finished. The way to do that is to write chunks and then send the segments as stream using HTTP chunked transfer encoding. A chunk is different from a segment in the sense that it does not need to start with an I-frame. The minimal delay is essentially given by the chunk duration and is a fixed value in all DASH implementation as far as I know (the value is not specified in the standard but is essentially segment duration - availabilityTimeOffset).

DASH is meant for mass-distribution of the same content to many clients, so the server is not doing any special content adaptation depending on network conditions. The server is essentially just serving whatever segments the clients request via HTTP. The clients can choose what bitrate to choose and also to interrupt a reception if it is too slow. livesim2 is meant to work like a normal DASH server, but can produce many variations of the content provided so that one can experiment with timing behaviour. Each session has fixed parameters, though.

There are some new development around MOQ (Media over QUIC) where the different chunks can be sent with different priorities which means that the client can prioritise delay over quality.

[pilgrimage1112]

Thank you so much! Your answer helped me learn a lot about LL-DASH. I would like to continue to understand the following questions about livesim2:

1. Is livesim2 able to support LL-DASH mode as it supports DASH?

2. If it is supported, how should I enable LL-DASH mode for live simulation?

I would be very grateful if I could get your timely reply.

[tobbee]

Yes, low latency is supported and configurable in various ways. Low-latency is mention in the second sentence on https://livesim2.dashif.org so I am a bit surprised about the question.

I recommend to use the URL generator page at https://livesim2.dashif.org/urlgen/, or the corresponding page on your local instance,set the parameters of the low-latency section. You should typically set the availabilityTimeOffset + the chunk duration to the same as the segment duration.

For example, for testpic_2s which has 2s segments, you can set the availabilityTimeOffset to 1.5s and the chunk duration to 0.5s, like in the following URL: https://livesim2.dashif.org/livesim2/ato_1.5/chunkdur_0.5/testpic_2s/Manifest.mpd