GstPad has a flag for suggesting if the accept-caps
query should use intersect instead of the default
subset caps operation to verify if the caps would be
acceptable.
basetransform currently always uses the subset check and
this patch makes it honor the flag for using intersect
if it is set.
https://bugzilla.gnome.org/show_bug.cgi?id=748635
To be able to disable the slightly "magic" forwarding of the
necessary events between the harnesses.
Also introduce a new test-suite for GstHarness, that documents the
feature, and should hopefully expand into documenting most of the
features the harness possesses.
https://bugzilla.gnome.org/show_bug.cgi?id=752746
As of now, even for stream completly inside segment, there is no
guarantied that the DTS will be inside the segment. Specifically
for H.264 with B-Frames, the first few frames often have DTS that
are before the segment.
Instead of using the sync timestamp to clip out of segment buffer,
take the duration from the start/stop provided by the sub-class, and
check if the pts and pts_end is out of segment.
https://bugzilla.gnome.org/show_bug.cgi?id=752791
Even though asserts can't be disabled in GstHarness, Coverity still
complains about running code inside them. Moving the code to outside the
g_asserts().
CID #1311326, #1311327, #1311328
gst_query_find_allocation_meta() requires the query to be
writable to work. This patch ensure avoids taking a reference
on the query, so we can now check if a certain allocation meta
is present.
https://bugzilla.gnome.org/show_bug.cgi?id=752661
By introducing gst_harness_add_src_harness and gst_harness_add_sink_harness
we collect all sub-harness setup in one function, making the previous
sub-harness creation functions now calls these directly, and making it
much easier (and less error-prone) to add your own src or sink-harness
using the more generic harness-creation functions.
This line has no purpose, clearly gst_segment_do_seek() is doing
the right job, also, having the start time (a timestamp) be that
same as time (the stream time) is quite odd.
https://bugzilla.gnome.org/show_bug.cgi?id=750783
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.
