These are not usable as they are, and can easily lead to crash
or leaks. This also silence warning from the scanner. If we manage to
make this usable, we can then remove that mark, it will require
to make this type boxed.
gstbasetransform.h:196: Warning: GstBase: "@submit_input_buffer" parameter unexpected at this location:
* @submit_input_buffer: Function which accepts a new input buffer and pre-processes it.
gstnetcontrolmessagemeta.c:103: Warning: GstNet: gst_buffer_add_net_control_message_meta: unknown parameter 'message' in documentation comment, should be 'addr'
Make gst_collect_pads_clip_running_time() function also store the
signed DTS in the CollectData. This signed DTS value can be used by
muxers to properly handle streams where DTS can be negative initially.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
The internal clock is only used for slaving against the remote clock, while
the user-facing GstClock can be additionally slaved to another clock if
desired. By default, if no master clock is set, this has exactly the same
behaviour as before. If a master clock is set (which was not allowed before),
the user-facing clock is reporting the remote clock as internal time and
slaves this to the master clock.
This also removes the weirdness that the internal time of the netclientclock
was always the system clock time, and not the remote clock time.
https://bugzilla.gnome.org/show_bug.cgi?id=750574
Allow for sub-classes which want to collate incoming buffers or
split them into multiple output buffers by separating the input
buffer submission from output buffer generation and allowing
for looping of one of the phases depending on pull or push mode
operation.
https://bugzilla.gnome.org/show_bug.cgi?id=750033
This uses all of the netclientclock code, except for the generation and
parsing of packets. Unfortunately some code duplication was necessary
because GstNetTimePacket is public API and couldn't be extended easily
to support NTPv4 packets without breaking API/ABI.
We extend our calculations to work with local send time, remote receive time,
remote send time and local receive time. For the netclientclock protocol,
remote receive and send time are assumed to be the same value.
For the results, this modified calculation makes absolutely no difference
unless the two remote times are different.
This improves accuracy on wifi or similar networks, where the RTT can go very
high up for a single observation every now and then. Without filtering them
away completely, they would still still modify the average RTT, and thus all
clock estimations.
They don't necessarily use the same underlying clocks (e.g. on Windows), or
might be configured to a different clock type (monotonic vs. real time clock).
We need the values a clean system clock returns, as those are the values used
by the internal clocks.
If the delay measurement is too far away from the median of the window of last
delay measurements, we discard it. This increases accuracy on wifi a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
We should do some more measurements with all these and check how much sense
they make for PTP. Also enabling them means not following IEEE1588-2008 by the
letter anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
GstPtpClock implements a PTP (IEEE1588:2008) ordinary clock in
slave-only mode, that allows a GStreamer pipeline to synchronize
to a PTP network clock in some specific domain.
The PTP subsystem can be initialized with gst_ptp_init(), which then
starts a helper process to do the actual communication via the PTP
ports. This is required as PTP listens on ports < 1024 and thus
requires special privileges. Once this helper process is started, the
main process will synchronize to all PTP domains that are detected on
the selected interfaces.
gst_ptp_clock_new() then allows to create a GstClock that provides the
PTP time from a master clock inside a specific PTP domain. This clock
will only return valid timestamps once the timestamps in the PTP domain
are known. To check this, the GstPtpClock::internal-clock property and
the related notify::clock signal can be used. Once the internal clock
is not NULL, the PTP domain's time is known. Alternatively you can wait
for this with gst_ptp_clock_wait_ready().
To gather statistics about the PTP clock synchronization,
gst_ptp_statistics_callback_add() can be used. This gives the
application the possibility to collect all kinds of statistics
from the clock synchronization.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
Just create the cancellable fd once and keep it around instead
of creating/closing it for every single packet. Since we spend
most time waiting for packets, an fd is alloced and in use pretty
much all the time anyway.
We were segfaulting because g_sequence_search was returning the iter_end,
and that iterator does not contain anything and thus should not be used
directly
In basesink functions gst_base_sink_chain_unlocked(), below code is used to
checking if buffer is late before doing prepare call to save some effort:
if (syncable && do_sync)
late =
gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
GST_CLOCK_EARLY, 0, FALSE);
if (G_UNLIKELY (late))
goto dropped;
But this code has problem, it should calculate jitter based on current media
clock, rather than just passing 0. I found it will drop all the frames when
rewind in slow speed, such as -2X.
https://bugzilla.gnome.org/show_bug.cgi?id=749258
Since frame->priv->discont was cleared earlier,
GST_BASE_PARSE_FLAG_LOST_SYNC was never being set.
Take the chance to refactor the frame creation a bit to
organize the flags setting and reset.
https://bugzilla.gnome.org/show_bug.cgi?id=738237
Otherwise we're going to set a rather arbitrary DTS of segment.start (usually
0) for live sources, which confuses synchronization if the source started
capturing at a later time. And it's especially wrong for raw media, for which
we should not set any DTS at all.
https://bugzilla.gnome.org/show_bug.cgi?id=747731
It could be triggered by:
gst-launch-1.0 videotestsrc num-buffers=20 ! videcrop bottom=214748364 ! videoconvert ! autovideosink
Spotted while testing:
https://bugzilla.gnome.org/show_bug.cgi?id=743910
The flush-stop event should not restart the task for live sources unless
the element is playing. This was breaking seeks in pause with the rtpsrc.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
Otherwise baseparse will consider empty streams to be an error while
an empty stream is a valid scenario. With this patch, errors would
only be emitted if the parser received data but wasn't able to
produce any output from it.
This change is only for push-mode operation as in pull mode an
empty file can be considered an error for the one driving the
pipeline
Includes a unit test for it
https://bugzilla.gnome.org/show_bug.cgi?id=733171
check_run.c: In function 'sig_handler':
check_run.c:127:13: warning: 'child_sig' may be used uninitialized in this function [-Wmaybe-uninitialized]
killpg(group_pid, child_sig);
^
check_run.c:130:31: warning: 'idx' may be used uninitialized in this function [-Wmaybe-uninitialized]
sigaction(sig_nr, &old_action[idx], NULL);
^
Otherwise e.g. ctrl+c in the test runner exits the test runner, while the test
itself is still running in the background, uses CPU and memory and potentially
never exits (e.g. if the test ran into a deadlock or infinite loop).
The reason why we have to manually kill the actual tests is that after
forking they will be moved to their own process group, and as such are
not receiving any signals sent to the test runner anymore. This is supposed
to be done to make it easier to kill a test, which it only really does if
the test itself is forking off new processes.
This fix is not complete though. SIGKILL can't be caught at all, and error
signals like SIGSEGV, SIGFPE are currently not caught. The latter will only
happen if there is a bug in the test runner itself, and as such seem less
important.
Large scale skip is an optimization, and thus it is safer to
stop skipping than to continue. Clear skip on segments and
discontinuities, as these are points where it is possible that
the original idea of "bytes to skip" changes.
GstNetAddress can be used to store ancillary data which was received with
or is to be sent alongside the buffer data. When used with socket sinks
and sources which understand this meta it allows sending and receiving
ancillary data such as unix credentials (See `GUnixCredentialsMessage`)
and Unix file descriptions (See `GUnixFDMessage`).
This will be useful for implementing protocols which use file-descriptor
passing in payloaders/depayloaders without having to re-implement all the
socket handling code already present in elements such as multisocketsink,
etc. This, in turn, will be useful for implementing zero-copy video IPC.
This meta uses the platform independent `GSocketControlMessage` API
provided by GLib as a part of GIO. As a result this new meta does not
require any new dependencies or any conditional compliation for
portablility, although it is unlikely to do anything useful on non-UNIX
platforms.
Allows buffers to be reclaimed when caps is to be renegotiated so
that bufferpools can be stopped. As the allocation query is
serialized all buffers have been already drained from the pipeline,
except this last_sample one.
https://bugzilla.gnome.org/show_bug.cgi?id=682770
Use gst_buffer_copy_deep() to force the copy of the underlying
memory instead of possibly doing a shallow copy of the buffer
and just referencing the memory
https://bugzilla.gnome.org/show_bug.cgi?id=745287
Based on patch from Song Bing <b06498@freescale.com>
Don't just set the need_preroll flag to TRUE in all cases. When we
are already prerolled it needs to be set to FALSE and when we go to
READY we should not touch it. We should only set it to TRUE in other
cases, like what the code above does.
See https://bugzilla.gnome.org/show_bug.cgi?id=736655
+ Gets installed
+ Uses a helper tool, gst-completion-helper, installed in
bash-completions/helpers.
+ Adds a common script that other tools can source.
https://bugzilla.gnome.org/show_bug.cgi?id=744877
Add a hold off when the clock calibration suddenly loses synch,
as it may be a glitch, but also make sure we update if it stays
desynched for more than a few seconds
Add the minimum-update-interval property to the clock, with a default
of 50ms and don't send polling requests faster than that. That helps to
ensure we spread the initial observations out a little - startup takes
a little longer, but tracking is more stable.
Move the discont skew limiting code inside an if statement, so that
it's only done when the linear regression succeeds and the clock
parameters might actually change.
Allow setting a GstBus on the network clock client
via a new 'bus' object property. If a bus is set, the
clock will output an element message containing statistics
about new clock observations and the clock correlation.
When the local clock is synchronised with the remote, limit the
maximum jump in the clock at any point to be one average RTT to
the server. Also, publish in the bus message whether we are
synched with the remote or not.
Both for the peer filter caps and the converted caps based on the peer caps.
If the peer filter caps are EMPTY, the peer caps query will also return
EMPTY. There's no ned to both downstream/upstream with this query.
Previously GStreamer got access to the libcheck interface by including
libs/gst/check/check.h which in turn included internal-check.h in the
same directory. internal-check.h was generated by copying
libs/gst/check/libcheck/check.h which in turn was generated from
check.h.in in the same directory. In this case generating
libs/gst/check/libcheck/check.h is unnecessary, in addition this file
was accidentally distributed in generated project tarballs.
Now libs/gst/check/internal-check.h is generated directly from
libs/gst/check/libcheck/check.h.in by configure. This means that the
libcheck source must include internal-check.h instead of the previously
generated libs/gst/check/libcheck/check.h. However the unnecessary
intermediate step is now skipped.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741359
Previously embedded libcheck versions did not depend on (u)intmax_t and
doing so would require projects using GStreamer's check framework to add
AX_CREATE_STDINT_H to their configure.ac. A workaround is to fallback to
glib types. This patch assumes that glib.h is always included before
internal-check.h which is ok since everything Gstreamer would include
gst/gstcheck.h instead of directly including internal-check.h.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727826
Reintroduced patches:
* Make sure that fail_if(1) actually fails
from commit 9f99d056a2
New patches due to updated libcheck (based on 0.9.14):
* Checks in m4/check-checks.m4 to cater for new dependencies
* Conditional compile-time compat POSIX fallbacks for libcheck
* Avoid relative paths for libcheck header files
* Make timer_create() usage depend on posix timers, not librt
* Rely on default AX_PTHREAD behavior to allow HAVE_PTHREAD to be used
when checking for types and functions (like clock_gettime())
* Avoid double declaration of clock_gettime() when availabe outside of
librt by making compat clock_gettime() declaration conditional
* check 0.9.9 renamed _fail_unless() and 0.9.12 later renamed it again
to _ck_assert_failed(), so ASSERT_{CRITICAL,WARNING}() now calls this
function
* Remove libcheck fallback infrastructure for malloc(), realloc(),
gettimeofday() and snprintf() since either they appear to be
available or they introduce even more dependencies.
The result is an embedded check in gstreamer that has been tested by
running check tests in core, -base, -good, -bad, -ugly and rtsp-server
on Linux, OSX and Windows.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727826
This lifts the files almost verbatim (the changes being running though
gst-indent and fixing the FSF address) from the upstream respository.
Therefore this commit reverts some GStreamer-specific patches to check
that will be reintroduced next.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727826
When using a negative rate (rate being segment.rate * segment.applied_rate),
we will end up reporting decreasing positions, therefore adjust the clamping
against last reported value accordingly.
Fixes positions getting properly reported with applied_rate < 0.0
https://bugzilla.gnome.org/show_bug.cgi?id=738092
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
Instead of checking if our outcaps are equivalent to the previous incaps, and
if that is the case not setting any caps on the pad... compare against our
previous outcaps because that's what we care about.
Fixes some cases where the outcaps became equivalent to the previous incaps,
but the previous outcaps were different and we were then sending buffers
downstream that were corresponding to the caps we forgot to set on the pad.
Resulting in crashes or image corruption.
Currently we are just returning FALSE, but we do have the information
we should just answer the query the same way as when answering through
the GstElement.query vmethod default implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=739580
Fixes 'Attempt to unlock mutex that was not locked'
warning with newer GLibs when sink is shut down in
certain situations. Triggered by the decodebin
test_reuse_without_decoders unit test in -base
sometimes, esp. on slower machines.
In order for user to be able to track changes in the value set in
GstTimedValueControlSource the following signals have been added:
* value-added
* value-removed
* value-changed
To be able to use a GstControlPoint to be marshalled into the signals,
the GstControlPoint structure is now registerd as a GBoxed type.
New API:
~~~~~~~
* GstTimedValueControlSource::value-added
* GstTimedValueControlSource::value-removed
* GstTimedValueControlSource::value-added
https://bugzilla.gnome.org/show_bug.cgi?id=737616
Add a method letting people to ensure that unreffing one object
leads to its destruction, and possibly the destruction of more object
(think destruction of a GstBin etc...).
https://bugzilla.gnome.org/show_bug.cgi?id=736477
Add a first_buffer boolean state flag to have baseparse do actions
before pushing data. This is used to check the caps for streamheader
buffers that are prepended to the stream, but only if the first buffer
isn't already marked with the _HEADER flag. In this case, it is assumed
that the _HEADER marked buffer is the same as the streamheader.
https://bugzilla.gnome.org/show_bug.cgi?id=735070
Adds API to get or peek a sub-reader of a certain size from
a given byte reader. This is useful when parsing nested chunks,
one can easily get a byte reader for a sub-chunk and make
sure one never reads beyond the sub-chunk boundary.
API: gst_byte_reader_peek_sub_reader()
API: gst_byte_reader_get_sub_reader()
Just remove one skip annotation that causes this:
** (g-ir-compiler:12458): ERROR **: Caught NULL node, parent=empty
with older g-i versions such as 1.32.1.
Adds gst_byte_reader_masked_scan_uint32_peek just like
GstAdapter has a _peek and non _peek version
Upgraded tests to check that the returned value is correct in the
_peek version
API: gst_byte_reader_masked_scan_uint32_peek
https://bugzilla.gnome.org/show_bug.cgi?id=728356
When going to READY, it is possible that we are still pusing a frame but that
our srcpad has already been set to flushing. In that case we should not
post any error on the bus but instead cleanly return FLOW_FLUSHING.
https://bugzilla.gnome.org/show_bug.cgi?id=733320
* GstGlobalDeviceMonitor was renamed to GstDeviceMonitor
* Expand GST_MESSAGE_DEVICE to the full enum value names
* Correct the incorrect references to the GstDeviceProvider interfaces
* Describe caps arguments for gstcheck interface
* Add missing docs for GstNetAddressMeta and its add function
* Add docs for toc helper macros
* Avoid refering to GstValueList type as done elsewhere
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732786
When the parser receives non-aligned packets it can push a buffer
and get a not-linked return while still leaving some data still to
be parsed. This remaining data will not form a complete frame and
the subclass likely returns _OK and baseparse would take that
as the return, while it the element is actually not-linked.
This patch fixes this by storing the last flow-return from a push
and using that if a parsing operation doesn't result in data being
flushed or skipped.
https://bugzilla.gnome.org/show_bug.cgi?id=731474
Currently the scan uses Boyer-moore method and its performance is good.
but, it can be optimized from an implementation of view.
The original scan code is implemented by byte array and index-based access.
In _scan_for_start_code(), the index is increasing from start to end and the
base address of the byte array is referred to as return value.
In the case, index-based access can be replaced by pointer access, which
improve the performance by removing index-related operations.
Its performace is enhanced by approximately 8% on arm-based embedded devices.
Although it seems trivial, it can affect the overall performance because the
_scan_for_start_code() function is very often called when H.264/H.265 video is
played.
In addition, the technique can apply for all architectures and it is good in
view of readability and maintainability.
https://bugzilla.gnome.org/show_bug.cgi?id=731442
Adds a utility struct that is capable of storing and aggregating flow returns
associated with pads.
This way all demuxers will have a standard function to use and have the
same expected results.
Includes tests.
https://bugzilla.gnome.org/show_bug.cgi?id=709224
Buffer pool set_config() may return FALSE if requested configuration needed
small changes. Reget the config and try setting it again (validating the
changes first). This ensure we have a configured pool if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=727916
exit() will call atexit handlers, which may try to
clean up things or wait for things to get cleaned up,
which we don't want or need. We just want to stop
and let the parent know about the failure as quickly
as possible in case fork() is used.
Fixes timeouts on assert failures in checks where
an exit handler waits for things to stop, but they
don't stop because they haven't been shut down,
and they haven't been shut down because there's no
simple way to do so on failures.
http://sourceforge.net/p/check/patches/50/
Currently, if prepare() takes too much time, we skip the call to render().
The side effect of this, is that we endup starving the render(). The solution
in this patch is to always render frames that are on time before prepare() is
executed. This will maximize the number of frames we display and smoothly
degrade the rendering performance.
https://bugzilla.gnome.org/show_bug.cgi?id=729335
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Keep it simple. Likely also makes things easier for bindings,
and efficiency clearly has not been a consideration given how
the existing code handled these lists.
In order to be deterministic, multiple waiting GstClockIDs needs to be
released at the same time, or else one can get into the situation that
the one being released first can add itself back again before the next
one waiting is released.
Test added for new API and old tests rewritten to comply.
This reverts commit b9313afc75.
This should be fixed in upstream libcheck instead. We want
to keep diff of our local copy to upstream libcheck
to a minimum.
We iterate the current discont group backwards and push each GOP forwards,
starting from the last one. However if the first buffer in the current
discont group is a keyframe, we will keep it around until next time,
which is far from ideal. Just push it.
This prevents situations where a first branch would get seeked and
receive a buffer before all branches got seeked, and thus collected
would get called based on EOS from the previous segment.
As a consequence, during the process of seeking, don't decrease
the eospads number when a FLUSH_STOP is received.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724571
GST_CHECKS can be simply "test*" to run run all tests (including those that are
marked broken). Update the sparse comments a bit to tell how this works.
Don't set the size to -1 in automatic_eos mode (which also updates the
duration to -1). We only want automatic_eos mode influence the maxsize
calculations without any side effects.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724564
This defaults to TRUE and if it is set to FALSE it is the subclasses
responsibility to return GST_FLOW_EOS from the create() vmethod once
the stream is done.
Store the eos event seqnum and use it when creating the
new eos event to be pushed downstream. To know if the eos
was caused by the eos events received on send_event, a
'forced_eos' flag is used to use the correct seqnum on
the event pushed downstream.
Useful if the application wants to check if the EOS message
was generated from its own pushed EOS or from another source
(stream really finished).
Also adds a test for this
https://bugzilla.gnome.org/show_bug.cgi?id=722791
If on passthrough during reverse playback, do not accumulate buffers as
baseparse will never check for DISCONT flag to push those buffers.
So just push buffers downstream as if it was forward playback.
https://bugzilla.gnome.org/show_bug.cgi?id=721941
TIME segments are being ignored and a standard initialized
segment is used instead. This causes issues as not properly detecting
reverse playback or not cliping output based on the segment.
This seems to be a regression from one of the GstSegment/GstEvent
redesigns on the 0.10 -> 1.0 transition
It wasn't required, instead baseparse was using it to check the media
caps to identify if it was handling audio or video.
The pending_segment was removed and a checked_media boolean
replaced it for a more accurate naming.
https://bugzilla.gnome.org/show_bug.cgi?id=721350
A GAP event is handled as an empty buffer by sinks and they expect
to receive start up events before GAP events (like a segment).
This is important specially if there is a GAP at the beginning of
a stream (before any buffers) so that the segment event can be
pushed downstream before the GAP
https://bugzilla.gnome.org/show_bug.cgi?id=721350
* fix typo GstBufferFlag -> GstBufferFlags
* fix typo GstFeatures -> GstCapsFeatures
* fix typo GstAllocatorParams -> GstAllocationParams
* fix typo GstContrlSources -> GstControlSource
* do not refer to gstcheck as an object
* make references gtk_init() and tcase_set_timeout() not be references
* gst_element_get_pad() renamed gst_element_get_static_pad()
* gst_clock_id_wait_async_full() renamed gst_clock_id_wait_async()
* _drop_element() is really gst_queue_array_drop_element()
* gst_pad_accept_caps() was removed, do not refer to it
* separate GST_META_TAG_MEMORY_STR declaration from description
* do not describe removed gst_collect_pads_collect()
* correctly link to GstElementClass' virtual set_context()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719614
Fix a typo in a doc string - the property is round-trip-limit, not
roundtrip-limit.
Remove a bogus GST_WARNING that can print an uninitialised variable
and is redundant anyway.
Sometimes, packets might take a very long time to return. Such packets
usually are way too late and destabilize the regression with their
obsolete data. On Wi-Fi, round-trips of over 7 seconds have been observed.
If the limit is set to a nonzero value, packets with a round-trip period
larger than the limit are ignored.
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
https://bugzilla.gnome.org/show_bug.cgi?id=712385
Keep a rolling average of the round trip time for network clock
observations, favouring shorter round trips as being more accurate.
Don't pass any clock observation to the clock slaving if it has a
round-trip time greater than 2 times the average.
Actual shifts in the network topology will be noticed after some
time, as the rolling average incorporates the new round trip times.
Even though this parameter is not used, it should be const to fit in with the
coding standards for other similar parameters. Client code already passes in
const strings under the expectation that they won’t be modified.
https://bugzilla.gnome.org/show_bug.cgi?id=710442
pads->data is the public list. It is dynamically rebuilt at each call to
check_collected, in check_pads to be specific. When you add a pad and
collectpads have been started, it is not added to the public list.
Thus there exists a possible race where :
1) You would add a pad to collectpads while running.
2) You set collectpads to flushing before check_collected has been called again
-> the pad is not set to flushing
3) the pad starts pushing data as downstream might not be prepared, in the case
of adder it then returns FLOW_FLUSHING.
4) elements like demuxers, when they get a FLOW_FLUSHING, stop their tasks,
never to be seen again.
https://bugzilla.gnome.org/show_bug.cgi?id=708636
The change should have been from PARAM_CONSTRUCT_ONLY to
PARAM_CONSTRUCT, otherwise bindings are affected, since
they look for the CONSTRUCT flag.
See ec55363d
The seqnum of the segment after a seek should be the same of
the seek event. Downstream elements might rely on seqnums to
identify events related to a seek.
This is particularly important when a demuxer maps a TIME seek
into a BYTES seek for upstream and it needs to identify the
corresponding segment event and map it back into TIME to push
downstream, possibly using the values from the original seek
event.
https://bugzilla.gnome.org/show_bug.cgi?id=707530
If a pad is removed while a collectpads element (say adder) is in a chain
function waiting to be collected, there is a possibility that an unref happens
on a NULL pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=707536
This avoids triggering plenty of extra code/methods/overhead downstream when
we can just quickly check whenever we want to set caps whether they are
identical or not
https://bugzilla.gnome.org/show_bug.cgi?id=706600
Use custom code to implement flush-stop, we can't reuse the set_flushing code
because we can't touch the live_playing flag and we need to signal the
streaming thread.
In some specific cases (like transmuxing) we want to force the element
to actually parse all incoming data even if the element deems it is not
necessary.
This property simply ignores requests from the element to enable passthrough
mode which results in processing always being enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=705621
Adds a variant of the _push function that doesn't check the queue limits
before adding the new item. It is useful when pushing an element to the
queue shouldn't lock the thread.
One particular scenario is when the queue is used to serialize buffers
and events that are going to be pushed from another thread. The
dataqueue should have a limit on the amount of buffers to be stored to
avoid large memory consumption, but events can be considered to have
negligible impact on memory compared to buffers. So it is useful to be
used to push items into the queue that contain events, even though the
queue is already full, it shouldn't matter inserting an item that has
no significative size.
This scenario happens on adaptive elements (dashdemux / mssdemux) as
there is a single download thread fetching buffers and putting into the
dataqueues for the streams. This same download thread can als generate
events in some situations as caps changes, eos or a internal control
events. There can be a deadlock at preroll if the first buffer fetched
is large enough to fill the dataqueue and the download thread and the
next iteration of the download thread decides to push an event to this
same dataqueue before fetching buffers to other streams, if this push
locks, the pipeline will be stuck in preroll as no more buffers will be
downloaded.
There is a somewhat common practice in dash streams to have a single
very large buffer for audio and one for video, so this will always
happen as the download thread will have to push an EOS right after
fetching the first buffer for any stream.
API: gst_data_queue_push_force
https://bugzilla.gnome.org/show_bug.cgi?id=705694
When the range for a property is defined as -INT_MAX-1 .. INT_MAX, like
the xpos in a videomixer the following expression in the macro
definitions of convert_g_value_to_##type (and the equivalent in
convert_value_to_##type)
v = pspec->minimum + (g##type) ROUNDING_OP ((pspec->maximum - pspec->minimum) * s);
are converted to:
v = -2147483648 + (g##type) ROUNDING_OP ((2147483647 - -2147483648) * s);
(2147483647 - -2147483648) overflows to -1 and the net result is:
v = -2147483648 + (g##type) ROUNDING_OP (-1 * s);
so v only takes the values -2147483648 for s == 0 and 2147483647
for s == 1.
Rewriting the expression as minimum*(1-s) + maximum*s gives the correct
result in this case.
https://bugzilla.gnome.org//show_bug.cgi?id=705630
Calling gst_buffer_get_size represented 2/3 of the cost of helper_find_peek
which was called whenever a typefindfunction wanted to peek at data.
We already know the size (from the GstMapInfo), so just use that.
Pass the fixed caps we're asked to accept as a filter for the caps
query, so we don't get a fully-expanded set of caps back (which we don't
need and can take a lot of time for intersection).
This reduces the time for camerabin to produce a second frame on a
logitech C910 camera from around 52 seconds to a bit less then 16
seconds on my system.
https://bugzilla.gnome.org/show_bug.cgi?id=702632
When we asynchronously go from READY to PLAYING, also call the
state change function so that subclasses can update their state for PLAYING.
Because the PREROLL lock is not recursive, we can't make this without
races and we must assume for now that the subclass can handle concurrent calls
to PAUSED->PLAYING and PLAYING->PAUSED. We can make this assumption because not
many elements actually do something in those state changes and the ones that
did would be broken even more without this change.
https://bugzilla.gnome.org/show_bug.cgi?id=702282
Doing it after every single create() is not very efficient and not necessary.
Especially on network file systems fstat() is not cached and causes network
traffic, making the source possibly unusable slow.
https://bugzilla.gnome.org/show_bug.cgi?id=652037
This makes sure that at least one buffer per second is rendered if buffers
are dropped before ::prepare. Without this change, at least one buffer per
second wouldn't be too late before ::prepare anymore but would be dropped
before ::render because of last_render_time being set before ::prepare
already.
This function works just like gst_data_queue_pop, but it doesn't
remove the object from the queue.
Useful when inspecting multiple GstDataQueues to decide from which
to pop the element from.
Add: gst_data_queue_peek
Importantly, this patch converts DTS to running time. Less importantly,
and possibly a problem for some muxers, is that it orders buffers by
DTS (if it is valid, otherwise PTS). This is generally correct, but
might be somewhat surprising to muxers.
Also note that once converted to running time, DTS can end up negative.
gst_pad_get_current_caps() on the source pad might yield NULL caps
if we're being shut down and the source pad has already been
deactivated by the other thread that's changing state. Just bail
out in that case, instead of passing NULL caps to the transform_size
function, which it might not expect.
Fixes spurious warnings in audioresample shutdown unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=693996
... and tracking of DTS. Fixes cases where PTS is locked on to the
DTS of an incoming buffer with no PTS with invalid data, leading to
no outgoing PTS (since it is not allowed smaller than DTS).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691481
Use GSIZE_TO_POINTER instead. sizeof(GType) may be larger
than sizeof(gulong) and sizeof(int), so the casts may
chop off some bits from the GType value on some architectures.
Don't retry to negotiate when we fail to negotiate but instead produce a
NOT_NEGOTIATED error. We only want to retry negotiation if the result from
gst_pad_push() returned NOT_NEGOTIATED.
When negotiation fails, mark the pad as needing a reconfigure again so
that it gets picked up again next time.
Signed-off-by: Niv Sardi <xaiki@evilgiggle.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691986
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
