The matrices were converting the wrong values with non-diagonal-only matrices.
e.g. a typical yflip matrix in [-1,1]^3 such as
1 0 0 0
0 -1 0 0
0 0 1 0
0 0 0 1
Would have actually required a matrix like this in [0,1]^3
1 0 0 0
0 -1 0 0
0 0 1 0
0 -2 0 1
Which is
1. not consistent with our multiplication convention and would require
transposing matrices or changing our multiplication order (from what is
generally used on opengl matrix guides/tutorials).
2. Produces incorrect values when input with actual vertices accounting for
the difference in multiplication order. e.g. some vertices multiplied by
the yflip matrix using vertex * yflip(== transpose(yflip) * vertex):
vertex: -> result: expected:
vec4(1,0,1,1) -> vec4(1,-2,1,1) vec4(1,1,1,1)
vec4(1,1,1,1) -> vec4(1,-3,1,1) vec4(1,0,1,1)
With the updated values, we now get the expected values.
Includes a test for this behaviour and the example above
The autotools build installs the file and sets the LICENSE_TRANSLATIONS_PATH
macro which licences.c uses as a fallback path. Do the same with meson.
https://bugzilla.gnome.org/show_bug.cgi?id=796274
This pixel format is a fully packed variant of NV12_10LE32,
a luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color range
follows the BT.2020 standard.
In order to get a better performance in hardware memory
operation, it may expend the stride, append zero data at the
end of echo lines.
Pack function by Nicolas Dufresne.
https://bugzilla.gnome.org/show_bug.cgi?id=795462
Signed-off-by: Nicolas Dufresne <nicolas@ndufresne.ca>
Signed-off-by: ayaka <ayaka@soulik.info>
For a single format in the caps, we were returning some weird answers,
like only RGB formats for a RGB input when we can also support YUV from
RGB.
Fixup of 3cfff727b1 where I thought my
previous (~6month) self had got this right. Don't trust your previous
self people!
Also yield common options to the outer project (gst-build in our case)
so that they don't have to be set manually and use array types for some
options.
Otherwise subclasses might accidentially use the old audioinfo/caps.
None of the subclasses currently uses the audioinfo/caps, but future
subclasses might.
https://bugzilla.gnome.org/show_bug.cgi?id=795827
Instead of having special cases at each GL texture creation, upload,
readback or copy for all non-8-bits-per-components.
Simply store the more specific format and retrieve the generic
component/type tuple from that.
Introduce a helper function for retrieving the generic GL format (RGBA,
RGB, RG, R, L, A) and type (BYTE, SHORT, SHORT_5_6_5) from a sized
GL format enum (RGBA8, RGB565, RG8, etc).
The problem is that even though the functions we are calling are
in-place transformation, orc automatically puts the restrict keyword
on all arguments. To silence that warning just create yet-another
variable containing the same value.
https://bugzilla.gnome.org/show_bug.cgi?id=795765
It is possible that both application and the stream are waiting
currently, if for example the following happens:
1) app is waiting because no buffer in appsink
2) appsink providing a buffer and waking up app
3) appsink getting another buffer and waiting because it's full now
4) app thread getting back control
Previously step 4 would overwrite that the appsink is currently waiting,
so it would never be signalled again.
https://bugzilla.gnome.org/show_bug.cgi?id=795551
Instead of trying to guess what profile to build, just get the possible
elements to use with the specified caps and determine the
EncodingProfile from it.
https://bugzilla.gnome.org/show_bug.cgi?id=795490
If we can guarantee the lifetime of the fd is longer than
the memory, we can use DONT_CLOSE flag not to close when release.
But it's not provided in gstdmabuf yet while gstfdmemory does.
For example, in case of using VA-API or MSDK, we would need this api.
Otherwise we should call dup to duplicate the fd.
https://bugzilla.gnome.org/show_bug.cgi?id=794829
This pixel format is a fully packed variant of NV12, a luma
pixel would take 10bits in memory, without any filled bits
between pixels in a stride. The color range follows
the BT.2020 standard.
In order to get a performance in hardware memory
operation, it may expend the stride, append zero data at the
end of echo lines.
Signed-off-by: ayaka <ayaka@soulik.info>
https://bugzilla.gnome.org/show_bug.cgi?id=795462
In the situation described in
https://bugzilla.gnome.org/show_bug.cgi?id=795397,
downstream_caps consists of two structures, the first with
the preferred rate, if at all possible (44100), the second
containing the full range of allowed rates, as audioresample
correctly tries to negotiate passthrough caps.
As audioaggregator cannot perform rate conversion, it wants
to return a fixated rate in its getcaps implementation,
however it previously directly used the first structure in
the caps allowed downstream, without taking the filter into
consideration, to determine the rate to fixate to.
With this, we first intersect our downstream caps with the
filter, in order not to fixate to an unsupported rate.
Otherwise it won't be possible to specify some profiles such as
video/x-h264,profile=(string)high-4:4:4
With this patch, we can do
video/x-h264,profile=(string)high-4\:4\:4
The default implementation for packet loss handling previously
always sent a gap event.
While this is correct as long as we know the packet that was
lost was actually a media packet, with ULPFEC this becomes
a bit more complicated, as we do not know whether the packet
that was lost was a FEC packet, in which case it is better
to not actually send any gap events in the default implementation.
Some payloaders can be more clever about, for example VP8 can
use the picture-id, and the M and S bits to determine whether
the missing packet was inside an encoded frame or outside,
and thus whether if it was a media packet or a FEC packet,
which is why ulpfecdec still lets these lost events go through,
though stripping them of their seqnum, and appending a new
"might-have-been-fec" field to them.
This is all a bit terrible, but necessary to have ULPFEC
integrate properly with the rest of our RTP stack.
https://bugzilla.gnome.org/show_bug.cgi?id=794909
the meta initialization function is provided *after* the base implementation
fields have been set so do *NOT* reset them otherwise it would result
in corrupted GstMeta.
Instead explicitely set our fields to the default values we actually want.
This commits add common elements for Ancillary Data and Closed
Caption support in GStreamer:
* A VBI (Video Blanking Interval) parser that supports detection
and extraction of Ancillary data according to the SMPTE S291M
specification. Currently supports the v210 and UYVY video
formats.
* A new GstMeta for Closed Caption : GstVideoCaptionMeta. This
supports the two types of CC : CEA-608 and CEA-708, along with
the 4 different ways they can be transported (other systems
are super-set of those).
https://bugzilla.gnome.org/show_bug.cgi?id=794901
When doing CPU Access, some architecture may require caches to be
synchronize before use. Otherwise, some visual artifact may be
visible, as the CPU modification may still resides in cache.
https://bugzilla.gnome.org/show_bug.cgi?id=794216
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
When outputting more than two channels, a channel-mask has to be
specified in the output caps.
We follow the same heuristic as other cases, when downstream
does not specify a channel-mask, we use that of the first
configured pad, and if there was none we generate a fallback
mask.
https://bugzilla.gnome.org/show_bug.cgi?id=794257
The various id3v2 specs handle the extended header sizes differently
(because hey, it wouldn't be fun otherwise).
http://id3.org/id3v2.3.0 states:
"Where the 'Extended header size', currently 6 or 10 bytes, excludes
itself."
http://id3.org/id3v2.4.0-structure states:
Extended header size 4 * %0xxxxxxx
Number of flag bytes $01
Extended Flags $xx
Where the 'Extended header size' is the size of the whole extended
header, stored as a 32 bit synchsafe integer. An extended header can
thus never have a size of fewer than six bytes.
So in id3v2.4.0 it's the *whole* extended header size (a-la ISOBMFF
atom), whereas in id3v2.3.0 it's the extended header size *excluding*
those 4 initial bytes.
And for other versions, god knows..
Fixes regression introduced in commit da607005.
https://bugzilla.gnome.org/show_bug.cgi?id=792983
Allow for sub-classes to change pad templates to
support other texture targets, and bind input textures
accordingly.
When setting the caps, also store the texture target.
By default, glfilter only reports 2D texture targets
in the default caps, but sub-classes can change that
and it would be nice if they could easily find out
which texture targets were negotiated.
This adds 2 fields to the public struct, but since
it's unreleased -base API, it's not an ABI break.
This prevents cross compilation errors like:
usr/include/xf86drm.h:40:10: fatal error: drm.h: No such file or directory
These are caused because gstgldisplay_gbm.h includes xf86drm.h .
https://bugzilla.gnome.org/show_bug.cgi?id=793837
It is the only thing gst_pb_utils_init() does and it could be
automatically called from the places in pbutils it is needed.
After 1.14 we should deprecate gst_pb_utils_init().
https://bugzilla.gnome.org/show_bug.cgi?id=793611
The current GstVideoRegionOfInterestMeta API allows elements to detect
and name ROI but doesn't tell anything about how this information is
meant to be consumed by downstream elements.
Typically, encoders may want to tweak their encoding settings for a
given ROI to increase or decrease their quality.
Each encoder has its own set of settings so that's not something that
can be standardized.
This patch adds encoder-specific parameters to the meta which can be
used to configure the encoding of a specific ROI.
A typical use case would be: source ! roi-detector ! encoder
with a buffer probe on the encoder sink pad set by the application.
Thanks to the probe the application will be able to tell to the encoder
how this specific region should be encoded.
Users could also develop their specific roi detectors meant to be used with a
specific encoder and directly putting the encoder parameters when
detecting the ROI.
https://bugzilla.gnome.org/show_bug.cgi?id=793338
Performance optimisation: Keep track whenever the streaming
thread or the application thread are waiting on the GCond for
more space or new data, and only signal on the GCond if someone
is actually waiting. Avoids unnecessary syscalls and thus
context switches.
Performance optimisation: Keep track whenever the streaming
thread or the application thread are waiting on the GCond
for more space or new data, and only signal on the GCond if
someone is actually waiting. Avoids unnecessary syscalls and
thus context switches.
When trying to create a wayland display, it may fail because there
is not actually display to connect. It this case NULL is returned
but the created instance is not freed.
This patch unrefs the failed display.
https://bugzilla.gnome.org/show_bug.cgi?id=793483
When the GstRTSPConnection class sends a RTSP over HTTP tunnelling
request, the HTTP Content-Type header is missing from the HTTP POST
request.
This isn't a problem with most servers, but there are servers that
rejects the request without there also being a Content-Type header.
RFC 1945:
Any HTTP/1.0 message containing an entity body should include a
Content-Type header field defining the media type of that body.
Apple Dispatch 28:
QuickTime Streaming uses the "application/x-rtsp-tunnelled" MIME
type in both the Content-Type and Accept headers. This reflects
the data type that is expected and delivered by the client and server.
https://bugzilla.gnome.org/show_bug.cgi?id=793110
The source offset (soff) was not incremented for each component and then
each group of 3 components were inverted. This was causing a staircase
effect combined with some noise.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This adds a 10 bit variant for NV16 packed into 32 bits little endian
words. The MSB 2 bits are padding. This format is used on Xilinx SoC and
identified with the FOURCC XV20.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This add a 10bit variant of gray scale packed into 32bits little endian
words. The MSB 2 bits are padding and should be ignored. This format is
used on Xilinx SoC and is identified with the FOURCC XV10.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This adds a 10bit variant for NV12 which packs 3 10bit components
into little endian 32bit words. The MSB 2 bits are padding and should be
ignored. This format is used on Xilinx SoC and is identified with there
with the FOURCC XV15
https://bugzilla.gnome.org/show_bug.cgi?id=789876
We can pass string constants here to g_strdup_printf(),
so do so and re-enable the -Wformat-nonliteral warning
we had to disable when merging the opengl libs.
If timestamp goes forwards more than allowed, we consider that the
timestamp belongs to the previous counting, so the extended timestamp
is unwrapped.
https://bugzilla.gnome.org/show_bug.cgi?id=783443
Tests and documentation will follow separately.
The mixer elements in the opengl plugin need to stay
in -bad for now since they use GstVideoAggregator.
https://bugzilla.gnome.org/show_bug.cgi?id=754094
This can be used in a generic way as common interface by all platforms
that, in one way or another, pass around physical memory addresses.
This is used by the gl lib and seems useful enough, so might just as
well move it next to the other allocators.
https://bugzilla.gnome.org/show_bug.cgi?id=779067
As most Wayland compositors supports XWayland, X11 backend get
selected. This also realign better GStreamer decision to what
happens with GTK and other stack out there.
This patch adds code to gldownload to export the image as a
dmabuf if requested. The element now exposes memory:DMABuf as
a cap feature, and if it is selected, the element exports the
texture to an EGL image and then a dmabuf. It also implements a
fallback to system memory download in case the exportation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=776927
Undefined symbols for architecture x86_64:
"_gst_gl_context_cocoa_get_type", referenced from:
__create_layer in libgstopengl_la-caopengllayersink.o
Might need some more in other headers, but first need to
clarify what exactly should be exported, there are some
inconsistencies (installed header files vs. funcs in docs).
It causes crashes in applications because the result of
fbGetDisplay() might be in use elsewhere in the application
and Vivante doesn't seem to do any refcounting
This reverts commit 47fd4d391e.
This patch is incorrect. It doesn't actually compile, and causes a crash
because the viv-fb window implementation needs a native EGL handle
to pass to fbCreateWindow, but the GstGLDisplayEGL handleis actually
an EGLDisplay now (and gets cast to the wrong type)
This simplifies the code a lot without any functional changes apart from
not closing the display connection. Closing the display connection is
not safe to do as it is shared between all other code in the same
process and no reference counting or anything happens at the platform
layer.
1. Propagate the GstGLDisplay we create
2. Add the created GstGLContext to the propagated GstGLDisplay
Otherwise with multi-branch GL pipelines involving gtkglsink, things
will fall apart and errors will be genarated somewhere.
