The element flag does not indicate wether a bin should be tested as a
source or as a sink, eg. a bin with the sink flag may still have a
source pad and a bin with the source flag may have a sink pad. In this
case it is better to determine the element type by looking at the
available pads and pad templates.
Also rename srcpad and sinkpad where it actually represents
element_srcpad_name and element_sinkpad_name.
https://bugzilla.gnome.org/show_bug.cgi?id=752493
For files which are smaller than 1.5 seconds, the duration
estimation does not happen. So the duration will always be
displayed as 0. Updating the duration on EOS when the estimation
has not happened already
https://bugzilla.gnome.org/show_bug.cgi?id=750131
We must make the buffer writable to write its PTS and DTS, and also
reset its duration.
The behaviour is now the same as before commit c3bcbadd, except metas
might still be attached to the buffer extracted from the adapter.
https://bugzilla.gnome.org/show_bug.cgi?id=752092
This way we don't have to allocate/free temporary structs
for storing things in the queue array.
API: gst_queue_array_new_for_struct()
API: gst_queue_array_push_tail_struct()
API: gst_queue_array_peek_head_struct()
API: gst_queue_array_pop_head_struct()
API: gst_queue_array_drop_struct()
https://bugzilla.gnome.org/show_bug.cgi?id=750149
POOL meta just means that this specific instance of the meta is related to a
pool, a copy should be made when reasonable and the flag should just not be
set in the copy.
POOL meta just means that this specific instance of the meta is related to a
pool, a copy should be made when reasonable and the flag should just not be
set in the copy.
This preserves GstMeta properly unless the subclass does special things. It's
enough to make h264parse's stream-format/alignment conversion pass through
metas as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=742385
All functions that return a GstBuffer or a list of them will now copy
all GstMeta from the input buffers except for meta with GST_META_FLAG_POOLED
flag or "memory" tag.
This is similar to the existing behaviour that the caller can't assume
anything about the buffer flags, timestamps or other metadata. And it's
also the same that gst_adapter_take_buffer_fast() did before, and what
gst_adapter_take_buffer() did if part of the first buffer or the complete
first buffer was requested.
https://bugzilla.gnome.org/show_bug.cgi?id=742385
The doc generator get confused with the inline structure. So
workaround by wrapping the inner of the structure with
public/private mark, and document that GST_COLLECT_PADS_DTS macro
shall be used to access this.
* Fix function name in sections.txt
* Add few missing or fix miss-named
* Workaround gtk-doc being confused with non typedef
types (loose track of public/private
There was few Since: mark missing their column. Also unify the way
we set the Since mark on enum value and structure members. These
sadly don't show up in the index.
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.
