1. The PTS of all frames should not be changed.
2. Just update the DTS based on the PTS. For the frame which is not
reordered, the DTS is equal to PTS. For frame which is reordered,
the DTS is equal to previous DTS. For example:
Input: F0[D0, P0] -- F1[D1, P1] -- F2[D2, P2] -- F3[D3, P3]
Output: F0[I, D0, P0] -- F3[P, D0, P3] -- F1[B, D1, P1] -- F2[B, D2, P2]
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6764>
1. The PTS of all frames should not be changed.
2. Just update the DTS based on the PTS. For the frame which is not
reordered, the DTS is equal to PTS. For frame which is reordered,
the DTS is equal to previous DTS. For example:
Input: F0[D0, P0] -- F1[D1, P1] -- F2[D2, P2] -- F3[D3, P3]
Output: F0[I, D0, P0] -- F3[P, D0, P3] -- F1[B, D1, P1] -- F2[B, D2, P2]
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6764>
Valgrind complains about uninitialized memory used in an ioctl
Syscall param ioctl(VKI_V4L2_G_TUNER).reserved points to uninitialised byte(s)
at 0x719294F: ioctl (ioctl.c:36)
by 0x3126A817: gst_v4l2_fill_lists (v4l2_calls.c:185)
by 0x3126A817: gst_v4l2_open (v4l2_calls.c:589)
by 0x3123F1C2: gst_v4l2_device_provider_probe_device (gstv4l2deviceprovider.c:122)
by 0x3123F648: gst_v4l2_device_provider_device_from_udev (gstv4l2deviceprovider.c:301)
by 0x3123F998: provider_thread (gstv4l2deviceprovider.c:395)
by 0x796FA50: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
by 0x710CAC2: start_thread (pthread_create.c:442)
by 0x719DA03: clone (clone.S:100)
Address 0x44008a34 is on thread 11's stack
in frame #1, created by gst_v4l2_open (v4l2_calls.c:524)
Uninitialised value was created by a stack allocation
at 0x3126A024: gst_v4l2_open (v4l2_calls.c:524)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6761>
Neither LIBDIR nor LIBPL are set with the native windows Python
(unlike MSYS2), so we need to use `prefix` which takes us to the
rootdir of the Python installation.
The name is also different: it's python312.dll, not python3.12.dll.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6748>
`python.get_variable('FOO', [])` becomes `python.get_variable('FOO')`
due to how Meson treats empty arrays in arguments, which breaks the
fallback feature of get_variable().
So we need to actually check whether the variable exists before trying
to fetch it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6748>
First it derived mapping was disabled for P010 formats, but also there's an
issue with interlaced frames.
It would be possible to disable derived mapping only for interlaced (H.264
decoder and vadeinterlace) but it would spread the hacks along the code. It's
simpler and contained to disable derived completely for Mesa <23.3
Fixes: #3450
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6746>
Instead of duplicating the GStreamer format to DRM fourcc mapping, this patch
uses the GstVideo library helpers. This duplicates the big O of looking for,
since the two lists are traversed, but it's less error prone.
Partially reverts commit 547f3e8622.
Fixes: #3354
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6744>
The assertion that was present before is a bit too harsh, since there is now
a (understandable) use-case where this could happen.
In gapless use-case, with two files containing the same type (ex:audio). The
first one *does* expose a collection with an audio stream, but decoding
fails (for whatever reason).
That would cause us to have configured a audio combiner, which was never
used (i.e. not active).
Then the second file plays and we (wrongly) assume it should be activated
... whereas the combiner was indeed present.
Demote the assertion to a warning and properly handle it
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3389
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6742>
If waylandsink received buffer rate is high which causes frame
drop, the cached staged buffer will be replaced when next buffer
needs to be rendered and be freed after redraw. But there is
chance to get memory leak if ended without redraw. So need to
free staged buffer when do gst_wl_window_finalize().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6735>
There was an issue with this equality check, which was to figure out what to do
with PCR pids (whether they were part of the streams present or not) and whether
we ignore PCR or not.
Turns out ... we already took care of that further up in the function.
The length check can be simplified by just checking whether the length of
the *original* PMT and the new PMT are identical. Since we don't store "magic"
PCR streams in those, we can just use them as-is.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6719>
Set as much information as possible on the slot (including the associated
track) *before* the associated source pad is added to the element.
We need this so that incoming event/queries can be replied to if they are
received when adding the pad
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6716>
A DPB buffer held by codec picture object may not be writable
at the moment, then gst_buffer_make_writable() will unref passed buffer.
Specifically, the use after free or double free can happen if:
* Crop meta of buffer copy is required because of non-zero
top-left crop position
* zero-copy is possible with crop meta
* A picture was duplicated, interlaced h264 stream for example
Interlaced h264 stream with non-zero top-left crop position
is not very common but it's possible configuration in theory.
Thus gst_buffer_make_writable() should be called with
GstVideoCodecFrame.output_buffer directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6710>
A DPB buffer held by codec picture object may not be writable
at the moment, then gst_buffer_make_writable() will unref passed buffer.
Specifically, the use after free or double free can happen if:
* Crop meta of buffer copy is required because of non-zero
top-left crop position
* zero-copy is possible with crop meta
* A picture was duplicated, interlaced h264 stream for example
Interlaced h264 stream with non-zero top-left crop position
is not very common but it's possible configuration in theory.
Thus gst_buffer_make_writable() should be called with
GstVideoCodecFrame.output_buffer directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6710>
The goal of this code was, for programs which were updates (i.e. adding/removing
streams but not completely changing) to allow dynamic addition/removal of
streams without completely removing everything.
But this wasn't 100% tested and there are a bunch of issues which make it fail
in plenty of ways.
For now disable that feature and force the legacy "add all pads again and then
remove old ones" behaviour to make it switch.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6708>
It seems that when D3D11CreateDevice collides in time
with other D3D11 calls, in particular the proccess of
creating a shader, it can corrupt the memory in the driver.
D3D11 spec doesn't seem to require any thread safety from
D3D11CreateDevice. Following MSDN, it is supposed to be called
in the beginning of the proccess, while GStreamer calls it with each
new pipeline.
Such crashes in the driver were frequently reproducing on the
Intel UHD 630 machine.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6702>
We suspect that it's not thread safe to just create and
destroy the device from any thread, particularly because
of D3D11CreateDevice, that is not documented as thread-safe.
While D3D11CreateDevice is usually protected from outside
by the gst_d3d11_ensure_element_data, it still can cross
with the Release() method of another device.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6702>
If propose_allocation comes before set_caps, self->video_info
has not been extracted from caps and self->video_info.size is 0.
It causes buffer pool fail to set config . So need to use info
size got from query instead when propose_allocation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6687>
Otherwise, if we run in to the copy case, this can cause these
groups to stay around with queued flag set, but never actually
queued, until gst_v4l2_allocator_flush() is called, which then
erroneously frees the associated memories, causing the release
function to decrement the allocator refcount where it was never
incremented, resulting in early allocator disposal, and either
deadlock or use after free.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6685>
The caps obtained from parsing the allocation query is borrowed and
should not be unreffed. This fixes criticals assertion introduced in
1.24.1.
(gst-launch-1.0:242): GStreamer-CRITICAL **: 19:48:02.667:
gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
Fixes: 5189e8b956 ("v4l2codecs: decoders: Add DMA_DRM caps support")
Closes#3462
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6682>
Some decoder drivers need to wait enough capture buffers before
starting to decode. But the dequeued buffer flag LAST but empty
has no chance to queue back to driver, which makes decode hang
after seek. So need to queue back such kind of buffer to driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6649>
Output buffers don't have to be writable. Accepting read-only buffers
from the V4L2 buffer pool allows upstream elements to write directly
into the V4L2 buffers without triggering a CPU copy into a new buffer
from the same V4L2 buffer pool every time.
Tested with the vivid output device:
GST_DEBUG=GST_PERFORMANCE:7 gst-launch-1.0 videotestsrc ! v4l2sink device=/dev/video5
With this change, gst_v4l2_buffer_pool_dqbuf() must be allowed to not
resize read-only memories of output buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6648>
../subprojects/gst-plugins-bad/tests/check/libs/gstlibscpp.cc:41:
fatal error: gst/mpegts/gstmpegts-enumtypes.h: No such file or directory
Could only pass the needed deps to the libscpp test, but gets
messier to maintain, so let's at it for consistency.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6644>
Since https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6153 ,
subtitle "decoders" (i.e. which decode to raw text) are no longer auto-plugged
by parsebin.
But if a given format does not have a parser at all, we would end up outputting
non-time/non-parsed outputs.
In order to mitigate the issue, until such parsers are available, we check if
the subtitle stream is in TIME format or not (i.e. whether it comes from a
parser or demuxer). If not, we attempt to plug in a subtitle "decoder".
Fixes#3463
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6597>
* RED_OR_ALPHA8 will map value to alpha for OpenGL, use R8 to avoid
2nd shader
* Determine texel size for proper texture memory preparation
* QByteArray::fromRawData() does shallow copy and thus leads to use of
corrupted memory
* Make sure RGBA dummy texture is fully opaque
* QRhiTexture::create() must be called to allocate texture resources
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6581>
During RTP-Info synchronization, clock_base was temporarily switched
from the actual clock-base to the base RTP time and then back some lines
later.
Instead directly work with the base RTP time. The comment about using a
signed variable for convenience doesn't make any sense because all
calculations done with the value are unsigned.
Similarly, rtp_clock_base was overridden with the rtp_delta when
calculating it, which was fine because it is not used anymore
afterwards. Instead, introduce a new variable `rtp_delta` to make this
calculation clearer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6575>
It's not in the same period as the current RTP base time but always in
the very first period. This avoids using it again at a much later time.
The code in question is only triggered with rtcp-sync=rtp-info.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6575>
It is compared to other extended RTP timestamps all over rtpjitterbuffer
and since 4df3da3bab the initial extended RTP timestamp is not equal
anymore to the plain RTP time.
Continue passing a non-extended RTP timestamp via the `sync` signal for
backwards compatibility. It will always be a timestamp inside the first
extended timestamp period anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6575>
When the buffer DTS is estimated based on arrival time at the
jitterbuffer (rather than provided on the incoming buffer itself),
it shouldn't be used for skew adjustment. The typical case is
packets being deinterleaved from a tunnelled TCP/HTTP RTSP stream,
and the arrival times at the jitter buffer are not well enough
correlated to usefully do skew adjustments.
This restores the original intended behaviour for the 'estimated dts'
path, that was broken years ago during other jitterbuffer refactoring.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6561>
For some cameras `gst_jpeg_parse_app0()` fails on a invalid segment.
While this is likely a driver or firmware bug that should be addressed
accordingly, it's not fatal and likely does not deserve a bus message on
every frame, flooding journals.
Turn down the volume of the warnings by turning them into object
warnings. If we conclude that in some cases we'd still want bus
warnings, they can be done more fine-grained in the
`gst_jpeg_parse_appX()` functions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6539>
If parameters remain similar enough to avoid either encoder reopening
or downstream renegotiation, avoid it.
This is going to be useful for dynamic parameters setting.
To check if the stream parameters changed, so the internal encoder has
to be closed and opened again, are required two steps:
1. If input caps, format, profile, chroma or rate control mode have changed.
2. If any of the calculated variables and element properties have changed.
Later on, only if the output caps also changed, the pipeline
is renegotiated.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6519>
The last frame which has the smallest diff should be consider as
the first choice rather than the golden frame. Especially when only
one reference available, this way can improve the BD rate about 5
percentage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6507>
It might happen that the key event arrives when the d3d11videosink
is stopping. In case of GstD3D11WindowWin32 it can raise a
navigation event even when the sink is already freed, because the
window object's refcount may reach 0 in the window thread. In
other words sometimes the GstD3D11WindowWin32 lives few ms more
then the GstD3D11VideoSink, because it's freed asynchronously.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6492>
The attempt to free the domain data is happeing twice during the ptp deinit.
Once while iterating through the list domain_data and second while iterating
through the list domain_clocks, so this is crashing the application
trying to gst_ptp_deinit
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6457>
And handle the case of a NULL buffer being returned cleanly, which is
valid as long as a buffer list is returned instead. Previously this
would cause an assertion because of calling gst_buffer_unref() with
NULL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6463>
If we can calculate timestamps for buffers, then set the duration
on outgoing buffers based on the number of samples depayloaded.
This can fix the muxing to mp4, where otherwise the last packet
in a muxed file will have 0 duration in the mp4 file.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6456>
Calling gst_pad_peer_query_caps() without a filter can give us EMPTY caps, whereas all the code below
assumes that's not the case. Replacing query+intersect with a filtered query ensures we always get a subset
of the template caps back.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6454>
