Direct3D feature level 10 supported GPUs were released
more than 15 years ago, around the time when Windows
Vista / 7 were released. Also our d3d11 plugin/library
does not support feature level 9.x very well already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5709>
The tags and caps were leaked for unknown streams, I'm not sure they'd be valid
in that case, but better safe than sorry.
The tags ownership is transfered when calling `gst_adaptive_demux_track_new()`
so unreffing those afterwards was a mistake.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5714>
We were previously always querying index 0, and while the number of planes per
buffer will never change, it seems more proper to query the right buffer rather
than always the first one.
This was found while reading strace logs, and wondering why the
V4L2_BUF_FLAG_MAPPED flag was present on all ¬0 indices even though that
happened before VIDIOC_EXPBUF.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5647>
- GstAnalyticRelationMeta is a base class for analytics
meta. It's able to store analytics results (GstAnalyticRelatableMtd)
and describe the relation between each analysis results.
- GstAnalysisRelationMeta also contain an algorithm able to explore
analysis results relation using a bfs.
- Relation(edge) between analysis results (vertice) are stored in an adjacency-matrix
that allow to quickly identify if two analysis results are related and by
which relation they related. It also work for indirect relation
and can provide the path of analysis results by which two
analysis results are related.
- One allocation per buffer to store analysis results. Here we rely on
the application to guess how much space will be required to store all
analysis results. This is something that could be improved
significantly but it's a starting point.
- Define common analysis results, classification, object-detection,
tracking that are subclass of GstAnalyticRelatableMtd. The also
provide exemple of how to extend GstAnalyticRelatableMtd to have them
benefit for the mechanim to express relation with other analysis
results.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4962>
Whenever that caps changes does not imply that a new segment will start.
Don't reset the last_ts if only the caps have changed. This fixes issues
if you have a stream without only first frame with TS=0, and have resolution
change happening. This was a regression introduced by !3059, which issue was
described in #1352. The reported issue is still fix after this change.
Fixes#1034
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5687>
During the video session memory allocation, the property flags can
be different from the expected ones, so do not expect all the
property flags and test it with G_MAXUINT32
It's failing with driver 525.47.26 and NVidia HW NVIDIA GeForce
RTX 3050 and 2060
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4850>
The fake video decoder ignores input bitstream except
to enforce caps restrictions. It reads video width,
height and framerate from caps. Then it just pushes
video frames without doing any decoding.
The fake video decoder just draws a snake moving from
left to right in the middle of the frame. This is a
light weight drawing while it still provides an idea
about how smooth is the rendering.
The fake video decoder inherits from GstVideoDecoder.
It is useful to measure how smooth will be the whole
rendering pipeline if you had the most efficient video
decoder. Also useful to bisect issues for example when
suspecting issues in a specific video decoder.
Handles mpeg2, mpeg4, h263, h264, theora, vp8, wmv3, msmpeg,
flash-video, vp6, vp9, wmv1, wmv2, divx but more can be
added if needed.
For now it can only output RGBA, RGBx, BGRA, BGRx.
Its rank is 0 (none) but I added a property to change it so
that it can be selected by decodebin.
gst-launch-1.0 fakevideodec rank=512 \
playbin uri=http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4http://bugzilla.gnome.org/show_bug.cgi?id=723778Closes#679
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5636>
From a multimedia perspective GLES >= 2 has the big advantage of
supporting external textures (`OES_EGL_image_external` /
`OES_EGL_image_external_essl3`), allowing various YUV formats to be
imported directly by drivers.
It appears unlikely by now that the extension will ever be ported to
GL with Vulkan becoming more popular, leaving GL without an "official"
way to import YUV formats.
Further more, for Gst internal purposes it's likely that GLES2 works
equally well if not better on most drivers these days, especially on
embedded devices.
Thus switch the default for EGL context creation to GLES2. This won't
affect apps that create their own context, but `gst-launch-1.0` etc.,
which are often used for testing so people don't have to pass
`GST_GL_API=gles2`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5509>
By sealing for future writes, we broke Wayland SHM support. It seems like the
wayland library maps the SHM in read/write mode. This is visible through no
display and an error message like this:
wl_shm@7: error 2: failed mmap fd 43: Operation not permitted
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5684>
