We reset the group start time to the running time of the start of the other
streams that are not flushed. This fixes seeking in gapless mode after the
first track has played.
https://bugzilla.gnome.org/show_bug.cgi?id=750013
If suburidecodebin is failed to negotiate (e.g file does not exist)
then free internal suburi variable so that 'current-suburi' property
returns correct status.
https://bugzilla.gnome.org/show_bug.cgi?id=751118
6a2f017bfa changed it to check the subtitle
factory caps if there is a text-sink but we fail to get its sinkpad. What
actually should be done here is to use the factory caps if there is no
text-sink at all.
https://bugzilla.gnome.org/show_bug.cgi?id=750785
There is the GstVideoMultiviewMode enum and the
GstVideoMultiviewFramePacking, which is a subset of the
multiview modes, with the same values as the corresponding
types from the full enum. Do some casts and use the right
times to avoid implicitly using/passing GstVideoMultiviewFramePacking
when a GstVideoMultiviewMode is needed.
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
