If we e.g. have AVI with DV container with video/audio inside the DV
container, we can't handle this at this point with an encoding profile.
Instead of erroring out, flatten the container hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=765708
This tag match the EXIF_TAG_FOCAL_LENGTH_IN_35_MM_FILM exif tag and is
stored on a short. Hence there is a precision loss compared to the
GstTag which is a double value.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
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 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
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.
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
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
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
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
P010 is a YUV420 format with an interleaved U-V plane and 2-bytes per
component with the the color value stored in the 10 most significant
bits.
https://bugzilla.gnome.org/show_bug.cgi?id=761607
---
Changes since v2:
- Set bits=16 in DPTH10_10_10_HI
Changes since v1:
- Fixed x-offset calculation in uv.
- Added 6-bit shifts to FormatInfo.
