This fixes simplification of caps with GstFractionRange structures,
for example, this caps:
video/x-raw, framerate=(fraction)5/1; video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
can now be simplified to:
video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
instead of:
video/x-raw, framerate=(fraction){ 5/1, [ 5/1, 30/1 ] }
And this:
video/x-raw, framerate=(fraction)[ 2/1, 5/1 ]; video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
can be simplified to:
video/x-raw, framerate=(fraction)[ 2/1, 30/1 ]
instead of
video/x-raw, framerate=(fraction){ [ 2/1, 5/1 ], [ 5/1, 30/1 ] }
This fixes overly-complicated GL caps set by avfvideosrc on macOS and
iOS when capturing from a webcam.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4132>
Removing a meta from a buffer means one doesn't have access to it
anymore. Instead use the already reffed composition directly.
Fixes a use-after-free in the following pipeline:
... ! vulkanupload ! timeoverlay ! vulkanoverlaycompositor ! ...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4143>
As specified in EIA/CEA-608-B section 8.4:
When closed captioning is used on line 21, field 2, it shall conform
to all of the applicable specifications and recommended practices as
defined for field 1 services with the following differences:
a) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 14h, 20h to 14h, 2Fh in field 1, shall be replaced
with 15h, 20h to 15h, 2Fh when used in field 2.
b) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 1Ch, 20h to 1Ch, 2Fh in field 1, shall be replaced
with 1Dh, 20h to 1Dh, 2Fh when used in field 2.
This means simply switching the "field" field in the caps isn't enough for
converting raw 608 from one field to another, some control codes also
need to be amended.
+ Adds simple test
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4126>
GstBufferPool implementation was referenced for this GstD3D11PoolAllocator,
for example GstAtomicQueue, various atomic operations, and GstPoll ones.
However, such combination seems to be almost pointless
since gst_poll_{read,write}_control() takes mutex and also
GstPoll uses Win32 event handle internally.
Use simple SRWLOCK and CONDITION_VARIABLE instead, and don't make things
complicated/inefficient.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2887>
When we run Cheese 41.1 on our imx platform, Cheese preview freeze
at first frame.
During pipeline state changing from NULL to PLAYING, if there are
both elements that state change asynchronously and state change
with no preroll in the bin, the element inside may send ASYNC_DONE
message to it, while the bin's pending state is VOID_PENDING.
In this case, the bin will not post ASYNC_DONE message to parent
bin, which makes parent bin thinks that there are still elements
in it that haven't completed state changing, causing the pipeline
freeze in an intermediate state.
This commit modifies the bin_handle_async_done() function. When the
bin, whose pending state is VOIDING_PENDING, receives the ASYNC_DONE
message, it will also post this message to its parent bin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3490>
A flush is resetting or not depending on the reset_time argument in the
FLUSH_STOP event is set.
Resetting flushes reset the running time to zero and clear any existing
segment. These are the kind of flushes used by flushing seeks, and by far the
most common. Non-resetting flushes are much more niche, used for instance for
quality changes in adaptivedemux2 and MediaSource Extensions in WebKit.
A key difference between the seek use case and the quality change use case is
that the latter is much more removed from the player. Seeks generally occur
because an user request it, whereas quality changes can be automatic.
Currently, there are three notable cases where position queries fail:
(a) before pre-roll, as there is no segment yet. This is one is understandable,
as for at least some time before pre-roll, we cannot know if a media stream
would start at 0 or any other position, or the duration of the stream for that
matter.
(b) after a resetting flush caused by a seek. This kind of flush resets the
segment, so it's not surprising position queries fail. This is inconvenient for
applications, as it means they always need to handle position reporting (e.g.
in UI) separately every time they request a seek, e.g. by caching the seek
target and using it when the position query fail. I'm not fond of this
behavior, as it's unintuitive and makes GStreamer harder to use, but at this
point could be difficult to change and it's not within the scope of this
proposal.
(c) after a non-resetting flush, e.g. caused by a quality change. The segment
is not reset in this case. Position queries work until a FLUSH_STOP is sent.
Querying position after a FLUSH_START but before a FLUSH_STOP works, and
returns the position the sink was at the moment the FLUSH_START was received.
**This in fact the only reliable way (short of adding probes to the sink
element) to get this position**, as FLUSH_START receival is asynchronous with
playback.
In the case (c), as of currently, position queries fail once the FLUSH_STOP is
received. But unlike in (b), the application has no position to fall back to,
as the FLUSH_START was initiated by elements inside the pipeline that are in a
lower layer of abstraction. Specific applications that have control of both the
player and the internal element doing the flushing -- such as WebKit -- can
still work around this problem through layer violations (lucky!), but this
still puts in question this behavior in GStreamer.
This patch fixes this case by amending the position query handler of basesink,
which was previously erroneously returning early with "wrong state", even
though the flush occurs in PAUSED or PLAYING.
A unit test checking this behavior has also been added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3471>
The code wants to prepend one byte to every byte pair. It correctly did
so by working backwards pair-wise, but then didn't work backwards
instead of each individual pair / future triplet, overwriting
information before attempting to read it.
The code also failed to update the len pointer after prepending.
This fixes both issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4100>
The abort() method of SourceBuffer in Media Source Extensions is
expected to flush the demuxer and discard the current fragment,
if any. The configuration of tracks, if any, should be preserved.
qtdemux has different behavior for flush events depending on the
context.
This patch activates the intended behaviour only for streams of the
VARIANT_MSE_BYTESTREAM type, conformant to the ISO BMFF Bytestream
specification[1]. This flush behaviour is the same as the one
already in use for adaptivedemux sources.
[1] https://www.w3.org/TR/mse-byte-stream-format-isobmff/https://bugzilla.gnome.org/show_bug.cgi?id=795424
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4101>
Removing sockets from the epoll for cancellation is unreliable and might
not be thread-safe. Rather, have SRT watch a FD from the cancellable if
available. Keep the cancellable cancelled while we're not open.
Use the regular single-socket `sock` and `poll_id` fields for the
listening thread instead of duplicating them.
Before polling we need to check the socket state. SRT closes broken
sockets by itself and when the epoll contains our cancellation FD it can
no longer be empty, which was an error before.
Treat more failures in the read and write operations as an opportunity
to try a reconnect.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4087>
Seems that SRT can remove the socket from the poll by itself when the
connection gets closed. Consider this an error condition and ensure we
only "abort successfully" when we're actually trying to unlock.
Needs more investigation but this is enough to prevent the element from
getting stuck not reporting an error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4087>
In tests in the rust bindings we end up with 2 thread initializing
concurrently, and it should not be a problem, -validate should be MT
safe.
Using a recursive mutex as we might recursively init for some reason
and we are not on the hot path here in any case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4089>
Recursively invoking the NSMainLoop can cause crashes in
applications that don't expect it. Instead of waiting for
permission to be granted, move the wait later - until we
actually need device permissions when starting the capture
session. That moves the wait into the streaming thread
instead of the application thread that's setting the pipeline
state to READY.
Instead of a manual state change implementation to open
and close the device, use the basesrc start/stop methods that
are intended for the purpose.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4083>
There may be garbage or some bits before a SOI comes in some problematic
mjpeg streams. For example, some network error may cause the EOI marker
of the previous frame lost, and when the new frame's SOI comes, we still
use the state of the last frame, which will generate errors.
For this kind of frames without EOI, if that frame already has some data
(the SOS segment is detected), we still push it as a frame with CORRUPTED
flag set. But if not, we just discard all the data before the new SOI.
Co-Authored-By: Víctor Jáquez <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4039>
The previous implementation was a bit primitive, assuming the subclass
had registered a template name starting with sink_ . Instead make
the effort of parsing the actual template name, and use that to generate
the final pad name.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4032>
This patch prevents a possible race condition from taking place between the EOS event handling and rtcp send
function/thread.
The condition starts by getting the GST_EVENT_EOS event on the send_rtp_sink pad, which causes two core things
to happen -- the event gets pushed down to the send_rtp_src pad and all sessions get marked "bye" prior to
completion of the event handler. In another thread the rtp_session_on_timeout function gets called after an
expiration of gst_clock_id_wait in the rtcp_thread function. This results in a call to the
ess->callbacks.send_rtcp(), which is configured as a function pointer to gst_rtp_session_send_rtcp via the
RTPSessionCallbacks structure passed to rtp_session_set_callbacks in the gst_rtp_session_init function.
In the race condition, the call to gst_rtp_session_send_rtcp can have the all_sources_bye boolean set to true
while GST_PAD_IS_EOS(rtpsession->send_rtp_sink) evaluates to false. This is the result of gst_rtp_session_send_rtcp
running before the send_rtp_sink's GST_EVENT_EOS handler completes. The exact point at which this condition occurs
is if there's a context switch to the rtcp_thread right after the call to rtp_session_mark_all_bye in the
GET_EVENT_EOS handler, but before the handler returns.
Normally, this would not be an issue because the rtcp_thread continues to run and indirectly call
gst_rtp_session_send_rtcp. However, the call to rtp_source_reset sets the sent_bye boolean to false, which ends up
causing rtp_session_are_all_sources_bye to return false. This gets passed to gst_rtp_session_send_rtcp and the EOS
event never gets sent.
The race condition results in the EOS event never getting passed to the rtcp_src pad, which prevents the bin and
pipeline from ever completing with EOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3798>
These checks were introduced to prevent exposing ARGB64/RGBA64 in the caps
when running on M1 Pro/Max with macOS <13 because of a bug in VideoToolbox.
Unfortunately, the initial buffer size of 15 is too short when running
in a VM - the CPU brand string there looks like "Apple M1 Pro (Virtual)",
which due to its length causes sysctlbyname to return -1, resulting in
broken formats still showing up in the caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4080>
We did several things to enable the new memory logic in msdkdec:
(1) We always use video memory for decoder in linux path;
(2) We give negotiated pool to alloc_pool stored in GstMsdkContext which
will be used in callback mfxFrameAllocator:Alloc to alloc surfaces as
MediaSDK needs, and this pool is also available for decoder itself;
(3) We modify decide_allocation process, that is we make pool negotiaion
before gst_msdk_init_decoder to ensure the pool is decided and ready for
use in mfxFrameAllocator:Alloc callback; then we will consider the case
when we need to do the gpu to cpu copy.
(4) In gst_msdkdec_finish_task, we modify the way for copy following the
logic in (3).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3439>
Add a pool creation function name as 2 for later use which will create
va pool for video memory in linux and keep system pool for windows.
This gst_msdkdec_create_buffer_pool2 will replace gst_msdkdec_create_buffer_pool
when all the memory allocation modifications are ready in the commits after.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3439>
Rewrite gst_msdk_frame_alloc and name it as xxx_2 before applying it.
It uses negotiated bufferpool stored in GstMsdkContext to allocate buffers
in the callback MfxFrameAllocator:Alloc, then extract VASurface from buffer,
wrap it as mfxMemIDs and pass these IDs to MediaSDK/oneVPL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3439>
The `add_candidate` vfunc of the GstWebRTCICE interface gained a GstPromise
argument, which is an ABI break. We're not aware of any external user of this
interface yet so we think it's OK.
This change is useful in cases where the application needs to bubble up errors
from the underlying ICE agent, for instance when the agent was given an invalid
ICE candidate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3960>
The signal triggers an asynchronous task on the PC thread but in some cases it
can be useful for apps to be notified when the task completed. This method of
the PeerConnection spec also returns a Promise so the interface is now more
coherent with the spec.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3960>
Read and flush console buffer from the console thread immediately,
instead of main thread. Otherwise (if main thread is busy)
the console thread will keep adding idle source and then main thread
will be unresponsive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4067>
The av1decoder class does not implement the ->parse() virtual function,
and we always need to add the av1parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The vp9decoder class does not implement the ->parse() virtual function,
and we always need to add the vp9parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The vp8decoder class does not implement the ->parse() virtual function,
it can only accepts frame aligned data. If some element such as filesrc
feed it with unaligned data, the behaviour is undecided. So we should
set_needs_format of the decoder to TRUE, then it can fail with a
"not-negotiated" error early, rather than go on and generate unexpected
error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The mpeg2decoder class does not implement the ->parse() virtual function,
and we always need to add the mpegvideoparse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The h264decoder class does not implement the ->parse() virtual function,
and we always need to add the h264parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The h265decoder class does not implement the ->parse() virtual function,
and we always need to add the h265parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
Raw 608 caps can now contain a "field" field. On the input side it
signifies that the input raw 608 is attached to either field 0 or 1,
on the output side it allows selecting whether to extract the raw 608
data for field 0 or 1 for field-aware formats.
In addition, it is also allowed to use ccconverter to "convert" 608
field 0 to 608 field 1 (and conversely), this is passthrough as the
change only needs to happen in the caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4031>
These parameters are not actually `out` parameters but must
be allocated and zero-initialized by the calling function.
Marking them as `out caller-allocates` will cause memory
corruptions when calling these APIs from e.g., Python code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4051>
The dimension of the overlay texture directly corresponds to the size of the overlay **buffer** which is given by its video meta.
The dimension at which the overlay should be displayed directly correspond to the overlay `render_width`and `render_height`.
This match the behavior of glimagesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4046>
It's only malformed data in APP when its length is less than 6 chars,
because it should have at least an id string. Otherwise, if the id string
is not handled, no warning is raised, only a debug message noticing it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3943>
Fixes the following valgrind error:
==616== Conditional jump or move depends on uninitialised value(s)
==616== at 0x4900E34: gst_debug_print_object (gstinfo.c:1143)
==616== by 0x49010B6: gst_info_printf_pointer_extension_func (gstinfo.c:1215)
==616== by 0x4959FDB: __gst_printf_pointer_extension_serialize (printf-extension.c:47)
==616== by 0x495A487: printf_postprocess_args (vasnprintf.c:258)
==616== by 0x495A52C: __gst_vasnprintf (vasnprintf.c:290)
==616== by 0x4959F8F: __gst_vasprintf (printf.c:154)
==616== by 0x4901C1F: gst_debug_message_get (gstinfo.c:791)
==616== by 0x4901C75: _gst_debug_log_preamble (gstinfo.c:1431)
==616== by 0x4903208: gst_debug_log_default (gstinfo.c:1575)
==616== by 0x49020BA: gst_debug_log_full_valist (gstinfo.c:624)
==616== by 0x490211D: gst_debug_log_valist (gstinfo.c:656)
==616== by 0x49021AD: gst_debug_log (gstinfo.c:533)
==616== by 0x48DDC11: gst_buffer_copy_into (gstbuffer.c:693)
==616== by 0x48DF5F1: gst_buffer_copy_with_flags (gstbuffer.c:727)
==616== by 0x48DF640: gst_buffer_copy_deep (gstbuffer.c:756)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4034>
When the QoS stats are reset (e.g. changing the source) the counters for
dropped + rendered frames are reset to zero which result in negative values
for their difference. This results in max-fps getting pegged at an extremely
high value.
```
fpsdisplaysink.c:373:display_current_fps:<fpsdisplaysink0> Updated max-fps to 36840705952231460864.000000
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3989>
Makes "start-bitrate" work without setting "connection-speed" property. Having
another property set as a requirement for this one to work is unexpected.
This commit allows to request some initial bitrate for first segment, then
go into adaptive streaming for the rest of media playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3895>
When constructing an output profile using --profile-from, it is useful
to be able to override the top level container profile.
Expose a --container-profile option that applies as an override after
other methods for constructing an output profile have run. If no other
method was used, this will result in an empty top level container.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3977>
Instead of creating new decoder instance per new sequence,
re-use configured decoder instance via cuvidReconfigureDecoder()
API. It will make output surface reusable without re-allocation.
Also, in order for application to be able to reserve higher resolution
output surface, "init-max-width" and "init-max-height" properties are
added to each decoder.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3884>
Call input resource map functions (i.e., nvEncRegisterResource,
nvEncUnregisterResource, nvEncMapInputResource, and
nvEncUnmapInputResource) only once and reuse the mapped resources,
instead of per input frame map/unmap
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3884>
