dashdemux issues with live profile and segment timeline

Description:

When decoding live DASH service, almost only the lowest bitrate representation is used
When (in rare cases) switched to higher bitrate for one segment, the segment afterwards is from lowest bitrate again. But in this case no init-segment is sent to decoder which causes video artefacts from this time on.

I know, there are some other issues regarding DASH in the bug list (#891, #575 (closed)) but they do not really match our problem here. This problem only occures on "Live profile" (MPD update) and "Segment Timeline".

Details:

Originary we found this issue on our embedded device (using GStreamer version 1.20.3) with a stream from public TV broadcaster. I don't know, if I'm allowed to share this stream. So I've created own tream using ffmpeg producing the same problem. It also can be reproduced using Ubuntu and V1.16.3.

While debugging on our embedded device, we found it is related with manifest update. Generally the last segment defined in the timeline is played all the time (we are live") and this causes EOF returned when dashdemux is trying to advance segment. Then the dashdemux waits for manifest update and after the update the playback is continued with lowest bitrate.

When, in rare cases, the "second to last" segment is send, the bitrate update is working and higer bitrate representation is used. But after manifest update, again the lowest bitrate is selected. In this case for some reason no init segment is sent.

Steps to reproduce

Server side

Install a HTTP server
Extract the attached packet (dash-live-test.tar.gz) to a location accessible via HTTP server.
In this directory enter the following command

ffmpeg -re \
  -stream_loop -1 -i video/640x360-h264.mp4 \
  -stream_loop -1 -i video/1280x720-h264.mp4 \
  -stream_loop -1 -i video/1920x1080-h264.mp4 \
  -stream_loop -1 -i audio/pingpong.wav \
  -map 0 -map 1 -map 2 -map 3 -c:a libfdk_aac -c:v copy \
  -use_timeline 1 -use_template 1 \
  -init_seg_name 'media/init-$RepresentationID$.mp4' \
  -media_seg_name 'media/media-$RepresentationID$-$Number%05d$.m4s' \
  -window_size 8 -seg_duration 4 -adaptation_sets "id=0,streams=v id=1,streams=a" \
  -remove_at_exit 1 \
  -metadata title="Metz AV-Sync Test Stream" \
  -f dash test-live.mpd

Client side

Use the following command to decode the stream: (URL must match to your server location, see above)

gst-play-1.0 http://192.168.0.252/media/dash/live1/test-live.mpd

You can see, that only the 640x360 streams is played
To enforce a resolution switch, use the "left arrow" key to jump back one second.

Additional info

I've tried to find the problem myself, but failed miserably. Maybe someone can give me a few pointers as to where to look. Above all, how the bitrate update should theoretically work in our special case, because the new manifest turns every settings to the beginning.

Admin message