On macOS, you always get your own 'timeline' for the AudioUnit session, so timestamps start from 0.
On iOS however, AudioUnit seems to give you a 'shared' timeline so timestamps start at a later, non-0 point in time.
Simply offsetting seems to do the trick.
This was causing osxaudiosrc to not output any sound on iOS.
Regressed in 2df9283d3f
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7856>
At some point in iOS 17, this call started waiting for the first render callback (io_proc) to finish.
In our case, that callback also takes the ringbuf object lock by calling gst_audio_ring_buffer_set_timestamp(),
which results in a deadlock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7856>
A correctly configured AVAudioSession is needed on iOS to:
- allow the application to capture microphone audio (in some cases)
- avoid playback being silenced in silent mode
Without this, initializing AudioUnit for capture can fail on iOS >=17 (from my testing).
Since AVAudioSession has a lot of settings, in most cases its setup should be handled by the user/app.
However, just to have a basic default scenario covered, let's configure the bare minimum ourselves,
and allow anyone to disable that behaviour by setting configure-session=false on src/sink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7856>
For some frames with decode-only flag, the v4l2 decoder will not
put them in output list. The corresponding decode-only frames will
be still kept in input list, which may cause potential performance
issue when the input list is full. So release the decode-only frames
according to the decode-only flag after they are processed by decoder
driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8153>
The matrix multiplication makes some assumption about the element
values to simplify the math with fixpoint values. If this is allowed
for the given matrices is now checked first.
Then the debug output for matrix and a comment have been fixed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8127>
Contains the following updates:
* New properties on avfvideosrc: screen-crop-*
* H265 and H265 Alpha support in vtdec and vtenc (VideoToolbox)
* ProRes support in vtenc
* New properties on vtenc elements: rate-control, data-rate-limits,
max-frame-delay
* New plugin atenc (AudioToolbox) with support for encoding AAC
* Plugin move: atdec moved from -bad to -good
* New property on osxaudio elements: unique-id
* OS X -> macOS
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8120>
If a new fragment is added with a valid duration but no offset then the start
offset is set later based on the end offset of the previous fragment. At that
point the end offset of this fragment can also be calculated and not doing so
would give the next fragment the same start offset.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8069>
Allow sample rate, number of channels and bps to change and in that case update
the caps accordingly.
Also move (non-fatal) validity checks and storing of the header values outside
the actual parsing once we actually know that a valid frame is available.
And also don't warn on the last frame with fixed block size blocking strategy
that the block size has changed: the last frame is allowed to be smaller.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3281
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8075>
While this specific case is also caught when initializing co_chunk, the error
is ignored in various places and calling into the function would lead to out of
bounds reads if the error message doesn't cause the pipeline to be shut down
fast enough.
To avoid this, no matter what, make sure enough offsets are available when
parsing them. While this is potentially slower, the same is already done in the
non-chunks_are_samples case.
Thanks to Antonio Morales for finding and reporting the issue.
Fixes GHSL-2024-245
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3847
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8059>
The level in GstAudioLevelMeta is represented as a signed 8bit value from 0 to
127 (with 127 meaning silence). When converting from double, make sure to clip
the value, this also prevent integer overflow in the conversion. This fixes an
issue where a lower then -127db is reported and random level with near silent
streams (due to integer overflow).
Fixes#4068
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8012>
Most importantly, this ensures that UDP streams still continue to run even if
they are not linked for a while. With decodebin3 the pads will all be unlinked
unless selected, and selecting a stream at a later time would otherwise switch
to a stream with a stopped udpsrc.
Apart from that this also ensures that actual errors from handling RTP packets
between udpsrc and the source pads are not silently ignored but considered
errors like they would be for TCP/interleaved.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7946>
This fixes a possible deadlock between gst_v4l2_video_dec_change_state
and gst_v4l2_video_dec_loop on the buffer pool.
When stopping capture, the flushing state of the v4l2 capture buffer
pool gets reverted in the processing loop after it was set via
gst_v4l2_object_unlock (self->v4l2capture) (in
gst_v4l2_video_dec_change_state). As a result, gst_v4l2_video_dec_loop
does not return and consequently, gst_pad_stop_task gets stuck waiting
for the GST_PAD_STREAM_LOCK. To circumvent this, skip acquiring the
buffer pool if stopping capture.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7958>
Scenario is that there are two (or more) GstGLContext's wrapping Qt's GL
context from either multiple qml(6)glsink or qml(6)glsrc elements. Call flow is this:
1. material 1 setBuffer()
2. material 1 bind()
3. material 2 setBuffer()
4. material 2 bind()
If the call to setBuffer() reuses the same buffer as previous call, then the
qt context is not updated in the material. If however the previously used qt
context by the material had been deactivated or freed, then bind() would fail
and could result in a critical like so:
gst_gl_context_thread_add: assertion 'context->priv->active_thread == g_thread_self ()' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7970>
A pipeline always has an async bus, which involves allocating an fd pair. As
splitmuxsrc only uses the bus' sync handler, this is not required and can easily
cause splitmuxsrc to exceed the fd limit for no good reason.
The other features of GstPipeline are also not needed here, e.g. clock selection.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7952>
Some streams in the wild have empty segments at the beginning and
hlsdemux2 use to stall forever while we can handle it by processing
the following ones. The gap handling mechanism in adaptivedemux2
works properly and pushes the required gaps.
Update validate medias so the hls stream is present.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6034>
We had a problem with negotiation of the framerate.
Gstreamer was querying the FRAMEINTERVALS based on the max frame size
instead of the desired frame size.
This was resulting in non-negotiated errors when trying to run with a
smaller frame size and fps higher than the max for the max image size.
Fx the max framerate for 1024x1024 RGB on CMOSIS4000 is 28.292
While for 1024x100 RGB it is 280.867
But Gstreamer would allow any framerates bigger than 28.292 no matter
the frame size used...
I have fixed it by 1st changing the CAPS query to use the minimum frame
size instead of maximum.
This however has the downside of allowing gstreamer to negotiate
framerates that are too high if the image size is bigger than the
minimum.
This is not a huge problem since our driver just CLAMPS the fps value to
the max then.
However gstreamer was not being properly notified of this change, and
would therefore report a wrong fps in the CAPS structure.
Note that the fps would be correct inside the buffer info.
Since gstreamer was reading the fps back after setting it.
It was just not being "propagated" to the CAPS structure.
I have also added a WARNING to this point so we can see if the fps that
gstreamer tries to apply was accepted or not.
And the next part of the fix was to add a framerate check after the
frame size has been established.
I did this inside the fixate_caps function of the v4l2src, which was
calling the TRY_FMT in order to check if the format was correct.
So I just added a check for the ENUM_FRAMEINTERVALS in there.
And now we get the non-negotiated again if the fps is too high for the
selected frame size.
Also added a couple of warnings so it is easy to see that this was the
cause.
See:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3037
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7850>
But also don't wait for a buffer on both pads, which might take forever in case
of gaps in one of the streams.
The muxer can only advance the time if it has a timestamped buffer that can be
output, otherwise it will just busy-wait and use up a lot of CPU.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7871>
Some special videos with mlv fourcc can't be recognized by
qtdemux when the subtype of the video is vide instead of
m1v, and will cause negotiation error in subsequent plugin.
So make the handle in qtdemux_video_caps. It might be better
than nothing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7855>
There is no point in having an endian marker on 8 bit bayer format names since
it is just one byte. Thus remove it.
This also fixes an incompatibility with plugins bad where there is no endian
marker on 8 bit bayer format names as well.
Fixes: #3729
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7826>
