Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.
So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.
This slightly changes the behaviour of gst_video_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.
If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.
So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.
This slightly changes the behaviour of gst_audio_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.
If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer
This reverts commit 8a64592481.
Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer
This reverts commit ea9b6a7e3c.
Add gst_audio_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary
API: gst_audio_decoder_set_use_default_pad_acceptcaps
Add gst_video_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary
API: gst_video_decoder_set_use_default_pad_acceptcaps
Use the object lock to protect the internal segment when updating
against access from getting the stats property.
Fix a critical in gst-inspect or when retrieving the stats
before any segment has arrived by checking whether the
segment has been initted..
last_segment is only being updated in dequeue_buffer(),
which is only called from _pull_sample(). _pull_preroll()
simply re-uses an old or dummy segment while the actual
one sits and waits in the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=751147
Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.
API: gst_video_decoder_sink_query_default
https://bugzilla.gnome.org/show_bug.cgi?id=753623
Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.
API: gst_audio_decoder_sink_query_default
https://bugzilla.gnome.org/show_bug.cgi?id=753623
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the audio tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
There was a confusion, six depayloaders where passing through the
timestamp while the base class was re-timestamping to running
time. This inconstancy has been unnoticed has in most use cases
the incoming segment is [0, inifnity] in which case timestamps are
the same as running time. With DTS/PTS shifting added (to avoid
negative values) and pcapparse sending a different segment this
started being an issue.
https://bugzilla.gnome.org/show_bug.cgi?id=753037
gstvideoencoder.h:228: Warning: GstVideo: "@transform_meta"
parameter unexpected at this location:
* @transform_meta: Optional. Transform the metadata on ...
Push all pending events before pushing the gap. This ensures the
segment is pushed before the gap so it can be properly translated
to the running time
Includes unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=753360
When there is no clock_base provided, the start position is
set to 0 instead of the original segment start value. This
would break synchronization if start was not 0.
https://bugzilla.gnome.org/show_bug.cgi?id=752228
Add logging categories for most video objects.
Remove some useless debug lines in video-info and videotestsrc.
Add a performance debug line in the video scaler.
GST_TYPE_RTSP_LOWER_TRANS used to be defined in there, not
including the generated file makes older gst-p-good fail to build,
so it constitues an API break.
Add process_rtp_packet() vfunc that works just like the
existing process() vfunc only that it takes the GstRTPBuffer
that the base class has already mapped (with MAP_READ),
which means that the subclass doesn't have to map it again,
which allows more performant processing of input buffers
for most RTP depayloaders.
https://bugzilla.gnome.org/show_bug.cgi?id=750235
This minor update should workaround a build system bug. While the
makefile has been updated to generate more enum type, there is nothing
that updates the header and would lead to the generated code to be
produced again. This minor doc fix should ensure no one get a build with
missing symbols.
E.g.
video-scaler.c: In function 'gst_video_scaler_horizontal':
video-scaler.c:1332:3: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized]
func (scale, src, dest, dest_offset, width, n_elems);
^
video-scaler.c: In function 'gst_video_scaler_vertical':
video-scaler.c:1373:3: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized]
func (scale, src_lines, dest, dest_offset, width, n_elems);
^
GCC's analyses seem to be correct, for the simple fact that if you pass
get_functions a known format, but no hscale or vscale, it'll return
True without having done anything.
Some callers check for the scale values to be not NULL, but then
hscale->resampler.max_taps could return 0.
A different approach to the one presented in this patch is to check
for those max_taps, too, before calling get_functions.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=752051
The padding (if any) is included in the length of the last packet, see
RFC 3550.
Section 6.4.1:
padding (P): 1 bit
If the padding bit is set, this individual RTCP packet contains
some additional padding octets at the end which are not part of
the control information but are included in the length field. The
last octet of the padding is a count of how many padding octets
should be ignored, including itself (it will be a multiple of
four).
Section A.2:
* The padding bit (P) should be zero for the first packet of a
compound RTCP packet because padding should only be applied, if it
is needed, to the last packet.
* The length fields of the individual RTCP packets must add up to
the overall length of the compound RTCP packet as received.
https://bugzilla.gnome.org/show_bug.cgi?id=751883
It's needed to check if pixel-aspect-ratio exists before fixating.
It does not exist if input caps is not set yet and allowed caps
does not contain pixel-aspect-ratio (e.g. when using GST_VIDEO_CAPS_MAKE)
https://bugzilla.gnome.org/show_bug.cgi?id=751932
POOL meta just means that this specific instance of the meta is related to a
pool, a copy should be made when reasonable and the flag should just not be
set in the copy.
The default implementation copies all metadata without tags, and metadata
with only the video tag. Same behaviour as in GstVideoFilter.
This currently does not work if the ::parse() vfunc is implemented as all
metas are getting lost inside GstAdapter.
https://bugzilla.gnome.org/show_bug.cgi?id=742385
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it is a division of an unsigned integer (i). Removing that check
and only checking if it is bigger than max and setting it appropriately.
CID #1308950
For alaw/mulaw we should also try to initialize the channel positions in the
ringbuffer's audio info. This allow pulsesink to directly use the channel
positions instead of using the default zero-initialized ones, which doesn't
work well.
https://bugzilla.gnome.org/show_bug.cgi?id=751144
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
Make sure to update the output segment to track the segment
we're decoding in, but don't actually push it downstream until
after buffers are decoded.
https://bugzilla.gnome.org/show_bug.cgi?id=744806
Otherwise upstream can get confused about offsets as there will
be a jump once the tags have been parsed due to the stripped area.
If upstream pulls from 0 to 100, and then tagdemux does the
tag reading and finds out that the first 200 bytes are the tag, the
next pull from upstream will have an offset of 200 bytes. So
upstream will get the following data:
0 - 100, 300 - (EOS), as it will continue requesting from where
it has last stopped, but tagdemux will add an offset to skip the
tags.
This patch makes sure that the tags have been parsed and skipped
since the first pull range call.
https://bugzilla.gnome.org/show_bug.cgi?id=744580
This reverts commit 19b9356680.
These two "profiles" are actually a complete set of profiles, which we will
need to handle separately. Unfortunately it seems like we need information
from the SPS to detect the exact profile.
The new gst_install_plugins_context_set_confirm_search() API can be used
to pass a hint to modify the behaviour of the external installer
process.
https://bugzilla.gnome.org/show_bug.cgi?id=744465
The new gst_install_plugins_context_set_desktop_id() and
gst_install_plugins_context_set_startup_notification_id() API can be
used to pass extra details to the external installer process.
https://bugzilla.gnome.org/show_bug.cgi?id=744465
These values are for now taken from x265 and need to be checked against
the spec. Especially we need to check if information from other fields
need to be taken into consideration too, e.g. the bit depth and chroma
index from the SPS.
This however makes 4:4:4 output of x265enc actually work.
Make a convenience function that combines 2 scalers to perform a 2d
scale. This removes quite a bit of overhead in method calls when doing a
typical scale and it also can reuse a piece of unused memory in the
vertical scaler.
Use the 2d scaler in video-converter and remove the other scalers and
temp memory.
Only merge scalers for selected formats.
Use nearest neighbour scaling for chroma when doing nearest neighbour
for the luma.
Also fastpath GRAY16_OE in nearest neighbour.
configure parameters correctly for packed fastpath.
Small performance tweaks for RGB and friends.
Add, but ifdef out, alternative nearest neighbour scaling, it is slower
than the current table based version.
Use memcpy instead of orc_memcpy because it is measurably faster.
Fix YUY2 and friends vertical scaling.
video-scaler.c:1331:14: error: variable 'func' is used uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
} else if (bits == 16) {
^~~~~~~~~~
video-scaler.c:1348:3: note: uninitialized use occurs here
func (scale, src_lines, dest, dest_offset, width, n_elems);
^~~~
video-scaler.c:1331:10: note: remove the 'if' if its condition is always true
} else if (bits == 16) {
^~~~~~~~~~~~~~~~
video-scaler.c:1260:27: note: initialize the variable 'func' to silence this warning
GstVideoScalerVFunc func;
^
= NULL
video-converter.c:3406:12: error: implicit conversion from enumeration type 'GstVideoFormat' to different
enumeration type 'GstFormat' [-Werror,-Wenum-conversion]
format = convert->fformat[plane];
~ ^~~~~~~~~~~~~~~~~~~~~~~
video-converter.c:3413:44: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_horizontal (h_scaler, format,
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3471:12: error: implicit conversion from enumeration type 'GstVideoFormat' to different
enumeration type 'GstFormat' [-Werror,-Wenum-conversion]
format = convert->fformat[plane];
~ ^~~~~~~~~~~~~~~~~~~~~~~
video-converter.c:3487:42: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_vertical (v_scaler, format, lines, d + out_x, i,
~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3551:12: error: implicit conversion from enumeration type 'GstVideoFormat' to different
enumeration type 'GstFormat' [-Werror,-Wenum-conversion]
format = convert->fformat[plane];
~ ^~~~~~~~~~~~~~~~~~~~~~~
video-converter.c:3569:46: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_horizontal (h_scaler, format,
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3577:42: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_vertical (v_scaler, format, lines, d + out_x, i,
~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
In function gst_video_scaler_vertical() the bits variable is always
set to either 8 or 16 in every possible format. No need to initialize it.
If the format isn't valid it goes to no_func, so there is no need to
handle the case of bits not being 8 or 16.
CID #1268401
Add API to add and get custom headers that are not
covered by our header fields enum. This is backwards
compatible in that it will also work for our defined
fields, so if we ever add a new header field to the
enum, get_header_by_name() for the same header string
will still work.
API: gst_rtsp_message_add_header_by_name()
API: gst_rtsp_message_take_header_by_name()
API: gst_rtsp_message_remove_header_by_name()
API: gst_rtsp_message_get_header_by_name()
Add fastpaths for all planar conversion and scaling.
Improve gray and alpha handling.
Add option to specify the chroma resampler method and set to linear as
default.
video-converter.c:3645:24: error: implicit conversion from enumeration type
'GstFormat' to different enumeration type 'GstVideoFormat'
[-Werror,-Wenum-conversion]
convert->fformat = fformat;
~ ^~~~~~~
video-converter.c:3667:24: error: implicit conversion from enumeration type
'GstFormat' to different enumeration type 'GstVideoFormat'
[-Werror,-Wenum-conversion]
convert->fformat = fformat;
~ ^~~~~~~
video-converter.c:3963:50: error: implicit conversion from enumeration type
'const GstVideoFormat' to different enumeration type 'GstFormat'
[-Werror,-Wenum-conversion]
if (!setup_scale (convert, transforms[i].fformat))
~~~~~~~~~~~ ~~~~~~~~~~~~~~^~~~~~~
