It is the 35 mm equivalent focal length of the lens, mainly used in
photography. Tag value is stored in a double value to be consistent with
GST_TAG_CAPTURING_FOCAL_LENGTH.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
When ximagesink is given a new window handle, it should check
its geometry and if the size of the new window differs from
the previous one, create reconfigure event in order to get
a chance to negotiate a more suitable image resolution with
the upstream elements.
We can't rely on receiving Expose or ConfigureNotify from
the X server for the newly assigned window, which would also
generate reconfigure.
https://bugzilla.gnome.org/show_bug.cgi?id=765424
When converting discoverer output to an encoding profile, it makes sense to
omit these. It's very very unlikely that our encoder is going to produce bit
by bit the same codec_data or streamheader.
https://bugzilla.gnome.org/show_bug.cgi?id=765534
If we are configured to use buffering and there is no demuxer in the chain, we
still want a multiqueue, otherwise we will ignore the use-buffering property.
In that case, we will insert a multiqueue after the parser or decoder - not
elsewhere, otherwise we won't have timestamps.
https://bugzilla.gnome.org/show_bug.cgi?id=764948
We add a couple of new functions gst_sdp_media_parse_keymgmt and
gst_sdp_media_parse_keymgmt. We also implement
gst_sdp_message_attributes_to_caps and gst_sdp_media_attributes_to_caps
in terms of these new functions and also gst_mikey_message_to_caps.
gstsubparse.c: In function ‘parse_subrip’:
gstsubparse.c:988:7: error: ignoring return value of ‘strtol’, declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors
https://bugzilla.gnome.org/show_bug.cgi?id=765042
Current implementation requires all srtp and srtcp parameters to be
given in the caps. MIKEY uses only one algorithm for encryption and one
for authentication so we now allow passing srtp or srtcp parameters. If
both are given srtp parametres will be preferred.
https://bugzilla.gnome.org/show_bug.cgi?id=765027
The only way for ALSA to expose a position-less multi channels is to
return an array full of SND_CHMAP_MONO. Converting this to a
GST_AUDIO_CHANNEL_POSITION_MONO array would be invalid as
GST_AUDIO_CHANNEL_POSITION_MONO is meant to be used only with one
channel.
Fix this by using GST_AUDIO_CHANNEL_POSITION_NONE which is meant to be
used for position-less channels.
https://bugzilla.gnome.org/show_bug.cgi?id=763799
As said in its doc GST_AUDIO_CHANNEL_POSITION_NONE is meant to be used
for "position-less channels, e.g. from a sound card that records 1024
channels; mutually exclusive with any other channel position".
But at the moment using such positions would raise a
'g_return_if_reached' warning as gst_audio_get_channel_reorder_map()
would reject it.
Fix this by preventing any attempt to reorder in such case as that's not
what we want anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=763799
We currently don't log much about channel positions making debugging
harder as it should be. This is the first step in my attempt to improve
this.
https://bugzilla.gnome.org/show_bug.cgi?id=763985
There is a small window of time where the audio ringbuffer thread
can access the parent thread variable, before it's initialized
by the parent thread. The patch replaces this variable use by
g_thread_self().
https://bugzilla.gnome.org/show_bug.cgi?id=764865
When blocking the subtitle pad, it's expected that stream-start
is the first event, and that it can precede caps arriving on the
peer pad - in fact the caps can only have arrived on the peer
pad when it was pre-primed with sticky events previously.
Instead, just pass the stream-start and don't block, because
stream-start is sticky anyway.
Don't require a cue identifier preceding the time range line
when parsing WebVTT. We could also store the CueID, but it's
not using anywhere, so just ignore it for now.
Since the allocation query caps contains memory size and the pad's caps
contains the display size, an audio encoder or decoder might need to allocate
a different buffer size than the size negotiated in the caps.
This patch splits this logic distinction for audiodecoder and audioencoder.
Thus the user, if needs a different allocation caps, should set it through
gst_audio_{encoder,decoder}_set_allocation_cap() before calling the negotiate()
vmethod. Otherwise the allocation_caps will be the same as the caps in the
src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
Since the allocation query caps contains memory size and the pad's caps
contains the display size, a video encoder or decoder might need to allocate
a different frame size than the size negotiated in the caps.
This patch splits this logic distinction for videodecoder and videoencoder.
The user if needs a different allocation caps, should set the allocation_caps
in the GstVideoCodecState before calling negotiate() vmethod. Otherwise the
allocation_caps will be the same as the caps set in the src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
Doing so prevents us dropping buffers in the rare, but possible, situations,
when the stream changes SSRC and new sequence numbers does not differ
much from the last sequence number from previous SSRC. For example:
ssrc - 0xaaaa 101,102,103,104 ssrc - 0xbbbb 102, 103, 104, 105...
In the scenario above we don't want to drop the first 3 packets of
0xbbbb stream.
https://bugzilla.gnome.org/show_bug.cgi?id=764459
Make writable the buffer before pushing it lead to a buffer copy. It's
because a reference is keep for the previous buffer.
The previous buffer reference is only need to duplicate the buffer. In
drop-only mode, the previous buffer is release just after pushing the
buffer so a copy is done but it's useless.
https://bugzilla.gnome.org/show_bug.cgi?id=764319
The function gst_discoverer_info_copy doesn't copy the data members seekable
and result of the source GstDiscovererInfo.
In the case of copying a GstDiscovererInfo for later use, the seekbale will be
undefined, which in practice usually will be false, even though the seekable of
the original GstDiscovererInfo is true.
https://bugzilla.gnome.org/show_bug.cgi?id=762710
The parameter type was wrongly documenting that a GstVideoInfo structure
pointer was needed, while it needs a GstVideoFormatInfo structure
pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=764414
