When identifying the current segment to be played for a live stream, the gst_dash_demux_setup_streams will use the now moment (adjusted with presentationDelay). The gst_mpd_client_seek_to_time function will compute ts_microseconds = g_date_time_difference (time, start) and gst_mpd_client_stream_seek will search the segment corresponding to this ts_microseconds in the presentation timeline.

But the standards defines the availabilityStartTime for a media segment to be at the end of the segment:
"For services with MPD@type='dynamic', the Segment availability start time of a Media Segment is the sum of the value of the MPD@availabilityStartTime, the PeriodStart time of the containing Period as defined in 5.3.2.1, the MPD start time and the MPD duration of the Media Segment."

This leads to adaptive demux waiting for the identified segment to be available.

For a visual scenario, let's consider the following data:
MPD@availabilityStartTime = 12:00:00
suggestedPresentationDelay = 0
Segment templates are uses, there are several segments, each having a duration of 1s. Segment numbers start at 1, so segment 1 is between 12:00:00 and 12:00:01, etc.
Now is 12:00:05.3

Based on now value, ts_microseconds = 5.3 * 1000 * 1000, choosing segment 6 (which is between 12:00:05 and 12:00:06). When trying to play it, the gst_adaptive_demux_stream_download_loop function will use gst_adaptive_demux_stream_get_fragment_waiting_time to determine how much to wait for the segment to be available. In our case, it will be 6-5.3=0.7s

The longer the segment duration, the longer the initial wait period when starting to play a live stream.

Question: shouldn't gst_dash_demux_setup_streams function try to choose the latest available segment (the segment previous to the one it currently identifies)? That would save the waiting time.

Also, do notice that if suggestedPresentationDelay is not 0, the identified segment is already available on the server so gst_adaptive_demux_stream_download_loop will not wait and playback will start immediately, violating the suggestedPresentationDelay which is not observed entirely.