The start of each segment is relative to the Period start, minus
the presentation time offset.
As specified in section 5.3.9.6 of the MPEG DASH specification:
The value of the @t attribute minus the value of the
@presentationTimeOffset specifies the MPD start time of
the first Segment in the series.
dashdemux was not taking account of presentationTimeOffset and in
some methods was not taking into account the Period start time.
This commit modifies the segment->start value to always be
relative to the MPD start time (zero for VOD,
availabilityStartTime for live streams). This makes all uses of
the segment list consistent.
Fixes#841
If we renegotiate, then it is currently possible for an added stream to
be added to webrtcbin before the SDP is complete. This causes an
internal inconsistency as there is a 'pending sink transceiver' without
a corresponding media section in the sdp. It also does not have an
associated transport stream and will fail in _connect_input_stream().
If both data channels become ready simultaneously, then the two integer
read-add-update cycles can execute concurrently and only ever increment
once instead of the required twice. Use an atomic add instead.
Limitations:
- No transport changes at all (ICE, DTLS)
- Codec changes are untested and probably don't work
- Stream removal doesn't remove transports (i.e. non-bundled transports
will stay around until webrtcbin is shutdown)
- Unified Plan SDP only. No Plan-B support.
We add the signal watch in testSeekPreTestCallback so
remove it in testSeekPostTestCallback and not deep inside
some if clause in some other callback somewhere.
Based upon the souphttpsrc tests, add unit tests for the curlhttpsrc
element. The souphttpsrc tests are able to use an HTTP server that
is provided as part of the soup library. This does not exist in the
curl library, therefore these tests provide a very simple HTTP server
using the GIO library.
These curlhttpsrc tests contain one new test that does not come from
the souphttpsrc tests. The test_multiple_http_requests test tries to
reproduce the way in which GstAdaptiveDemux makes use of URI source
elements. GstAdaptiveDemux creates a bin with the httpsrc element
and a queue element and sets the locked state of that bin to TRUE,
so that it does not follow the state transitions of its parent. It
then moves this bin to the PLAYING state to start each download and
back to READY when the download completes.
The VCD source was ported in 2014 (commit 89eb1e9), but the necessary
"cdxaparse" plugin, which is used to "Parse a .dat file (VCD) into
raw mpeg1" was never ported.
This means that the probable main user for the feature, totem, hasn't
actually been able to play back VCDs, since 2012, when it switched to
using GStreamer 1.0.
Note that even if cdxaparse was finally ported, a lot of work would
still be necessary before it is considered usable. Notably, it is
missing disc image support [1] and some VCDs just cannot be opened for
reading [2].
[1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/898
[2]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/899
Allow fallback to orc subproject if any, and add missing orc version check.
Additionally 'dependencies' keyword is removed from find_library,
because it's invalid keyword for find_library.
Allow run some unit tests on Windows.
* Add dependency explicitly for some test cases, otherwise plugins couldn't be
loaded on uninstalled environment of Windows.
* Add missing GST_PLUGIN_LOADING_WHITELIST on meson build.
This is for testing race condition with multi-thread wayland client
environment. The race condition will be resolved with wayland proxy
wrapper API when handling event queue.
It depends on the framerate how many cc_data byte pairs are allowed per
frame, and the framerate is also needed for converting into the CDP or
MCC format as the framerate is part of the header metadata.
