This is cosmetic as 'late' should never be set during preroll (in pause).
Though code may evolve in the future, so this is good for preventing
potential bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=772468
When the first buffer arrives, we endup calling:
->prepare()
->prepare()
->preroll()
->render()
This will likely confuse any element using this method. With this patch,
we ensure the preroll take place before the first render prepare() is
called. This will result in:
->prepare()
->preroll()
->prepare()
->render()
https://bugzilla.gnome.org/show_bug.cgi?id=772468
Hurd also defines __MACH__, but it does not have mach_absolute_time. Use
the more strict __APPLE__ instead.
Has also been sent upstream: https://github.com/libcheck/check/pull/65
This reverts commit 2e278aeb71.
Some parsers, specifically audio parsers, assume to get all remaining
data on EOS and just pass them onwards. While the idea here is correct,
we will probably need a property for this on baseparse for parsers to
opt-in.
https://bugzilla.gnome.org/show_bug.cgi?id=773666
Implement handling in basesink to not unconditionally discard
out-of-segment buffers and expose it as a new property on fakesink
(not unconditionally in all basesink based sinks).
The property defaults to FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=765734
baseparse would pass whatever is left in the adapter to the
subclass when draining, even if it's less than the minimum
frame size required. This is bogus, baseparse should just
discard that data then. The original intention of that code
seems to have been that if we have more data available than
the minimum required we should pass all of the data available
and not just the minimum required, which does make sense, so
we'll continue to do that in the case that more data is available.
Fixes assertions in rawvideoparse on EOS after not-negotiated with
fakesrc sizetype=random ! queue ! rawvideoparse format=rgb ! appsink caps=video/x-raw,format=I420
https://bugzilla.gnome.org/show_bug.cgi?id=773666
The durations of the buffers are (usually) assuming that no frames are being
dropped and are just the durations coming from the stream. However if we do
trickmodes, frames are being dropped regularly especially if only key units
are supposed to be played.
Fixes completely bogus QoS proportion values in the above case.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
If segment.stop was given, and the subclass provides a size that might be
smaller than segment.stop and also smaller than the actual size, we would
already stop there.
Instead try reading up to segment.stop, the goal is to ignore the (possibly
inaccurate) size the subclass gives and finish until segment.stop or when the
subclass tells us to stop.
Waiting before posting calculated bitrates seems to be the
intent of the code, so avoid adding them to the tag list
pushed with the first frame.
When the threshold is reached, gst_base_parse_update_bitrates
sets tags_changed, so this posts the calculated ones right
that moment.
This prevents an insane average calculated from just the
first (key) frame from getting posted.
https://bugzilla.gnome.org/show_bug.cgi?id=768439
There must be a SEGMENT event before the GAP event, and SEGMENT events must
come after any CAPS event. We however did not produce any CAPS yet, so we need
to ensure to insert the CAPS event before the SEGMENT event into the pending
events list.
https://bugzilla.gnome.org/show_bug.cgi?id=766970
If we were in PAUSED, the current clock time and base time don't have much to
do with the running time anymore as the clock might have advanced while we
were PAUSED. The system clock does that for example, audio clocks often don't.
Updating the start time in PAUSED will cause a) the wrong position to be
reported, b) step events to step not just the requested amount but the amount
of time we spent in PAUSED. The start time should only ever be updated when
going from PLAYING to PAUSED to remember the current running time (to be able
to compensate later when going to PLAYING for the clock time advancing while
PAUSED), not when we are already in PAUSED.
Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com>
The updating of the start time when the state is lost was added in commit
ba943a82c0 to fix the position reporting when
the state is lost. This still works correctly after this change.
https://bugzilla.gnome.org/show_bug.cgi?id=739289
We don't do calculations with different units (buffer offsets and bytes)
anymore but have functions for:
1) getting the number of bytes since the last discont
2) getting the offset (and pts/dts) at the last discont
and the previously added function to get the last offset and its distance from
the current adapter position.
https://bugzilla.gnome.org/show_bug.cgi?id=766647
API: gst_buffer_prev_offset
API: gst_buffer_get_offset_from_discont
The gst_buffer_get_offset_from_discont() method allows retrieving the current
offset based on the GST_BUFFER_OFFSET of the buffers that were pushed in.
The offset will be set initially by the GST_BUFFER_OFFSET of
DISCONT buffers, and then incremented by the sizes of the following
buffers.
The gst_buffer_prev_offset() method allows retrievent the previous
GST_BUFFER_OFFSET regardless of flags. It works in the same way as
the other gst_buffer_prev_*() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=766647
The subclass should do that already, but just in case do it ourselves too as a
fallback. Without this, e.g. playbin will just wait forever if this fails
because it is triggered as part of an ASYNC state change.
POSIX standards requires strsignal() to return a pointer to a char,
not a const pointer to a char. [1] On uClibc, and possibly other
libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares
const char *strsignal (int sig) which causes a type error.
[1] man 3 strsignal
https://bugzilla.gnome.org/show_bug.cgi?id=763567
To allow the GstTestClock to be used as a GstSystemClock, it is
useful to implement the clock-type property that GstSystemClock
provides. This allows GstTestClock to be used as the system clock
with code that expects a GstSystemClock.
https://bugzilla.gnome.org/show_bug.cgi?id=762147
Otherwise PTS and DTS will come out of sync if upstream continues to provide
PTS and not DTS, and we have to skip some data from the stream or PTS are not
exactly increasing with the duration of each packet.
https://bugzilla.gnome.org/show_bug.cgi?id=765260
gsttypefindhelper.c:485: Warning: GstBase: invalid "transfer" annotation for gsize: only valid for array, struct, union, boxed, object and interface types
If we don't store the value in prev_dts, we would over and over again
initialize the DTS from the last known upstream PTS. If upstream only provides
PTS every now and then, then this causes DTS to be rather static.
For example in adaptive streaming scenarios this means that all buffers in a
fragment will have exactly the same DTS while the PTS is properly updated. As
our queues are now preferring to do buffer fill level calculations on DTS,
this is causing huge problems there.
See https://bugzilla.gnome.org/show_bug.cgi?id=691481#c27 where this part of
the code was introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=765096
It is calling do_sync(), which requires the STREAM_LOCK and PREROLL_LOCK to be
taken. The STREAM_LOCK is already taken in all callers, the PREROLL_LOCK not.
https://bugzilla.gnome.org/show_bug.cgi?id=764939
This is the best guess we can make if such a buffer reached the collect
pad. This is uncommon, we do expect parsers to have tried and fixed that
if possible (or needed).
https://bugzilla.gnome.org/show_bug.cgi?id=762207
POSIX standards requires strsignal() to return a pointer to a char,
not a const pointer to a char. [1] On uClibc, and possibly other
libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares
const char *strsignal (int sig) which causes a type error.
[1] man 3 strsignal
https://bugzilla.gnome.org/show_bug.cgi?id=763567
Many parsers are storing tags only in pre_push_frame(), if we wouldn't check
afterwards we would push buffers before those tags and a lot of code assumes that
tags are available before preroll.
https://bugzilla.gnome.org/show_bug.cgi?id=763553
Similar to the stress test functions for buffers that has a callback to
create the buffer to be pushed, it's useful to have functions that use a
callback to create the event to be pushed.
API: gst_harness_stress_push_event_with_cb_start()
API: gst_harness_stress_push_event_with_cb_start_full()
API: gst_harness_stress_send_upstream_event_with_cb_start()
API: gst_harness_stress_push_upstream_event_with_cb_start_full()
https://bugzilla.gnome.org/show_bug.cgi?id=761932
Depending on when gst_harness_pull was called - before the buffer reached
gst_harness_chain or after we can get different behaviors of the test
with enabled blocking push mode. The fix makes the behavior always the
same. In pull function we get the buffer first, thus making sure
gst_harness_chain waits for the signal, and emitting the signal after.
https://bugzilla.gnome.org/show_bug.cgi?id=761931
Set the sink_forward_pad to NULL before tearing down sink_harness to
avoid that the harness tries to forward events/queries to it while it's
tearing down.
https://bugzilla.gnome.org/show_bug.cgi?id=761904
We have no guarantees about what flags are set on buffers we take
out of the GstAdapter. If we push out multiple buffers from the
first input buffer (which will have discont set), only the first
buffer we push out should be flagged as discont, not all of the
buffers produced from that first initial input buffer.
Fixes issue where the first few mp3 frames/seconds of data in push
mode were skipped or garbled in some cases, and the discont flags
would also trip up decoders which were getting drained/flushed for
every buffer. This was a regression introduced in 1.6 apparently.
Does not matter here but makes Coverity more happy. It can't
know that g_list_remove() only looks at the pointer value but
does not dereference it.
CID 1348454
Currently, the query values are being set even if the query itself was
determined to have failed. Fix this to ensure the values are only set in
case of a query success.
https://bugzilla.gnome.org/show_bug.cgi?id=760479
There's not much lost by having the clock idle around a bit longer but it will
potentially allow anybody wanting to use the same clock server again to sync
much faster.
If multiple net/NTP clocks are created for the same server, reuse the same
internal clock for all of them. This makes sure that we don't flood the server
with too many requests and also possibly allows faster synchronization if
there already was an earlier synchronized clock when creating a new one.
Watching videos with variant bitrate is common to have delta
more than 10 kbps, resulting in tag list spam.
Instead of relying on fixed 10 kpbs delta, it is better to
calculale the difference in percentage and update tag list
only when bitrate changes more than 2%.
https://bugzilla.gnome.org/show_bug.cgi?id=759055
My previous fix for #758029 wasn't quite right and simply made the race rarer.
Some of the files are installed by install-exec and others by install-exec, so
the hooks need to be split too.
https://bugzilla.gnome.org/show_bug.cgi?id=758029
This reverts commit 2c475a0355.
This causes issues with h264parse. It breaks timestamps as
there are headers in the middle of the stream and this patch
makes the timestamps for those differ from the ones that
are adjusted, creating a discontinuity and leading to sync
issues.
Otherwise the buffer was left with the original values and later would
be compared with other buffers that were converted to runninn time,
leading to bad interleaving of multiple streams.
https://bugzilla.gnome.org/show_bug.cgi?id=757961
baseparse tries to preserve timestamps from upstream if
it is running on a time segment and write that to
output buffers. It assumes the first DTS is going to be
segment.start and sets that to the first buffers. In case
the buffer is a header buffer, it had no timestamps and
will have only the DTS set due to this mechanism.
This patch prevents this by skipping this behavior for
header buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=757961
The install hook needs to be a install-data-hook not an install-exec-hook as the
helpers are installed into helperdir which is considered data (only path
variables with "exec" in are considered executables).
The explicit dependency on install-helpersPROGRAMS was an attempt at solving
this, but this causes occasional races where install-helpersPROGRAMS can run
twice in parallel (once via install-all, once via the hook's dependency).
https://bugzilla.gnome.org/show_bug.cgi?id=758029
They take a GstBaseSink instance as argument at not a GstPad. Rename the
argument to 'obj' which is not miss leading and in line with
GST_BASE_SINK_PAD(obj).
https://bugzilla.gnome.org/show_bug.cgi?id=756954
In file included from gst-ptp-helper.c:40:0:
/usr/include/net/if.h:265:19: error: field 'ifru_addr' has incomplete type
struct sockaddr ifru_addr;
https://bugzilla.gnome.org/show_bug.cgi?id=756136
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753851
The default padding I introduced in d4f81fb4e6 is
actually only 4 pointers and on 32bit platforms already smaller than the union.
Replace it with a fixed 64byte padding. Don't add the normal padding for now.
Fixes#755822
Broke this when I removed the G_GNUC_PRINTF in a previous
commit to fix indentation, since it was not really needed.
Turns out unlike gcc clang warns though if a non-literal
format string is passed then. Fix indentation differently.
http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format
While this technically is an abi break, we decided to do this:
1) the struct is documented to be internal
2) the struct is alloced and freed inside the library
3) there are no public methods that receive or return instances
4) the only code known to use this struct are classes containd here
gst_segment_to_position might cause confusion, especially with the addition of
gst_segment_position_from_stream_time . Deprecated gst_segment_to_position
now, and replaced it with gst_segment_position_from_running_time.
Also added unit tests.
In order for gst_harness_new_full to be MT-safe the increase and
decrease of HARNESS_REF must be MT-safe. This allows for creating
multiple harnesses from different threads wrapping the same element.
https://bugzilla.gnome.org/show_bug.cgi?id=754661
1. Get a list of pad templates from the element class, not the
factory. This allows us to interact with test-elements that does
not have a factory.
2. Use the pad_template_caps in caps-queries when caps is not set
explicitly on the pad. Not doing so is simply wrong, and prohibits
interactions with special templates used for testing.
https://bugzilla.gnome.org/show_bug.cgi?id=754193
There exist cases where a reconfigure event was propagated from
downstream, but caps didn't change. In this case, we would
reconfigure only when the next buffer arrives. The problem is that
due to the allocation query being cached, the return query parameters
endup outdated.
In this patch we refactor the reconfigurating code into a function, and
along with reconfiguring when a new buffer comes in, we also reconfigure
when a query allocation arrives.
https://bugzilla.gnome.org/show_bug.cgi?id=753850
Explicitly keep track again whether upstream tags or parser tags
already contain bitrate information, and only force a tag update
for a bitrate if we are actually going to add the bitrate to the
taglist later. This fixes constant re-sending of the same taglist,
because upstream provided a bitrate already and we didn't add it,
so we didn't save the 'posted' bitrate, which would then in turn
again trigger the 'bitrate has changed too much, update tags'
code path. Fixes tag spam with m4a files for example.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
In 0.10 there were no sticky events, and all tag events
sent would just be merged with the previously-received
tags. In 1.x we have sticky events, and the tags in the
tag event(s) should at all times carry the complete tags,
so we can't just push some tags and then just push tags
with just bitrates to update the bitrates, etc.
Instead we need to keep track of the upstream stream tags
received, of the tags set by the video decoder subclass,
and send an updated tag event with the combined tags
including our own bitrate tags (if applicable) whenever
the upstream tags, the subclass tags or any of our bitrates
change.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
This is needed so that we can do proper tag handling
all around, and combine the upstream tags with the
tags set by the subclass and any extra tags the
base class may want to add.
API: gst_base_parse_merge_tags()
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Use gst_pad_peer_query_duration() and remove a few
unnecessary levels of indentation. Rest of code might
looks a bit questionable, but leave it as is for now.
According to the design docs:
The ACCEPT_CAPS query is not required to work recursively, it can simply
return TRUE if a subsequent CAPS event with those caps would return
success.
So make it a shallow check instead of recursivelly check downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=748635
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
