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.
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 the same reason as the dash tests. This should ideally
be converted to gst-validate tests. These tests randomly timeout also
due to the tests doing seeks from the streaming thread (sic).
We used to have the same enum to represent H265 profiles and idc values.
Those are no longer the same with extension profiles defined from
version 2 of the spec.
Split those enums so the semantic of each is clearer and we'll be able
to add extension profiles to GstH265Profile.
Also add gst_h265_profile_tier_level_get_profile() to retrieve the
GstH265Profile from the GstH265ProfileTierLevel. It will be used to
implement the detection of extension profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=793876
SDP's are generated and consumed according to the W3C PeerConnection API
available from https://www.w3.org/TR/webrtc/
The SDP is either created initially from the connected
sink pads/attached transceivers as in the case of generating an offer or
intersected with the connected sink pads/attached transceivers as in
the case for creating an answer. In both cases, the rtp payloaded streams
sent by the peer are exposed as separate src pads.
The implementation supports trickle ICE, RTCP muxing, reduced size RTCP.
With contributions from:
Nirbheek Chauhan <nirbheek@centricular.com>
Mathieu Duponchelle <mathieu@centricular.com>
Edward Hervey <edward@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792523