Weak refs don't quite work here correctly as there is always a race with
taking the lock between find_view() and remove_view(). If find_view()
returns a view that is going to removed by remove_view() then we have an
interesting situation.
In theory, the number and type of views for an image are relatively
constant and should not change one they've been set up which means that
it is actually practical to perform pool-like reference counting here
where the image holds a pool of different views that it can give out
as necessary.
Current code would change any non-ok return from gst_pad_push to
GST_FLOW_ERROR, thus hiding meaningful returns such as GST_FLOW_EOS.
Tests also added.
Exposure mode property, extra colour tone values (aqua, emboss, sketch, neon), extra scene modes (backlight, flowers, AR, HDR).
Missing vmethods for exposure mode, analog gain, lens focus, colour temperature, min & max exposure time
Contribs by Mohammed Sameer <msameer@foolab.org>, Adam Pigg <adam@piggz.co.uk>
To allow curlhttpsrc to support DASH streams that use the on-demand
profile, it needs to support HTTP Range GETs. In GStreamer, the RANGE
is specified by issuing a GST_FORMAT_BYTES seek to set the start and
end of the range. curlhttpsrc needs to implement seek and set the
appropriate curl options to make it add the Range header to the
request.
Sometimes, one wants to force a clock on some pipelines - for instance,
when testing TSN related pipelines, one usually uses GstPtpClock or
CLOCK_REALTIME (assuming system realtime clock is in sync with network
one). Until now, one needs to write an application for that - not
difficult, but quite boring if one just wants to test something. This
patch presents a new element to help that: clockselect.
clockselect is a pipeline with two properties to select a clock. One
property, "clock-id", enables one to choose between "monotonic",
"realtime", "ptp" or "default" clock - where default keeps pipeline
behaviour of choosing a clock based on its elements. The other property,
"ptp-domain" gives one the choice of which PTP domain should be used.
Some very simple tests also added for this new element.
x265 does not allow user to configure a picture size smaller than
at least one CU size, and maxCUSize must be 16, 32, or 64.
Therefore, the CU size must be set according to the input resolution,
and the input resolution can not be less than 16.
... and add our stub cuda header.
Newly introduced stub cuda.h file is defining minimal types in order to
build nvcodec plugin without system installed CUDA toolkit dependency.
This will make cross-compile possible.
... and put them into new nvcodec plugin.
* nvcodec plugin
Now each nvenc and nvdec element is moved to be a part of nvcodec plugin
for better interoperability.
Additionally, cuda runtime API header dependencies
(i.e., cuda_runtime_api.h and cuda_gl_interop.h) are removed.
Note that cuda runtime APIs have prefix "cuda". Since 1.16 release with
Windows support, only "cuda.h" and "cudaGL.h" dependent symbols have
been used except for some defined types. However, those types could be
replaced with other types which were defined by "cuda.h".
* dynamic library loading
CUDA library will be opened with g_module_open() instead of build-time linking.
On Windows, nvcuda.dll is installed to system path by CUDA Toolkit
installer, and on *nix, user should ensure that libcuda.so.1 can be
loadable (i.e., via LD_LIBRARY_PATH or default dlopen path)
Therefore, NVIDIA_VIDEO_CODEC_SDK_PATH env build time dependency for Windows
is removed.
This patch adds the infrastructure to test AVTP plugin elements. It also
adds a test case to check avtpaafpay element basic functionality. The
test consists in setting the element sink caps and properties, and
verifying if the output buffer is set as expected.
It's been replaced by NVENC/NVDEC and even NVIDIA doesn't
support VDPAU any longer and hasn't for quite some time.
The plugin has been unmaintained and unsupported for a very
long time, and given the track record over the last 10 years
it seems highly unlikely anyone is going to make it work well,
not to mention adding plumbing for proper zero-copy or
gst-gl integration.
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/828
This is a re-implementation of the RTP elements that are submitted in
2013 to handle RTP streams. The elements handle a correct connection
for the bi-directional use of the RTCP sockets.
https://bugzilla.gnome.org/show_bug.cgi?id=703111
The rtpsink and rtpsrc elements add an URI interface so that streams
can be decoded with decodebin using the rtp:// interface.
The code can be used as follows
```
gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay config-interval=3 ! rtpsink uri=rtp://239.1.1.1:1234
gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay config-interval=1 ! rtpsink uri=rtp://239.1.2.3:5000
gst-launch-1.0 rtpsrc uri=rtp://239.1.2.3:5000?encoding-name=H264 ! rtph264depay ! avdec_h264 ! videoconvert ! xvimagesink
gst-launch-1.0 videotestsrc ! avenc_mpeg4 ! rtpmp4vpay config-interval=1 ! rtpsink uri=rtp://239.1.2.3:5000
gst-launch-1.0 rtpsrc uri=rtp://239.1.2.3:5000?encoding-name=MP4V-ES ! rtpmp4vdepay ! avdec_mpeg4 ! videoconvert ! xvimagesink
```
rtpmanagerbad: add pkg-config
rtpmanagerbad: Rtp should be uppercase
rtpmanagerbad: add G_OS_WIN32 for shielding unix headers
rtpmanagerbad: remove Since from documentation
rtpmanagerbad: rename lib name from nrtp to rtpmanagerbad
rtpmanagerbad: sync meson.build with other modules
rtpmanagerbad: add Makefile.am
rtpmanagerbad: use GstElement to count pads
rtpmanagerbad: use gst_bin_set_suppressed_flags
rtpmanagerbad: check element creation
rtpmanagerbad: post message when trying to access missing rtpbin
rtpmanagerbad: return FALSE with g_return tests
rtpmanagerbad: use gsocket multicast check
rtpmanagerbad: use gst_caps_new_empty_simple iso gst_caps_from_string
rtpmanagerbad: sync with gstrtppayloads.h
rtpmanagerbad: correct media type X-GST
rtpmanagerbad: test if a compatible pad was found
rtpmanagerbad: remove evil copy of GstRTPPayloadInfo
rtpmanagerbad: add gio_dep to meson
rtpmanagerbad: revert to old glib boilerplate
GStreamer 1.16 does not yet support the newer GLib templates, so revert.
rtpmanagerbad: return GST_STATE_CHANGE_NO_PREROLL for live sources
for live sources, NO_PREROLL should be returned for PLAYING->PAUSED and
READY->PAUSED transitions.
rtpmanagerbad: use GstElement pad counting
rtpmanagerbad: just use template name to request pad
rtpmanagerbad: remove commented code
rtpmanagerbad: use funnel to send multiple streams on one socket
rtpmanagerbad: avoid beaches
beaches should only be used during the summer, so rewrite the code to
return explicitly and avoid beaches during the winter.
rtpmanagerbad: add copyright to test code
rtpmanagerbad: g_free is NULL safe
rtpmanagerbad: do not trace rtpbin
rtpmanagerbad: return NULL explitly
rtpmanagerbad: warn when data port is not even
According to RFC 3550, RTP data should be sent on even ports, while RTCP
is sent on the following odd port.
rtpmanagerbad: document port allocation in rtpsink/src
rtpmanagerbad: improve uri description
rtpmanagerbad: add comment re-use socket
rtpmanagerbad: rename gst_object_set_properties_from_uri_query
rtpmanagerbad: loan prop/val setter from rist
rtpmanagerbad: rtpsrc: fix unitialised pointer
rtpmanagerbad: fix silly typo
rtpmanagerbad: test for empty key/value
rtpmanagerbad: rtpsrc: deprecate ssrc collision to INFO
rtpmanagerbad: sync debug with rist
rtpmanagerbad: small strings allocated on stack
rtpmanagerbad: correct rename
rtpmanagerbad: add locking on prop setters/getters
Locking is added because the URI allows to access the properties too.
rtpmanagerbad: allow for RTCP through NAT
rtpmanagerbad: move gio to header file
rtpmanagerbad: free small strings too
rtpmanagerbad: ttl_mc for ttl on dynudpsink
rtpmanagerbad: add comments on the URI registered
rtpmanagerbad: correct macro after file rename
rtpmanagerbad: code style
rtpmanagerbad: handle wrong URIs in setter
rtpmanagerbad: nit URI notation correction
In an URI, the first key/value pair should not have an ampersand, the
parser did not die though.
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.
Several tests use a Period@start value of 10 seconds, which either
needs to be taken into account when calculating expected timestamps
or have that attribute removed.
This commit uses a mix of updating the timestamps and removing the
start attribute, so that both the case of its presence and absence
is tested.
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.
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.
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).
With prenegotiated channels, the data-channel protocol is not used and
instead the channel's negotiation is intended to be performed out of band in
some application-specific manner.
Comes with test!
This means that we will reject all operations before we've transitioned
into READY.
This also fixes the tests using the default GMainContext in the NULL
state instead of the webrtcbin internal GMainContext and thread. Also
removes a potential ordering race where on the element transitioning to
READY, an operations could have been queued on two different threads and
removing a guarentee on operation ordering.
It works like a valve in front of the actual avwait. When recording ==
TRUE, other rules are then examined. When recording == FALSE, nothing is
passing through.
https://bugzilla.gnome.org/show_bug.cgi?id=796836
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
Try prioritizing downstream's caps over upstream's if possible so the
parser can configured in "passthrough" if possible and save it from
doing useless conversions.
https://bugzilla.gnome.org/show_bug.cgi?id=790628
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.
Remove gst_init() from a few tests. Use _OBJECT variants in logging. Remove
arbitrary extra blank lines. Make push_event() more like push_buffer() - set
the event to NULL and add cleanup to _chain_data_clear().
Using two (or more) probes on the same pad where one of the probe
returns HANDLED or DROP is tricky since the other probes might
not be called.
Instead use regular probes and a proper pad (the sinkpad already existed,
it only required to be activated and have a dummy chain function for
the events/buffers to be received/handled properly)
In most cases we want to stop the pipeline just once, but we have
to do this from code that runs in the streaming threads and in case
we have multiple streams, we need to make sure that we do this only
once. The previous checks were broken, this should fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=786006
Except for gst/gl/gstglfuncs.h
It is up to the client app to include these headers.
It is coherent with the fact that gstreamer-gl.pc does not
require any egl.pc/gles.pc. I.e. it is the responsability
of the app to search these headers within its build setup.
For example gstreamer-vaapi includes explicitly EGL/egl.h
and search for it in its configure.ac.
For example with this patch, if an app includes the headers
gst/gl/egl/gstglcontext_egl.h
gst/gl/egl/gstgldisplay_egl.h
gst/gl/egl/gstglmemoryegl.h
it will *no longer* automatically include EGL/egl.h and GLES2/gl2.h.
Which is good because the app might want to use the gstgl api only
without the need to bother about gl headers.
Also added a test: cd tests/check && make libs/gstglheaders.check
https://bugzilla.gnome.org/show_bug.cgi?id=784779
Sending an event can accepted event if the caps were rejected
because the event could be queued and processed later.
Also send a drain query in the caps test to make sure that the
event has been processed.
https://bugzilla.gnome.org/show_bug.cgi?id=781673
Since insertion of aud landed, we need to change some testcases
accroding to the change.
Note that counting frames are changed in parser.c,
due to generated frames, AUD.
https://bugzilla.gnome.org/show_bug.cgi?id=736213
For duration queries on live streams, adaptivedemux ignores the query.
The problem then is that the query is answered by the downstream
qtdemux element, with the duration of the currently passing fragment.
This commit changes the behaviour of adaptivedemux to answer the duration
queries for live streams, returning GST_CLOCK_TIME_NONE.
https://bugzilla.gnome.org/show_bug.cgi?id=753879
See https://bugzilla.gnome.org/show_bug.cgi?id=773666
This would ideally be solved in baseparse but that requires further
thought at this point, and in the meantime it would be good to have
rawbaseparse not assert on this but handle it gracefully instead.
Make the unit tests handle the fact that pads don't appear
immediately. Before, the test assumed pads are exposed before the
internal source element is created, which is no longer true.
To satisfy follwing restriction of HLS spec 6.3.3,
select startup fragment sequence to 4th from end of playlist.
Also, seek range should exclude last three fragment in playlist.
"the client SHOULD NOT choose a segment which starts less than
three target durations from the end of the Playlist file."
https://bugzilla.gnome.org/show_bug.cgi?id=777682
