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.
