If end_tc is NULL, it means that we don't want avwait to stop at any
timecode. When explicitly setting end_tc to NULL, there is no point in
comparing end_tc with start_tc (to see if we'll reject end_tc for being
before start_tc), so the check in question is completely disabled
instead of letting it crash.
Add support for parsing linear time code from
an audio source using libltc
https://github.com/x42/libltc
The user can now choose between 3 different and independently
running timecode sources. The old override-existing property
has been replaced by timecode-source.
https://bugzilla.gnome.org/show_bug.cgi?id=784295
This element can be configured to add jitter and/or drift to incoming
buffers' PTS, DTS, or both. Amplitude and average of jitter and drift
are configurable.
https://bugzilla.gnome.org/show_bug.cgi?id=787358
When we receive a video or audio buffer, we calculate the next stream
time based on the current stream time + buffer duration. If the next
buffer's stream time is after that, we issue a warning.
This happens because the stream time incoming from Decklink should be
really constant and without gaps. If there is a gap, it means that
something went wrong, e.g. the internal buffer pool is empty (too many
buffers queued up downstream).
https://bugzilla.gnome.org/show_bug.cgi?id=781776
When switching bitrates we set the old streams as cancelled, but it
could also be confused with a cancel due to other reasons (as an error)
and it would lead the element to stop the pipeline mistankely. This
would happen when the stream being replaced was waiting for a manifest
update on live. Ss make it sure that we are stopping for switching
bitrates to avoid erroring out.
https://bugzilla.gnome.org/show_bug.cgi?id=789457
avwait can now be configured to stop when a given timecode has been
reached. It will start at the timecode indicated with start-timecode and
end at the timecode indicated with end-timecode. If end-timecode is
NULL (default), the previous functionality is preserved: keep going and
not end.
https://bugzilla.gnome.org/show_bug.cgi?id=789403
If we're adding to the tail of the queue, it's because we're converting
a gap event, so don't block there it means we're calling from the output
thread.
https://bugzilla.gnome.org/show_bug.cgi?id=784911
OpenJPEG 2.3 installs its headers to /usr/include/openjpeg-2.3. However,
since libopenjp2.pc seems to provide the right includedir CFLAGS at
least since version 2.1, instead of adding yet another version check,
just remove the subdir and the check for 2.2.
https://bugzilla.gnome.org/show_bug.cgi?id=788703
Unfortunately we need to use an extra set of parenthesis for each data level.
For details see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
Affected versions are e.g.
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
which is the default on ubuntu-trusty. I looks like the fix was never
backported.
It is legal for a stream to reuse segments (marking discontinuities as
needed). Uplynk delivers such playlists for their placeholder loops.
Leave the URI scanning in place for playlists which have no
EXT-X-MEDIA-SEQUENCE tag. This should be harmless since the spec
requires these playlists to not be missing segments (RFC8216 6.2.2),
so we should be always matching on the first segment.
https://bugzilla.gnome.org/show_bug.cgi?id=788417
