- Feb 14, 2018
-
-
George Kiagiadakis authored
This is useful if the output buffers are planar and have extra padding on each plane, in which case size/bpf does not represent the number of valid samples.
-
George Kiagiadakis authored
Aggregation will break the layout, as it concatenates buffers, and fixing it here would be much more inefficient than configuring the actual decoder implementation to output larger buffers.
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
adder needs more than just trivial work to support planar buffers properly because it currently reads sub-buffers from GstCollectPads in order for all of them to have matching sizes. In planar mode, this means it would truncate some channels and mix them up in strange ways. It only works if all input buffers in all sink pads have matching sizes.
-
George Kiagiadakis authored
-
George Kiagiadakis authored
Essentially this moves the truncation logic out of gst_audio_buffer_clip() so that it can be used in other places, like in audiorate.
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
George Kiagiadakis authored
-
- Feb 10, 2018
-
-
Edward Hervey authored
Buffering messages are only sent for the active group (in case there is more than one). If the inactive group posts buffering messages we keep the last one around and will post it once it becomes the playing one.
-
François Laignel authored
After eos, decodebin3 enters a loop sending eos events which causes high cpu usage. https://bugzilla.gnome.org/show_bug.cgi?id=792693
-
Edward Hervey authored
In order to flush out multiqueue, we send again a STREAM_START and then a EOS event. The problem was that was that we might end up pushing out on the output of multiqueue (and therefore decodebin3) a series of: * EOS / STREAM_START / EOS Apart from the uglyness of such output, If decodebin3 is used with elements such as concat on their output, they might potentially block on that second STREAM_START. In order to make sure we don't end up in that situation we send a custom STREAM_START event when refreshing multiqueue (which we drop on the output) and we don't special case EOS events on streams on which we already got EOS. At worst we now end up sending at most two EOS on the output of multiqueue (and decodebin3).
-
Edward Hervey authored
Similar in vein to the playbin2 architecture except that uridecodebin3 are prerolled much earlier and all streams of the same type are fed through a 'concat' element. This keeps the philosphy of having all elements connected as soon as possible. The 'about-to-finish' signal is emitted whenever one of the uridecodebin is about to finish, allowing the users to set the next uri/suburi. The notion of a group being active has changed. It now means that the uridecodebin3 has been activated, but doesn't mean it is the one currently being outputted by the sinks (i.e. curr_group and next_group). This is done via detecting GST_MESSAGE_STREAM_START emission by playsink and figuring out which group is really playing. When the current group changes, a new thread is started to deactivate the previous one and optionnaly fire 'about-to-finish'.
-
Edward Hervey authored
Apologies for the big commit, but it wasn't really possible to split it in anything smaller. * Switch to uridecodebin3 instead of managing urisourcebin and decodebin3 ourselves. No major architectural change with this. * Reconfigure sinks/outputs when needed. This is possible thanks to the various streams-related API. Instead of blocking new pads and waiting for a (fake) no-more-pads to decide what to connect, we instead reconfigure playsink and the combiners to whatever types are currently selected. All of this is done in reconfigure_output(). New pads are immediately connected to (combiners and) sinks, allowing immediate negotiation and usage. * Since elements are always connected, the "cached-duration" feature is gone and queries can reach the target elements. * The auto-plugging related code is currently disabled entirely until we get the new proper API. * Store collections at the GstSourceGroup level and not globally * And more comments a bit everywhere NOTE: gapless is still not functional, but this opens the way to be able to handle it in a streams-aware fashion (where several uridecodebin3 can be active at the same time).
-
Edward Hervey authored
With push-based sources, urisourcebin will emit this signal when the stream has been fully consumed. This signal can be used to know when the source is done providing data.
-
Edward Hervey authored
In the same vein as old uridecodebin except that it also accepts a suburi and uses urisourcebin and decodebin3 internally
-
Edward Hervey authored
Those properties doesn't exist on playbin3, don't emit a notify for that
-
Edward Hervey authored
That property doesn't exist
-
Edward Hervey authored
-
Edward Hervey authored
-
Edward Hervey authored
-
Edward Hervey authored
Upstream might respond negatively to the event, whereas we actually handled it.
-
Edward Hervey authored
-
Edward Hervey authored
-
Edward Hervey authored
We only need to take the input lock when adding/removing inputs from the list.
-
Edward Hervey authored
The lock is never used
-
Edward Hervey authored
They were never used and we need a better system
-
Edward Hervey authored
It is not needed in the new streams-aware world
-
Edward Hervey authored
It was never used and makes no sense in the new streams-based world
-