In the case where the stream doesn't have a framerate set and the frames
don't have a duration set, we still want to use the clipping path to
make sure we don't push buffers outside of the segment.
The problem was the previous iteration was setting a duration of 2s, which
meant that any buffer which was less than 2s before the segment start would
end up getting pushed.
Instead, use a saner 40ms (25fps single frame duration) to figure out whether
the frame could be within the segment or not
v210, UYVP and IYU1 are complex formats for which pixel stride does not really
have a meaning. If we copy width*pstride bytes per line, it's not going to do
the right thing. As a fallback, copy stride bytes per line. This might copy
uninitialized bytes at the end of each line, but at least copies the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=755392
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
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_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
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
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
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.
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
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
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.
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
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)
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
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
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
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 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 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 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))
~~~~~~~~~~~ ~~~~~~~~~~~~~~^~~~~~~
