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))
~~~~~~~~~~~ ~~~~~~~~~~~~~~^~~~~~~
If we have timestamps on input buffers and are in trickmode no-audio
mode, then don't pass anything to the subclass for decode and simply
send gap events downstream
Only for forward playback for now - reverse requires accumulating
GAP events and pushing out in reverse order.
https://bugzilla.gnome.org/show_bug.cgi?id=735666
In trickmode no-audio mode, or when receiving a GAP buffer,
discard the contents and render as a GAP event instead.
Make sure when rendering a gap event that the ring buffer will
restart on PAUSED->PLAYING by setting the eos_rendering flag.
This mostly reverts commit 8557ee and replaces it. The problem
with the previous approach is that it hangs in wait_preroll()
on a PLAYING-PAUSED transition because it doesn't commit state
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=735666
The decoder can fail to drain on EOS if there was only one gather
set, because it will never have sent the segment event downstream
and set the output segment, and fail to detect that the rate < 0.0
Make sure to send pending events before sending all the gather data
for decode.
In gst_video_resampler_init () if method is GST_VIDEO_RESAMPLER_METHOD_NEAREST
then params.envelope is not initialized but still used later in line 382.
Make sure this variable is initiliazed to avoid undefined behaviour.
CID #1256568
Don't render out silence samples to a buffer, just
start the clock running, since any buffer with the
GAP flag will be discarded in render() now anyway.
Make the base audio sink throw away buffers marked GAP, or all
incoming buffers when performing a trick play with
GST_SEGMENT_TRICKMODE_NO_AUDIO flag set, and make sure to start
the ringbuffer when that happens so the clock starts running.
Preserve the timing calculations when rendering, so state is all
updated the same, but just don't render samples.
https://bugzilla.gnome.org/show_bug.cgi?id=735666
video-converter.c:3073:48: 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:3081:44: error: implicit conversion from enumeration type 'GstFormat' to different enumeration type 'GstVideoFormat'
[-Werror,-Wenum-conversion]
gst_video_scaler_vertical (v_scaler, format, lines, d, i, out_w);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3137:24: error: implicit conversion from enumeration type 'const GstVideoFormat' to different enumeration type 'GstFormat'
[-Werror,-Wenum-conversion]
convert->fformat = GST_VIDEO_INFO_FORMAT (in_info);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../gst-libs/gst/video/video-info.h:125:43: note: expanded from macro 'GST_VIDEO_INFO_FORMAT'
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../gst-libs/gst/video/video-format.h:361:59: note: expanded from macro 'GST_VIDEO_FORMAT_INFO_FORMAT'
~~~~~~~~^~~~~~
video-converter.c:3157:24: error: implicit conversion from enumeration type 'GstVideoFormat' to different enumeration type 'GstFormat'
[-Werror,-Wenum-conversion]
convert->fformat = GST_VIDEO_FORMAT_GRAY8;
Add fast path scaling for YUY2 and other packed YUV formats. Add a new
method to merge the scalers of the Y and UV components into one scaler.
Add faster horizontal 2tap scaler.
See https://bugzilla.gnome.org/show_bug.cgi?id=741987
Some audio sink sub-classes (pulsesink) don't start their clock
when the ringbuffer starts, but always have to on EOS. When we
explicitly need to start the ringbuffer, make sure sub-classes will
do it by (ab)using the existing eos_rendering flag.
Add support for scaling of images with pstride == 1. This can be used
to scale individual planes later.
Rework some of the scaling code to take the pstride as a parameter.
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it is an unsigned integer. Removing that check and only checking if
it is bigger than max and setting it appropriately.
CID 1256559
CLAMP checks both if n_taps is '< 0' and '> max_taps'. n_taps will never be a
negative number because it is an unsigned integer. Removing that check and only
making sure it isn't set bigger than max.
CID 1256558
Add an option to disable chroma resampling.
Improve the matrix option values so that you can choose to use the input
or output matrix or disable conversion.
The gst_discoverer_info_get_missing_elements_installer_details()
documentation and annotation says that the return value should be freed
with g_strfreev(), but actually it's owned by the GstDiscovereInfo
object and should definitely not get freed by the caller as well.
https://bugzilla.gnome.org/show_bug.cgi?id=742006
Video buffer pool will update video alignment to respect stride alignment
requirement. But haven't updated it to video alignment in configure.
Which will cause user get wrong video alignment.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741501
Otherwise calls to get the clock time might change its internal state
and the internal/external time for calibration get unbalanced leading to
a clock jump
https://bugzilla.gnome.org/show_bug.cgi?id=740834
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.
Also it ensure that we always have a clean state before start(), cleaned the
same way in every case.
The same was done already in the decoder, and we cleaned some state just above
manually that would also be taken care of by reset().
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.
The stop() vfunc might mess with some of our fields we have just
reset, which could cause memory leaks or invalid state taken over
to later.
Also the stop() vfunc, or anything called until it from another thread,
might want to be able to use the fields that were just resetted and
become confused because of that.
In the decoder we already had a workaround for things like this happening,
this workaround is not needed anymore.
The implementation of that vfunc might want to use the object lock for
something too. It's generally not a good idea to keep the object lock while
calling any function implemented elsewhere.
Also the ringbuffer can only be NULL at this point, remove a useless if block.
And in the sink actually hold the object lock while setting the ringbuffer on
the instance. Code accessing this is expected to use the object lock, so do it
here ourselves too.
Allows subclasses to do custom caps query replies.
Also exposes the standard caps query handler so subclasses can just
extend on top of it instead of reimplementing the caps query proxying.
Allows decoders to proxy downstream restrictions on caps.
Also implements accept-caps query to prevent regressions caused by the
new fields on the return of a caps query that would cause the accept-caps
to fail as it uses subset caps comparisons
Allows subclasses to do custom caps query replies.
Also exposes the standard caps query handler so subclasses can just
extend on top of it instead of reimplementing the caps query proxying.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
With the new caps query results the caps returned might have extra fields
that are not required by the decoder (framerate for image decoders) and it
causes a regression making, for example, jpegdec reject caps that don't
have framerates.
The accept-caps implementation will do 2 checks:
1) Do subset check with the template caps, making sure all the required
fields that are present on the template are present on the received caps.
2) Do a intersection check with the result of a caps query, making sure
that downstream can accept the fields in the received caps.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
Refactor the encoder's caps query proxying function to a common place
and use it in the videodecoder to proxy downstream restrictions.
The new function is private to the gstvideo lib.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
Update the new buffer size after alignment in the pool configuration
before calling the parent set_config. This ensures that the parent knows
about the buffer size that we will allocate and makes the size check
work in the release_buffer method.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741420
This reverts commit 406f32a946.
The problem was apparently that my video-orc.h was not updated and did not
include the prototype for that function. Only a "make clean" caused it to
be regenerated.
Avoid using a constant.
Avoid doing saturated adds, results are not supposed to overflow here.
Rework the C backup function a little in preparation for custom backup
functions in ORC.
See https://bugzilla.gnome.org/show_bug.cgi?id=741015
In some cases, the user might want the stream outputted by encodebin to
be in the exact same format during all the stream. We should let the
user specify when this is the case. This commit add some API in the
GstEncodingProfile to determine whether the format can be renegotiated
after the encoding started or not.
API:
gst_encoding_profile_set_allow_dynamic_output
gst_encoding_profile_get_allow_dynamic_output
https://bugzilla.gnome.org/show_bug.cgi?id=740214
It will cause the frame to be initialized with inconsistent values that then
later can cause crashes or any other kind of interesting and hard to debug
bugs.
In cases where we just call orc directly this is somewhat
superfluous, but let's do it anyway for consistency. In
other cases the compiler can hopefully use this to optimise
memory access a little.
when using variable taps and when we are limiting the number of taps,
recalculate the lanczos parameters to match the clamped value.
Set the max number of taps to 128
Make a small object to hold a pool of allocated temp lines.
Keep track of how many temp lines each conversion stage needs and use
this to allocate just enough temp lines from the temp lines object. from
the temp lines object.
When dealing with mixed interlaced, setup a scaler and chroma-resampler
for both interlaced and progressive frames and switch between them
depending on the interlace mode of the input frame.
Add an option to limit the number of taps to use in automatic mode. The
problem is that for lanczos, we might use more taps than what we can
handle with the current precision.
Rework the other options a little to make it nicer to set defaults.
Refactor GstVideoInfo init, make function to set default colorimetry.
Call fill_planes after we configure the GstVideoInfo with parameters
from the caps.
The size of the chroma planes for interlaced vertically subsampled
formats needs to be rounded up to 2, we have 2 fields with each
the same anount of chroma lines.
Keep only 1 structure with all matrix information.
Add structure to hold gamma information.
Add more options to control gamma, primaries and color matrix handling.
Add functions to compute transformations to and from XYZ and use this
to convert between primaries.
Merge gamma into the convert to and from RGB stage.
Fix border val.
Simplify the fastpath table, remove unused fields, add some more checks.
Prepare for doing full gamma corrected conversion and scaling by first
splitting the conversions from and to RGB into separate steps.
split scaling in downscaling and upscaling steps to be performed before
and after conversion respectively.
Fix clipping of images that are partially left of the video
surface, they would get clipped on the right side instead of
the left side, because the video unpack functions currently
ignore the x offset parameter. Work around that until that
is implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=739281
In case of overlay being completely or partially outside
the video frame, the offset calculations are not right,
which resulted in the overlay not being displayed as
expected, or crashes due to invalid memory access.
When the overlay rectangle is completely outside,
we need not render the overlay at all.
For partial display of overlay rectangles, src_yoff
was not being calculated, hence it was always clipping
the bottom half of the overlay, By calculating the
src_yoff, now the overlay is clipped properly.
https://bugzilla.gnome.org/show_bug.cgi?id=739281
Make an ORC version of the 2x vertical upsampling code.
Improve unit tests, test chroma up and down sampling.
memset buffer in conversion to make valgrind happy.
