Add GstVideoMultiviewFramePacking enum, and the
video-multiview-mode and video-multiview-flags
properties on playbin.
Use a pad probe to replace the multiview information in
video caps sent out from uridecodebin.
This is a part implementation only - for full
correctness, it should also modify caps in caps events,
accept-caps and allocation queries.
https://bugzilla.gnome.org/show_bug.cgi?id=611157
When traversing the color balance element channel list to find the one that
matches with the playsink proxy, the assignation was set to iterator of the
playsink proxy, not the balance element. Thus, the mapping to the values of
the balance element channel was wrong.
This patch fixes the assignation of the color balance element channel, so the
mapping to the channel of the color balance element is fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=750691
when text playbin is not enabled in the beginning, then
video_srcpad_stream_synchronizer gets linked to videochain->sinkpad
and when we try to enable text bin during play, since it is already linked to videochain,
text chain does not get linked properly. Hence unlinking the same
before linking to text chain
https://bugzilla.gnome.org/show_bug.cgi?id=748908
Summary:
So that the user can easily use the same encoding profile to render
with/without audio/video stream.
API:
gst_encoding_profile_is_disabled
gst_encoding_pofile_set_enabled
https://bugzilla.gnome.org/show_bug.cgi?id=749056
When a stream has a variable framerate, videorate calculates it and
forces it on the output caps. However, the code in _transform_caps()
currently also does that if the transform is going in the opposite
direction (GST_PAD_SRC), so during a renegotiation it tries to force
upstream to use the calculated framerate and it fails.
https://bugzilla.gnome.org/show_bug.cgi?id=750032
This part of pipeline is:
tee name=t ! visualizationbin ! streamsynchronizer name=s
t. ! s.
streamsynchronizer might block and it could starve the visualization
branch of the pipeline when it is enabled.
The visualization bin has queues internally but the other branch
that links the audiotee directly to the synchronizer is vulnerable
to block. Adding a queue between "t. ! s." fixes deadlocks.
https://bugzilla.gnome.org/show_bug.cgi?id=749676
From the API documentation: "Note that it is generally not
a good idea to reuse an existing cancellable for more
operations after it has been cancelled once, as this
function might tempt you to do. The recommended practice
is to drop the reference to a cancellable after cancelling
it, and let it die with the outstanding async operations.
You should create a fresh cancellable for further async
operations."
https://bugzilla.gnome.org/show_bug.cgi?id=739132
From the API documentation: "Note that it is generally not
a good idea to reuse an existing cancellable for more
operations after it has been cancelled once, as this
function might tempt you to do. The recommended practice
is to drop the reference to a cancellable after cancelling
it, and let it die with the outstanding async operations.
You should create a fresh cancellable for further async
operations."
https://bugzilla.gnome.org/show_bug.cgi?id=739132
GST_VIDEO_CONVERTER_OPT_ALPHA_MODE, GST_VIDEO_CONVERTER_OPT_CHROMA_MODE,
GST_VIDEO_CONVERTER_OPT_MATRIX_MODE, GST_VIDEO_CONVERTER_OPT_GAMMA_MODE and
GST_VIDEO_CONVERTER_OPT_PRIMARIES_MODE were G_TYPE_STRING with only a few valid
options. Changed those to real enums.
https://bugzilla.gnome.org/show_bug.cgi?id=749104
Upstream might want to use it to properly map timestamps to running/stream
times, if we just override it with 0 synchronization will be just wrong.
For this we remove some old 0.10 code related to segment accumulation, and
remove some more code that is useless now, and accumulate the group start time
(aka segment.base offset) manually now.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
Embedded systems often have limited charset conversion
functionality, so don't rely on g_convert() (i.e. iconv)
for UTF-16 to UTF-8 conversions, we can easily enough do
that ourselves by converting to native endianness and
then using GLib's helper functions.
This is a fixup for b2db18cda2
audioconvert: avoid float calculations when mixing integer-formatted channels
The int matrix was using gint and gint32 synonymously, which can theoretically
cause problems if gint and gint32 are actually different types.
https://bugzilla.gnome.org/show_bug.cgi?id=747005
Try harder to look for gvfs backend changes in the right
place, to make sure the plugin gets reloaded when backends
are removed or installed. We watch the gvfs mounts directory
because the files there contain absolute paths to the
backend executables, and those may not be in the usual gio
path.
https://bugzilla.gnome.org/show_bug.cgi?id=747841
We don't expect clients to send us any data, but if they do, just
ignore it. Web browsers might send us an HTTP request for example,
but some will still be happy if we just send them data without
a proper HTTP response.
There was a bug in the reading code path. We only have a small
read buffer and would provoke an EWOULDBLOCK trying to read
because we don't bail out of the loop early enough.
https://bugzilla.gnome.org/show_bug.cgi?id=743834
When shutting down the chain, we can get a deadlock when removing
a pad, if that chain was being busy streaming but blocked (eg, while
waiting for a queue to have free space).
https://bugzilla.gnome.org/show_bug.cgi?id=746480
In case upstream does not provide videorate with framerate information,
it will detect the current framerate from the buffer it received,
but if downstream forces the use of variable framerate (most probably
through the use of a caps filter with framerate = 0 / 1), videorate will
respect that.
And add some unit tests
https://bugzilla.gnome.org/show_bug.cgi?id=734424
In the case the framerate is variable (represented by framerate=0/1),
we currently end up loop pushing the first buffer and then recompute
diff1 and diff2 without updating the videorate->next_ts at all
leading to infinitely looping pushing that first buffer.
In the case of variable framerate, we should just compute the next_ts
as previous_pts + previous_duration.
https://bugzilla.gnome.org/show_bug.cgi?id=734424
The patch calculates a second channel mixing matrix from the current one. The
matrix contains the original values * (2^10) as integers. This matrix is used
when integer-formatted channels are mixed.
On a ARM Cortex-A8, single core, 800MHz this improves performance in a
testcase from 29s to 9s for downmixing 6 channels to stereo.
https://bugzilla.gnome.org/show_bug.cgi?id=747005
If a new pad is added after playbin has been put to READY/NULL it
should ignore new pads as it is shutting down.
This can happen when the pipeline fails to preroll (is still in READY)
and the user gives up on waiting or an error that doesn't reach
the demuxer occurs (on some event handling) and it will continue to
work and exposing pads while playbin has been put to NULL.
Without this check an input-selector is created and set to PAUSED
state, preventing playbin from properly shutting down in case it
has data blocked inside it.
audio_convert_convert unpacks to default format (signed) before calling
quantize, and the unsigned variants were equivalent to signed anyway,
so we just get rid of them.
Since range size is always 2^n, we can simply use modulo (implemented
with a bitmask).
The previous implementation used 64-bit integer division, which is
done in software on ARMv7. Although the divisor was constant, the
division could not be transformed into "multiplication by magic number"
since the dividend was 64-bit.
The now-unused and not-so-fast gst_fast_random_(u)int32_range functions
were removed.
Also, implementing bug fixes:
1) ADD_DITHER_TPDF_HF_I no longer discards bias.
2) We change TPDF's noise range to be the same as RPDF's. Previously,
RPDF's noise ranged:
{ bias - dither, bias + dither }
while TPDF's noise ranged:
{ bias/2 - dither/2, bias/2 + dither/2 - 1 } +
{ bias/2 - dither/2, bias/2 + dither/2 - 1 } =
{ bias - dither, bias + dither - 2 }
Now, both range:
{ bias - dither, bias + dither - 1 }
https://bugzilla.gnome.org/show_bug.cgi?id=746661
This fixes a race where the use-buffering property on a multiqueue was
set before the queue depth was changed from it's high preroll limits to
lower playback limits. This resulted in buffering messages being emitted
by the multiqueue in the short window between use-buffering being
set and the queue depth being reset.
https://bugzilla.gnome.org/show_bug.cgi?id=744308
The variables could have changed when the lock was released
to push a gap event. Streamsynchronizer needs to check them
again before going to sleep.
Bonus: fix a comment typo
multisocketsink now understands the new GstNetControlMessageMeta to allow
sending control messages (ancillary data) with data when writing to Unix
domain sockets.
Thanks to glib's `GSocketControlMessage` abstraction the code introduced
in this commit is entirely portable and doesn't introduce and additional
dependencies or conditionally compiled code, even if it is unlikely to be
of much use on non-UNIX systems.
