Add a utility function that, given a video size and a
packed stereoscopic mode, attempts to guess if the video
is packed at half resolution per view or not, since
very few videos provide the information.
We need to scale groups of 4 bytes for YUY2 formats so round up to 4.
It's possible that there is no Y byte for the last pixel so make sure
we clamp correctly.
The API does not follow the type naming convention. Re-enable
only if one take the time to box and rename (see (rename-to SYMBOL)
annotation) all types.
When copying info from the reference input state, duplicate
all the fields of the video info. The sub-class will have the
chance to override them later.
Add flags and enums to support multiview signalling in
GstVideoInfo and GstVideoFrame, and the caps serialisation and
deserialisation.
videoencoder: Copy multiview settings from reference input state
Add gst_video_multiview_* support API and GstVideoMultiviewMeta meta
https://bugzilla.gnome.org/show_bug.cgi?id=611157
This new clock slaving method allows for installing a callback that is
invoked during playback. Inside this callback, a custom slaving
mechanism can be used (for example, a control loop adjusting a PLL or an
asynchronous resampler). Upon request, it can skew the playout pointer
just like the "skew" method. This is useful if the clocks drifted apart
too much, and a quick reset is necessary.
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
https://bugzilla.gnome.org/show_bug.cgi?id=708362
Otherwise ssrc changes via rtpsession's (deprecated!) internal-ssrc property
are not possible anymore. rtpsession was now patched to only suggest an ssrc
if it makes sense to do so.
In 2.0 we should get rid of all the properties that are also negotiated via
caps, the code and behaviour is too confusing otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=749581
According to this section of the rfc.
https://tools.ietf.org/html/rfc5506#section-3.4.2
The validation should be updated to accept more types of RTCP
packages, with this mask change feedback packages will be also
accepted.
Change-Id: If5ead59e03c7c60bbe45a9b09f3ff680e7fa4868
Micro-optimisation: if the buffer consist of just one memory, we
know we have already mapped that memory to read the headers, so
no need to map it another time to get to the payload data, we
can just set up the payload data details right there and then
and avoid another map call in gst_rtp_buffer_get_payload().
Adds up when receiving RTP-payloaded raw video which can easily
be thousands of packets per frame.
Implement a chain_list function, which avoids lots of locking
compared to the default fallback implementation in GstPad.
We may also want to do some more sophisticated timestamp
tracking here at some point, but for now leave it up to the
jitterbuffer and/or subclasses (in case buffers in the
buffer list have no timestamp set on them, there may only
be a timestamp for the whole list on the first buffer).
This provides the exact same behaviour as the default
fallback implementation.
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
Instead of returning the first video meta found on a buffer, return the
one with the lowest id (which is usually the same thing, except on
multi-view buffers)
Use g_utf16_to_utf8() instead of the more generic g_convert(), so
that we can extract text in UTF-16 format even on embedded systems
with crippled iconv support.
This code path is exercised by the id3demux test_unsync_v23
check in gst-plugins-good.
https://bugzilla.gnome.org/show_bug.cgi?id=741144
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
[API] gst_discoverer_info_to_variant
[API] gst_discoverer_info_from_variant
[API] GstDiscovererSerializeFlags
+ Serializes as a GVariant
+ Adds a test
+ Does not serialize potential GstToc (s)
https://bugzilla.gnome.org/show_bug.cgi?id=748814
This affects the pt, ssrc, seqnum-offset and timestamp-offset properties. If
they were set from a property, or we configured caps before, we try to use
that value for them. Even if the first structure of the downstream caps
specifies a different value, we check if the value is supported by other
structures.
Only if all this fails, we use the values given by downstream in the first
structure, i.e. if no properties were set and these are the first caps we
negotiate or downstream does not support our values.
By doing this we ensure that we don't spuriously change ssrcs or other fields
in the middle of the stream (and also consider property values more). Ssrc
changes would currently happen after sending an RTX packet (thus creating a
new internal source inside the rtpsession), and then renegotiating the
payloader (which then gets the RTX ssrc from rtpsession).
https://bugzilla.gnome.org/show_bug.cgi?id=749581
All those where super straight forward from the warnings gtkdoc prints. It kind
of makes sense to apply them before the list of warnings is >100 and people
complain that gtkdoc is noisy.
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
2 second frame duration is rather unlikely... but if we don't clip
away buffers that far before the segment we can cause the pipeline to
lockup. This can happen if audio is properly clipped, and thus the
audio sink does not preroll yet but the video sink prerolls because
we already outputted a buffer here... and then queues run full.
In the worst case we will clip one buffer too many here now if no
framerate is given, no buffer duration is given and the actual
framerate is less than 0.5fps.
Fixes seeking on HLS/DASH streams, when seeking into the middle of
fragments and having no framerate/buffer duration.
This will be useful for elements that wish to post unhandled navigation
events on the bus to give the application a chance to do something with
it
https://bugzilla.gnome.org/show_bug.cgi?id=747245
Take into account the different steps between Y and UV when calculating
the line size for vertical resampling or else we might not resample
enough pixels and leave bad lines.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=747790
gst_message_parse_toc() returns a reffed GstToc which is owned by the
GstDiscovererInfo. But we have to make sure we unref its previous value before
setting the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=747103
We only get here if we don't have any srcpad caps, and we're going
to override the GstAudioInfo a few lines below anyway without ever
using it if for whatever reason we get caps here.
Otherwise we would forward the GAP event without ever providing any caps,
which then would make decodebin expose a srcpad without any caps set. That's
confusing for applications and can lead to all kinds of interesting bugs.
Instead do the same as already is done in GstAudioDecoder, and try to invent
caps based on the sinkpad caps and the caps allowed by downstream and the
srcpad template caps.
https://bugzilla.gnome.org/show_bug.cgi?id=747190
Bypass g_convert/iconv if there's nothing to convert. That way,
conversion won't fail on systems where iconv doesn't support
converting utf-8 to latin1 and there's nothing to convert.
https://bugzilla.gnome.org/show_bug.cgi?id=723252
memcmp will blindly compare the reserved fields, as well as any
padding the compiler may choose to sprinkle in GstSegment.
Fixes valgrind complaints in unit tests, as well as some found via
https://bugzilla.gnome.org/show_bug.cgi?id=738216
The spec for this does not say nor imply how this should be
interpreted. The previous code would try to shift by 64 bits,
which is undefined.
Coverity 1195119
https://bugzilla.gnome.org/show_bug.cgi?id=727955
When generating segment, we can't assume the first buffer is actually
the first expected one. If it's not, we need to adjust the segment to
start a bit before.
Additionally, we if don't know when the stream is suppose to have
started (no clock-base in caps), it means we need to keep everything in
running time and only rely on jitterbuffer to synchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
Make a base class that can help with allocating fd-backed memory.
Make dmabuf extend from the base class.
We can now make methods to check if memory has an fd and get the fd for
all the different types of fd-backed memory.
Make a separate file for the code to handle the fd backed memory.
This would make it possible later to add other allocators also using
fd backed memory.
Based on patch from Mozzhuhin Andrey <nopscmn at gmail.com>
Add a table based matrix8 multiplication implementation. The algorithm
does not do any clipping so we need to make sure we never call this on
input that might need to be clipped. In general, this algorithm is
2 times faster than the orc optimized one and would be chosen for all
RGB -> YUV conversions and some YUV->YUV and RGB->RGB conversions.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732186
When the ringbuffer is deactivated and then acquired, if the audio clock
provided by the sink gets reset to zero, we need to add an offset to the
clock to make sure that subsequent samples are written out at the right
times. While we need to leave this to derived classes to take care of
when they provide their own clock (since that clock may or may not be
reset to zero), we can do this ourselves if we know the provided clock
is our own (which does reset to zero on a re-acquire).
When we are using the fast linear resampler, use the ->inc to calculate
the first and last pixel we need so that we can do vertical resampling
on the right amount of pixels.
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it in an unsigned integer. Removing that check and only checking
if it is bigger than max and setting it appropriately.
CID #1271606
Only activate the scaler fastpath for x2 up and downscale when the
scaler method is respectively nearest and linear because that is what
those fastpaths really implement.
Add support for alpha. Make it possible to copy, set and multiply the
alpha value of a frame during conversion.
Set the border alpha to 0xff by default.
Go over some of the fastpaths and add alpha handling.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=745006
