Not all aggregator subclasses will have a single pad template called sink_%u
and might do something special depending on what the application requests.
https://bugzilla.gnome.org/show_bug.cgi?id=757018
Otherwise they will receive a QOS event that has earliest_time=0 (because we
can't have negative timestamps), and consider their buffer as too late
https://bugzilla.gnome.org/show_bug.cgi?id=754356
In the case where you have a source giving the GstAggregator smaller
buffers than it uses, when it reaches a timeout, it will consume the
first buffer, then try to read another buffer for the pad. If the
previous element is not fast enough, it may get the next buffer even
though it may be queued just before. To prevent that race, the easiest
solution is to move the queue inside the GstAggregatorPad itself. It
also means that there is no need for strange code cause by increasing
the min latency without increasing the max latency proportionally.
This also means queuing the synchronized events and possibly acting
on them on the src task.
https://bugzilla.gnome.org/show_bug.cgi?id=745768
Before aggregator based elements always started at running time 0,
now it's possible to select the first input buffer running time or
explicitly set a start-time value.
https://bugzilla.gnome.org/show_bug.cgi?id=749966
Adding a pad will add a new upstream that might have a bigger minimum latency,
so we might have to wait longer. Or it might be the first live upstream, in
which case we will have to start deadline based aggregation.
Removing a pad will remove a new upstream that might have had the biggest
latency, so we can now stop waiting a bit earlier. Or it might be the last
live upstream, in which case we can stop deadline based aggregation.
And keep on querying upstream until we get a reply.
Also, the _get_latency_unlocked() method required being calld
with a private lock, so removed the _unlocked() variant from the API.
And it now returns GST_CLOCK_TIME_NONE when the element is not live as
we think that 0 upstream latency is possible.
https://bugzilla.gnome.org/show_bug.cgi?id=745768
One has to use the src_lock anyway to protect the min/max/live so they
can be notified atomically to the src thread to wake it up on changes,
such as property changes. So no point in having a second lock.
Also, the object lock was being held across a call to
GST_ELEMENT_WARNING, guaranteeing a deadlock.
While gst_aggregator_iterate_sinkpads() makes sure that every pad is only
visited once, even when the iterator has to resync, this is not all we have
to do for querying the latency. When the iterator resyncs we actually have
to query all pads for the latency again and forget our previous results. It
might have happened that a pad was removed, which influenced the result of
the latency query.
It was between another function and its helper function before, which was
confusing when reading the code as it had nothing to do with the other
functions.
This lock is not what is commonly known as a "stream lock" in GStremer,
it's not recursive and it's taken from the non-serialized FLUSH_START event.
https://bugzilla.gnome.org/show_bug.cgi?id=742684
steal_buffer() + unref seems to be a wide-spread idiom
(which perhaps indicates that something is not quite
right with the way aggregator pad works currently).
Instead of using the GST_OBJECT_LOCK we should have
a dedicated mutex for the pad as it is also associated
with the mutex on the EVENT_MUTEX on which we wait
in the _chain function of the pad.
The GstAggregatorPad.segment is still protected with the
GST_OBJECT_LOCK.
Remove the gst_aggregator_pad_peak_unlocked method as it does not make
sense anymore with a private lock.
https://bugzilla.gnome.org/show_bug.cgi?id=742684
Some members sometimes used atomic access, sometimes where not locked at
all. Instead consistently use a mutex to protect them, also document
that.
https://bugzilla.gnome.org/show_bug.cgi?id=742684
Reduce the number of locks simplify code, what is protects
is exposed, but the lock was not.
Also means adding an _unlocked version of gst_aggregator_pad_steal_buffer().
https://bugzilla.gnome.org/show_bug.cgi?id=742684
Whenever a GCond is used, the safest paradigm is to protect
the variable which change is signalled by the GCond with the same
mutex that the GCond depends on.
https://bugzilla.gnome.org/show_bug.cgi?id=742684
No need to use an iterator for this which creates a temporary
structure every time and also involves taking and releasing the
object lock many times in the course of iterating. Not to mention
all that GList handling in gst_aggregator_iterate_sinkpads().
The minimum latency is the latency we have to wait at least
to guarantee that all upstreams have produced data. The maximum
latency has no meaning like that and shouldn't be used for waiting.
When iterating sink pads to collect some data, we should take the stream lock so
we don't get stale data and possibly deadlock because of that. This fixes
a definitive deadlock in _wait_and_check() that manifests with high max
latencies in a live pipeline, and fixes other possible race conditions.
This simplifies the code and also makes sure that we don't forget to check all
conditions for waiting.
Also fix a potential deadlock caused by not checking if we're actually still
running before starting to wait.
When this is TRUE, we really have to produce output. This happens
in live mixing mode when we have to output something for the current
time, no matter if we have enough input or not.
This removes the uses of GAsyncQueue and replaces it with explicit
GMutex, GCond and wakeup count which is used for the non-live case.
For live pipelines, the aggregator waits on the clock until either
data arrives on all sink pads or the expected output buffer time
arrives plus the timeout/latency at which time, the subclass
produces a buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=741146
Otherwise the caps of the pad might change while the subclass still works with
a buffer of the old caps, assuming the the current pad caps apply to that
buffer. Which then leads to crashes and other nice effects.
https://bugzilla.gnome.org/show_bug.cgi?id=740376
Audiomixer blocksize, cant be 0, hence adjusting the minimum value to 1
timeout value of aggregator is defined with MAX of MAXINT64,
but it cannot cross G_MAXLONG * GST_SECOND - 1
Hence changed the max value of the same
https://bugzilla.gnome.org/show_bug.cgi?id=738845
Determines the amount of time that a pad will wait for a buffer before
being marked unresponsive.
Network sources may fail to produce buffers for an extended period of time,
currently causing the pipeline to stall possibly indefinitely, waiting for
these buffers to appear.
Subclasses should render unresponsive pads with either silence (audio), the
last (video) frame or what makes the most sense in the given context.
The previous implementation kept accumulating GSources,
slowing down the iteration and leaking memory.
Instead of trying to fix the main context flushing, replace
it with a GAsyncQueue which is simple to flush and has
less overhead.
https://bugzilla.gnome.org/show_bug.cgi?id=736782
Without a lock that is taken in FLUSH_START we had a rare race where we
end up aggregating a buffer that was before the whole FLUSH_START/STOP
dance. That could lead to very wrong behaviour in subclasses.
Avoiding to be in an inconsistent state where we do not have
actual negotiate caps set as srccaps and leading to point where we
try to unref ->srccaps when they have already been set to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=735042
Along with the required mandatory dependent events.
Some elements need to perform an allocation query inside
::negotiated_caps(). Without the caps event being sent prior,
downstream elements will be unable to answer and will return
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=732662
We would constantly re-post the taglist because
posted_avg_rate only gets set to avg_bitrate if
parse->priv->post_avg_bitrate is true, so if it's
false the posted rate will always differ from the
current average rate and we'd queue an update,
which leads to us spamming downstream and the
application with taglist updates.
Fix this by only queuing an update if the average
rate will actually be posted.
These taglists updates could cause expensive
operations on the application side, e.g. in Totem.
https://bugzilla.gnome.org/show_bug.cgi?id=786561
buffer is not unreferened if preroll failed
:Detailed Notes:
- Problem : video freeze when switching from pause to 1/2-FF repeatedly
- RootCause : buffer leaks in basesink
- Solution : unref the buffer if prerolled failed
:Testing Preformed:
How to Test :
pause -> 1/2 FF -> resume -> pause -> 1/2 FF ...
https://bugzilla.gnome.org/show_bug.cgi?id=784932
Holding this lock on live source prevents the source from changing
the caps in ::create() without risking a deadlock. This has consequences
as the LIVE_LOCK was replacing the STREAM_LOCK in many situation. As a
side effect:
- We no longer need to unlock when doing play/pause as the LIVE_LOCK
isn't held. We then let the create() call finish, but will block if
the state have changed meanwhile. This has the benefit that
wait_preroll() calls in subclass is no longer needed.
- We no longer need to change the state to unlock, simplifying the
set_flushing() interface
- We need different handling for EOS depending if we are in push or pull
mode.
This patch also document the locking of each private class member and
the locking order.
https://bugzilla.gnome.org/show_bug.cgi?id=783301
This is something bindings can't handle and it causes leaks. Instead
move the ref_sink() to the explicit, new() constructors.
This means that abstract classes, and anything that can have subclasses,
will have to do ref_sink() in their new() function now. Specifically
this affects GstClock and GstControlSource.
https://bugzilla.gnome.org/show_bug.cgi?id=743062
An untested pointer segfaulted in webkit while playing video
on imx6 sabrelite. It turned out that the imx plugin didn't
implement the meta transform function.
The following GST_DEBUG trace was visible:
gstbasetransform.c:1779:foreach_metadata:<conv2> copy metadata
GstImxVpuBufferMetaAPI
Thread 26 vqueue:src received signal SIGSEGV, Segmentation fault.
(gdb) bt
0x00000000 in ?? ()
0x73f8d7d8 in foreach_metadata (inbuf=0xc9b020, meta=0x474b2490,
user_data=<optimized out>) at gstbasetransform.c:1781
0x73eb3ea8 in gst_buffer_foreach_meta (buffer=buffer@entry=0xc9b020,
func=0x73f8d705 <foreach_metadata>,
user_data=user_data@entry=0x474b24d4)
at gstbuffer.c:2234
https://bugzilla.gnome.org/show_bug.cgi?id=782050
This unbalanced closing parenthesis is leftover from the commit
8b739d91e7. It used to wrap the caps but we don't seem to do that in
the current code.
So, just remove it. No functionality has been changed.
https://bugzilla.gnome.org/show_bug.cgi?id=781484
Use g_object_new() instead which nowadays has a shortcut for the
no-properties check. It still does an extra GType check in the
function guard, but there's a pending patch to remove that
and it's hardly going to be a performance issue in practice,
even less so on a system that's compiled without run-time checks.
Alternative would be to move to the new g_object_new_properties()
with a fallback define for older glib versions, but it makes the
code look more unwieldy and doesn't seem worth it.
Fixes deprecation warnings when building against newer GLib versions.
https://bugzilla.gnome.org/show_bug.cgi?id=780903
If parsing returns a non-OK flow return in the middle
of processing an input buffer, don't overwrite that
if a later return is OK again - the subclass might
return not-linked in the middle, and then discard
subsequent data without pushing while returning OK.
A later success doesn't invalidate the earlier failure,
but we should continue processing after not-linked, so
as to keep parse state consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=779831
We would add the offset a second time in _scan_for_start_code()
when we found a result, but it's already been added to the data
pointer at the beginning of _masked_scan_uint32_peek(), so the
peeked value would be wrong if the initial offset was >0, and
we would potentially read memory out-of-bounds.
Add unit test for all of this.
https://bugzilla.gnome.org/show_bug.cgi?id=778365
Otherwise when seeking/looping to the start when reaching the end,
the sink waits for the duration of the stream. So the user hears
nothing for the duration of the stream before it actually loop again.
See example attached to the bug for that.
Existing test:
gst-plugins-good/tests/icles/test-segment-seeks foo.flac
Without the patch the user hears a crack/cut at each seek.
https://bugzilla.gnome.org/show_bug.cgi?id=777780
This was totally non-obvious, the kind of big problem is that subclasses must
be able to unblock their streaming thread and continue exactly where they left off
on unpause!
https://bugzilla.gnome.org/show_bug.cgi?id=773912
It might've failed just because of flushing or other things, and we
should retry again on the next possibility if something ever calls in
here again.
https://bugzilla.gnome.org/show_bug.cgi?id=774623
Check the correct segment format value.
parse->segment.format is the format we're outputting in,
not the upstream format. Use parse->priv->upstream_format instead,
and make sure it's set in pull mode.
If the parser is not parsing a raw elementary stream, restrict
the position, duration and conversion query replies to
things we can sensibly answer about - especially don't do
random conversions to/from bytes.
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
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.
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
