The current _directviv_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _directviv_upload_accept(), we should only accept the system
memory as input caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _gl_memory_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _gl_memory_upload_propose_allocation(), we should only allocate
the allocator and buffer pool for the caps with "memory:GLMemory"
feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _upload_meta_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _raw_data_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
We also should recognize the system memory caps in _accept() early, if
the input is not system memory, we just return early.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
Most of the time, the RGB kind formats are OpenGL native supported
format which has only one plane. They can be imported at one shot
using no matter DIRECT or INDIRECT mode.
While YUV kind formats which have multi planes have two ways to import.
They can be DIRECT imported, which requires GL_OES_EGL_image_external
extension. The output format should be RGBA and TARGET should be set
as OES after imported. The other way, they can be INDIRECT imported,
which makes each plane as a texture. In this mode, the imported textures
have different fourcc from the original format. For example, the NV12
format can be imported as a R8 texture for the first plane and RG88
texture for the second plane. The output TARGET should be sets as 2D
in this mode.
When converting sink caps to src caps, we first filter the feature of
"video/x-raw(memory:DMABuf)" and system memory. Then Based on the
external_only flag (INDIRECT mode does not care while DIRECT mode cares),
we transform the drm-format into the gst video format.
When converting src caps into sink caps, we first filter the correct
TARGET(INDIRECT mode contains 2D only while DIRECT mode contains 2D,
OES or both of them) gstructure. Then Based on the include_external flag
(INDIRECT mode always true while DIRECT mode depends on TARGET), we
transform the gst video format into drm-format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
When switching from a raw stream to an encoded stream we need to make sure the
slot is unlinked, there is code in place for this but it wasn't triggered
because the slot being reconfigured wasn't advertised as linked beforehand.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5126>
Pass GstVideoInfoDmaDrm or GstVideoInfo whenever possible, avoiding passing
strange combination of GstVieoFormat + modifier. Even though we don't have any
at the moment, this also allow supporting GstVideoFormat that are not supported
in our DRM integration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5120>
When we fill a bitstream buffer the buffer might be too small to hold
the entire frame. Only resize to the filled size, preventing the
following assertion to happen.
gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5100>
Shader compilation was failing on macOS:
gstglslstage.c:519:_compile_shader:<glslstage1> fragment shader compilation failed:
ERROR: 0:10: 'input_swizzle' : syntax error: Array size must appear after variable name
Co-authored-by: Matthew Waters <matthew@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5123>
According to libva API description, cu_qp_delta in VAConfigAttribValEncHEVCFeatures
is supposed to be used as a flag not the value of depth. And if flag enabled,
diff_cu_qp_delta_depth should be decided by log2_diff_max_min_luma_coding_block_size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5068>
Rework the va_map_unlocked() after we keep mapping behavior (whether to
use derive) consistent with allocator_try stage. Also remove the flag
for iHD case because pitch/stride difference between vaCreateImage and
vaDeriveImage only possibly happen on iHD by now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5046>
In gst_va_allocator_try, the first try is to use derive_image, if it
succeeds, we should use info from derived image to create bufferpool.
If derive fails, then try create_image and give created image info
to the pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5046>
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2771
This EOS branch exists so that if a seek with a stop is made, qtdemux
stops accepting bytes from the sink after the entire requested playback
range is demuxed, as otherwise we could keep download content that is
not being used.
This patch fixes two flaws that were present in that EOS check:
1) A comparison was made between track time and movie time without conversion.
This made the check trigger early in files with edit lists. This patch fixes
this by converting the track PTS to movie PTS (stream time) for the check.
2) To avoid sending a EOS prematurely when the segment stop is within a GOP and
B-frames are present, the check for EOS should only be done for keyframes. I
gather this was already the intention with the existing code, but because it
used `stream->on_keyframe` instead of the local variable `keyframe` the old
code was checking if the *previous* frame was a keyframe.
It's interesting to note that these two flaws in the old code mask each other
in most cases: the track PTS will have reached the movie end PTS, but EOS would
only be sent if the previous frame was a keyframe. A simple case where they
wouldn't mask each other, reproducing the bug, is a sequence of 3 frame GOPs
with structure I-B-P.
The following validateflow tests have been added to future-proof the
fix:
* validate.test.mp4.qtdemux_ibpibp_non_frag_pull.default
* validate.test.mp4.qtdemux_ibpibp_non_frag_push.default
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5021>
