Hi, i'm currently testing and validating a DASH live streaming solution over Akamai CDN using the DASH mediapm.edgesuite.net player (Akamai Dash Diagnostic Player ) and the player is unexpectedly freezing after a random period of time.
The root cause of the freeze is an HTTP 404 error when trying to download the current segment. Only a player restart allows recovering live edge.
We can see before the freeze that the player progression bar going progressively backwards up to be out of the buffer range.
Player time synchronization is key with DASH as the requested segment must always correspond to the live edge minus 1 or 2 segments (may be more depending of the player):
requested_segment = startNumber_mpd + (Player_current_time - availabilityStartTime_mpd) / duration_mpd
When I use in parallel another player such as the bitmovin one (http://bitmovin.com/hls-mpeg-dash-test-player/) I don’t reproduce such freeze, seems that that player is able to keep synchronize with Live edge all the time, probably using another mechanism.
Using the network sniffing feature of the web browser I can see at the same time that the bitmovin player is requesting for example the segment_number_1000 whereas the mediapm.edgesuite.net player is requesting the segment_number_980 up to be out of the buffer range.
The live encoder is in my lab and is properly NTP synchronized.
So for me either the player relies on the PC clock, so this one would have to be at least NTP synchronized, either the player itself runs another mechanism to get synchronized.
It seems that the mediapm.edgesuite.net player use the UTC time provided by the time.akamai.com server. Is that true? Is there a specific mechanism in the Akamai DASH test player to calculate the current segment using that time.akamai.com discarding PC clock ?