Moved gst_mpd_client_get_next_segment_availability_end_time and
gst_mpd_client_add_time_difference functions to be grouped with
functions from the same category.
https://bugzilla.gnome.org/show_bug.cgi?id=752027
Corrected the initialisation of mimeType in
gst_mpdparser_get_list_and_nb_of_audio_language: the variable is used
in a loop, so it must be set to NULL at the beginning of each iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=751911
Introduced by c4c9fe60b pcapparse: Take buffer directly from the adapter
Using gst_adapter_take_buffer_fast() can lead to buffers that are
made up of multiple memories with the first memory smaller than the
RTP header size, which violates assumptions GstRtpBaseDepayloader
makes, namely that the complete RTP header will be in the first
memory. This leads to such packets being dropped when feeding
them from pcapparse to RTP depayloaders. Use take_buffer() so
we get buffers with a single memory.
Introduced by c4c9fe60b pcapparse: Take buffer directly from the adapter
Flush any trailing bytes after the payload from the adapter as well,
otherwise we'll read a bogus packet size from the adapter next and
then everything goes downhill from there.
https://bugzilla.gnome.org/show_bug.cgi?id=751879
Before returning the next fragment duration value, the
gst_mpd_client_get_next_fragment_duration function tries to validate it.
But the condition was incorrect.
https://bugzilla.gnome.org/show_bug.cgi?id=751539
Segment start/time/position/base should only be modified if this is the first
time we send a segment, otherwise we will override values from the seek
segment if new streams have to be exposed as part of the seek.
Segment base should be calculated from the segment start based on the stream's
own segment, not the demuxer's segment. Both might differ slightly because of
the presentationTimeOffset.
Always add the presentationTimeOffset (relative to the period start, not
timestamp 0) to the segment start after resetting the stream's segment based
on the demuxer's segment (i.e. after seeks or stream restart). Also make sure
to keep the stream's segment up to date and not just send a new segment event
without storing the segment in the stream.
https://bugzilla.gnome.org/show_bug.cgi?id=745455
We're interested in the offset between the period start timestamp and the
actual media timestamp so that we can properly correct for it. The absolute
presentation offset to timestamp 0 is useless as the only thing we really
care about is the offset between the current fragment timestamp and the
media timestamp.
Otherwise we will look for segments after the period usually. The seek
timestamp is relative to the start of the first period and we have to
select a segment relative to the current period's start.
We didn't do this for fragments that are generated on demand from a template,
only for the other cases when they were all generated upfront. This caused
fragment timestamps to start from 0 again for each new period.
If not set, the timeShiftBufferDepth has a default value of -1.
The standard says that this should be interpreted as infinite.
The gst_mpd_client_check_time_position function incorrectly compares
timeShiftBufferDepth with 0 instead of -1 to determine if it was set.
https://bugzilla.gnome.org/show_bug.cgi?id=751500
CMBlockBufferGetDataLength would return the entire data length, while
size of individual blocks can be smaller. Iterate over the block buffer
and add the individual (possibly non-contiguous) memory blocks.
https://bugzilla.gnome.org/show_bug.cgi?id=751071
The last parameter of gst_mpd_client_add_media_segment function is a
duration. But when called from gst_mpd_client_setup_representation, the
last argument was wrongly set to PeriodEnd
https://bugzilla.gnome.org/show_bug.cgi?id=751449
The period start information, calculated in gst_mpd_client_setup_media_presentation
function is stored in stream_period->start. The information read from
xml file and stored in stream_period->period->start is not changed.
If the xml file does not contain the period start information,
stream_period->period->start will be -1.
The function gst_mpd_client_get_next_segment_availability_end_time wants to
use period start time, but incorrectly uses stream_period->period->start
(value from xml file, which could be -1) instead of stream_period->start
(computed value)
https://bugzilla.gnome.org/show_bug.cgi?id=751465
