SegmentList nodes are allowed into Period, AdaptationSet or Representation nodes
and there is at most 1 element, so no need to keep a list;
Period nodes cannot have any Represention elements, as AdaptationSet nodes are mandatory;
this breaks compatibility with some legacy DASH test sequences.
gstmpdparser.c: In function ‘gst_mpdparser_get_list_and_nb_of_audio_language’:
gstmpdparser.c:2891: warning: ‘return’ with no value, in function returning non-void
g_ascii_strtoull() returns a long long integer, but we need to
pass a normal int to gst_structure_set() for fields of G_TYPE_INT,
so cast appropriately.
The buffer parameter wasn't being used, it was only to signal if
a buffer was downloaded and advance to the next fragment in the
manifest.
Replace the buffer with a boolean that has the same effect and is
safer
connection setup times seem to matter when measuring the download
rate of different streams. Streams with longer fragments have a
*relatively* lower connection setup time and achieve higher bitrates.
Using the average seems unfair here, so use each stream's measured bitrate
to select its best quality option.
We need to cancel the downloader for each stream before joining the main download task, otherwise
the download task will block until all the stream tasks finish.
When the codec is AAC-LC, some server implementation (e.g. Microsoft IIS) doesn't add the CodecPrivateData attribute. The element needs to re-create the codec data from the Quality Level attributes (channels and sampling rate).
There is no way to know if a live stream is really finished, so try to reload the manifest and check if there are more fragments to download. Else just let know it's the EOS.
Live streams force the demuxer to keep reloading the Manifest from
time to time, as the new fragments are being added as they are recorded.
The demuxer should also try to keep up and detect when it had to skip
fragments, marking the discont flag when that happens.
Curiously, the spec doesn't seem to mention when/how a live stream is supposed
to end, so keep trying downloads until the demuxer errors out.
Use pad tasks to download data and an extra task that gets the earlier
buffer (with the smallest timestamp) and pushes on the corresponding
pad.
This prevents that the audio stream rushes ahead on buffers as its
fragments should be smaller