Don't feed 64-bit integer variable into vararg function that expects
an unsigned integer to go with GST_TAG_TRACK_NUMBER. This would
cause crashes on 32-bit platforms, and if not that then test
failures if the comparisons fail later (at least on big endian
platforms).
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it in an unsigned integer. Removing that check and only checking
if it is bigger than max and setting it appropriately.
CID #1271606
When we modify a GList (via g_list_delete_link), always reassign the
new head to the original GList. Otherwise we end up with
filtered_errors being corrupt (the head might have been the element
removed)
Use smaller steps for lower rates to allow more
fine-grained control. Handle jump across 0 properly
from both sides (just flip direction where we would
have gone down to 0 instead). Don't artificially
limit rates to +/- 10x. Print new rate.
https://bugzilla.gnome.org/show_bug.cgi?id=745174
Only activate the scaler fastpath for x2 up and downscale when the
scaler method is respectively nearest and linear because that is what
those fastpaths really implement.
Add support for alpha. Make it possible to copy, set and multiply the
alpha value of a frame during conversion.
Set the border alpha to 0xff by default.
Go over some of the fastpaths and add alpha handling.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=745006
This function is static, and only ever called with the expose lock
taken. It thus has no reason to take this lock itself.
This was introduced by one of my locking fixes from 741355.
https://bugzilla.gnome.org/show_bug.cgi?id=741355
Check if dbin->decode_chain is NULL before running drain_and_switch_chains()
because if it is, we shouldn't run that function or it will segfault.
CID #1271074
Make sure to update the output segment to track the segment
we're decoding in, but don't actually push it downstream until
after buffers are decoded.
https://bugzilla.gnome.org/show_bug.cgi?id=744806
Otherwise if there are multiple parsers we would most likely break negotiation
of the stream-format/alignment wanted by the decoders as parsers generally
support all possible stream-formats and alignments.
If caps on a newly added pad are NULL, analyze_new_pad will try to
acquire the chain lock to add a probe to the pad so the chain can
be built later. This comes from the streaming thread, in response
to headers or other buffers causing this pad to be added, so the
stream lock is taken.
Meanwhile, another thread might be destroying the chain from a
downward state change. This will cause the chain to be freed with
the chain lock taken, and some elements are set to NULL here, which
can include the parser. This causes pad deactivation, which tries
to take the element's pad's stream lock, deadlocking.
Fix this by keeping track of which elements need setting to NULL,
and only do this after the chain lock is released. Only the chain
manipulation needs to be locked, not the elements' state changes.
https://bugzilla.gnome.org/show_bug.cgi?id=741355
There was a deadlock between a thread changing decodebin/demuxer
state from PAUSED to READY, and another thread pushing data
when starting.
From the stack trace at
https://bug741355.bugzilla-attachments.gnome.org/attachment.cgi?id=292471,
I deduce the following is happening, though I did not reproduce the
problem so I'm not sure this patch fixes it.
The streaming thread (thread 2 in that stack trace) takes the demuxer's
sink pad's stream lock in gst_ogg_demux_perform_seek_pull and will
activate a new chain. This ends up causing the expose lock being taken
in _pad_added_cb in decodebin.
Meanwhile, a state changed is triggered on thread 1, which takes the
expose lock in decodebin in gst_decode_bin_change_state, then frees
the previous chain, which ends up calling gst_pad_stop_task on the
demuxer's task, which in turn takes the demuxer's sink pad's stream
lock, deadlocking as both threads are now waiting for each other.
https://bugzilla.gnome.org/show_bug.cgi?id=741355
Otherwise upstream can get confused about offsets as there will
be a jump once the tags have been parsed due to the stripped area.
If upstream pulls from 0 to 100, and then tagdemux does the
tag reading and finds out that the first 200 bytes are the tag, the
next pull from upstream will have an offset of 200 bytes. So
upstream will get the following data:
0 - 100, 300 - (EOS), as it will continue requesting from where
it has last stopped, but tagdemux will add an offset to skip the
tags.
This patch makes sure that the tags have been parsed and skipped
since the first pull range call.
https://bugzilla.gnome.org/show_bug.cgi?id=744580
Don't use private GMutex implementation details to check
whether it has been freed already or not. Just turn dispose
function into finalize function which will only be called
once, that way we can just clear the mutex unconditionally.
Also improve the waiting condition for stream switches, which was assuming
before that the condition variable will only stop waiting once when it is
signaled. But the documentation says that there might be spurious wakeups.
https://bugzilla.gnome.org/show_bug.cgi?id=736655
Test that a pipeline can change from PLAYING to PAUSED and back in
the following scenarios:
1. One track reach EOS after pushed some buffers while another track
still pushes buffers
2. One track reach EOS without buffers while another track still pushes
buffers
https://bugzilla.gnome.org/show_bug.cgi?id=736655
Change the GAP events that are currently sent from the chain function of
the current pad to all other EOS pads. They should instead be sent from
their own streaming threads.
https://bugzilla.gnome.org/show_bug.cgi?id=736655
Wait in the event function when EOS is received until all pads are EOS
and then forward the EOS event from each pads own event function.
Also send a new GAP event for EOS pads from the event function whenever
going from PLAYING->PAUSED by shortly waking up the GCond. This is needed
to allow sinks to pre-roll again, as they did not receive EOS yet because
we blocked that, but also will never get data again.
https://bugzilla.gnome.org/show_bug.cgi?id=736655
This reverts commit 19b9356680.
These two "profiles" are actually a complete set of profiles, which we will
need to handle separately. Unfortunately it seems like we need information
from the SPS to detect the exact profile.
