There could be a case where the new program has the same program number as the
previous one ... but is actually located on a PID previously used for elementary
stream. In that case the program is guaranteed to not be an update of the
previous program but a completely new one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1919>
We need to be able to look for programs by their PID also. Using a hash table
was a bit sub-par (and overkill) for storing a range of programs.
This is needed because there could potentially be two programs with the same
program id but different PMT PID (while one is being deactivated the new one
would "exist").
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1919>
This patch fixes a seg.fault in gst_structure_new() with warnings as below.
GLib-GObject-WARNING **:
../gobject/gtype.c:4330: type id '0' is invalid
GLib-GObject-WARNING **:
can't peek value table for type '<invalid>' which is not currently referenced
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1920>
Fix a small race where a group can receive stream-start
and post a pending buffering message just as another
thread posts a different buffering message, causing them
to be received by the application out of order. In the
worst case, this leads the application receiving a
stale 99% buffering message and going back to buffering
right after the 100% buffering message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1901>
And use the output segment position for the outgoing timestamp while it
is. This is needed to delay the calculation of `output_ts_offset` until
we actually have a usable timestamp, as tsmux will output a few initial
packets while `last_ts` is still unset.
Without this, the calculation would use the initial `0` value, which did
not have the intended effect of making VBR mode behave like CBR mode,
but always calculated an offset equal to the selected start time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1895>
When doing only a single stream of audio/video this hardly matters,
but when doing many at the same time, the fact that you have to get
a hold of the glib global type-system lock every time you process a buffer,
means that there is a limit to how many streams you can process in
parallel.
Luckily the fix is very simple, by doing a cast rather than a full
type-check.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1890>
When tunneling over HTTP, if connection on the second channel happens
before the control timer is created we may trigger an assert in
rtsp_ctrl_timeout_remove(). Avoid that by taking the priv->lock before
attaching the client thread to the context.
Fixes#1025
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1870>
Not having this field is equivalent with it being 1/1 so consider
it like that. The generic caps functions are not aware of these
semantics and would consider the caps different, causing a negotiation
failure when caps are changing from caps with to caps without or the
other way around.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1833>
Not having these fields is equivalent with them being mono/0 so consider
them like that. The generic caps functions are not aware of these
semantics and would consider the caps different, causing a negotiation
failure when caps are changing from caps with to caps without or the
other way around.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1833>
Otherwise fetching of the offer will fail with a cryptic error:
```
Traceback (most recent call last):
File "/../gstreamer/subprojects/gst-examples/webrtc/sendrecv/gst/webrtc_sendrecv.py", line 56, in on_offer_created
offer = reply['offer']
TypeError: 'Structure' object is not subscriptable
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1832>
```
ERROR peer '5762' not found
Traceback (most recent call last):
File "/../gstreamer/subprojects/gst-examples/webrtc/sendrecv/gst/webrtc_sendrecv.py", line 190, in <module>
res = loop.run_until_complete(c.loop())
File "/usr/lib64/python3.10/asyncio/base_events.py", line 641, in run_until_complete
return future.result()
File "/../gstreamer/subprojects/gst-examples/webrtc/sendrecv/gst/webrtc_sendrecv.py", line 155, in loop
self.close_pipeline()
File "/../gstreamer/subprojects/gst-examples/webrtc/sendrecv/gst/webrtc_sendrecv.py", line 142, in close_pipeline
self.pipe.set_state(Gst.State.NULL)
AttributeError: 'NoneType' object has no attribute 'set_state'
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1832>
```
File "/../gstreamer/subprojects/gst-examples/webrtc/sendrecv/gst/webrtc_sendrecv.py", line 189, in <module>
loop.run_until_complete(c.connect())
File "/usr/lib64/python3.10/asyncio/base_events.py", line 641, in run_until_complete
return future.result()
File "/../gstreamer/subprojects/gst-examples/webrtc/sendrecv/gst/webrtc_sendrecv.py", line 40, in connect
self.conn = await websockets.connect(self.server, ssl=sslctx)
File "/home/nirbheek/.local/lib/python3.10/site-packages/websockets/legacy/client.py", line 650, in __await_impl_timeout__
return await asyncio.wait_for(self.__await_impl__(), self.open_timeout)
File "/usr/lib64/python3.10/asyncio/tasks.py", line 445, in wait_for
return fut.result()
File "/home/nirbheek/.local/lib/python3.10/site-packages/websockets/legacy/client.py", line 654, in __await_impl__
transport, protocol = await self._create_connection()
File "/usr/lib64/python3.10/asyncio/base_events.py", line 1080, in create_connection
transport, protocol = await self._create_connection_transport(
File "/usr/lib64/python3.10/asyncio/base_events.py", line 1110, in _create_connection_transport
await waiter
File "/usr/lib64/python3.10/asyncio/sslproto.py", line 631, in _on_handshake_complete
raise handshake_exc
File "/usr/lib64/python3.10/asyncio/sslproto.py", line 676, in _process_write_backlog
ssldata = self._sslpipe.do_handshake(
File "/usr/lib64/python3.10/asyncio/sslproto.py", line 116, in do_handshake
self._sslobj = self._context.wrap_bio(
File "/usr/lib64/python3.10/ssl.py", line 526, in wrap_bio
return self.sslobject_class._create(
File "/usr/lib64/python3.10/ssl.py", line 865, in _create
sslobj = context._wrap_bio(
ssl.SSLError: Cannot create a client socket with a PROTOCOL_TLS_SERVER context (_ssl.c:801)
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1832>
asyncio.get_event_loop() will not implicitly create a new event loop
in a future version of Python, so we need to do that explicitly.
```
webrtc_sendrecv.py:188: DeprecationWarning: There is no current event loop
loop = asyncio.get_event_loop()
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1832>
Remove the symbolic link `gst-uninstalled` which points to `gst-env`.
The `uninstalled` is the old name and the project should stick to a
single name for the procedure.
Remove the term from all the files, exceptions are variables from
dependencies like `uninstalled_variables` from pkgconfig and
`meson-uninstalled`.
Adjust mentions of the script in the documentation and README.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1829>
Do not maintain similar build instructions within each gst-plugins-*
subproject and the subproject/gstreamer subproject. Use the build
instructions from the mono-repository and link to them via hyperlink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1829>
The fd was in different meanings on windows:
POSIX read and write use the fd as a file descriptor.
The gst_poll use the fd as a WSASocket.
This patch use WSASocket as default on windows. This is a temporary measure, because IPC has many different implement. There may be a better way in the future.
See #1044
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1822>
LOAD macro relies in m7 being zero for interleaving purposes. Using LOAD
on the m7 register makes it interleave with its new content instead of
with 0.
The effect of this bug was bobbing on some static lines that appeared
over fast-moving content.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1823>
osxaudiodeviceprovider now probes devices more than once to determine
if the device can function as both an input AND and output device.
Previously, if the device provider detected that a device had any output
capabilities, it was treated solely as an Audio/Sink. This causes issues
that have both input and output capabilities (for example, USB interfaces
for professional audio have both input and output channels). Such devices
are now listed as both an Audio/Sink as well as an Audio/Source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1809>
The RTP payload seems to be required as it carries the frame count
information. Also, gst_rtp_base_payload_allocate_output_buffer had
the second argument incorrect.
Strangely some devices like Shanling MP4 and Sony XM3 would still
work without this while some like the Sony XM4 do not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1804>
If the video4linux device supports norms but has no norm set, norm is
returned as an uninitialized variable after the ioctl call, leading to
gst_v4l2_tuner_get_norm_by_std_id() returning a random norm from the
supported norms. Catch this case and instead return NULL to indicate
that no norm is setup.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1758>
The instant-rate value in the TrickMode enum is a
flag, but the other values are not. Move instant-rate
to the end of the enum and give it a value large enough
for it to be used without modifying the trick-mode
setting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1793>
Update x264enc long-name to be more than just the name. Then the
description also was updated to be longer than the long-name, and
similar to the plugin description.
Finally, as I am here, H264 was replaced by H.264 and x264 is only a
plugin (not plugins).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1781>
... instead of round(). Depending on framerate, calculated position
may not be clearly represented by using uint64, 30000/1001 for example.
Then the result of round() can be sliglhtly larger (1ns) than
buffer timestamp. And that will cause unnecessary frame delay.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1755>
It was assumed that the kernel parameters would match with the bitstream value
but instead the author when with another set of value. Surprisingly, this
makes no difference with the resulting fluster score.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1754>
If present, add '-lsocket' and '-lnsl' to network_deps.
ext/curl/meson.build: add network_deps to dependencies
gst/festival/meson.build: same
sys/shm/meson.build: same
Fixes linking issues on Illumos distros.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1736>
The libjpeg-turbo internal state might not be correctly initialized for
the first frame in a stream, pull the frame stride from gstreamer frame
metadata instead, which is correct even for the first frame, and which
makes this code consistent with the surrounding lines.
Fixes: e6d83d8f96 ("jpegdec: Support libjpeg-turbo colorspace conversion")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
It is imperative that the libjpeg-turbo state is properly initialized
before jpeg_start_decompress() is called. Make sure cinfo.out_color_space
and cinfo.raw_data_out are set to their final values matching their peer
caps before calling jpeg_start_decompress().
Fixes: e6d83d8f96 ("jpegdec: Support libjpeg-turbo colorspace conversion")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
Pull out peer caps checking code into gst_jpeg_turbo_parse_ext_fmt_convert().
This code is used by libjpeg-turbo extras to determine whether peer is capable
of handling buffers into which libjpeg-turbo can directly decode data. This
kind of check must be performed before jpeg_start_decompress() is called in
gst_jpeg_dec_prepare_decode() as well as in gst_jpeg_dec_negotiate(), hence
the common code.
This commit does modify the code a little to make it easier to call from both
call sites without much duplication, hence the extra `if (*clrspc)` test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
This reverts commit 2aa2477208.
The commit is completely wrong, libjpeg-turbo is perfectly capable
of decoding I420 (YUV) to RGB. The test case provided alongside the
aforementioned commit passes without this revert because it decodes
image of JCS_YCrCb color space, so the new `if (clrspc == JCS_RGB)`
condition is false on that image, and the libjpeg-turbo decoding
does not get used. The real bug is hidden by that commit.
The real problem is in the call order of gst_jpeg_dec_prepare_decode()
and gst_jpeg_dec_negotiate(). The gst_jpeg_dec_prepare_decode() calls
jpeg_start_decompress() which sets up internal state of the libjpeg,
however, neither cinfo.out_color_space nor cinfo.raw_data_out are
set correctly yet. Those two are set up in gst_jpeg_dec_negotiate()
which is called a bit later. Therefore, the real fix is the set up
cinfo.out_color_space and cinfo.raw_data_out before calling
jpeg_start_decompress(). This is however a separate patch.
Fixes: 2aa2477208 ("jpegdec: only allow conversions from RGB")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
The current manner for deciding the new temporal unit is based on
temporal delimiter(TD) OBU. We only start a new temporal unit when
the TD comes.
But some streams do not have TD at all, which makes the output "TU"
alignment fail to work. We now add check based on the relationship
between the different layers and it can successfully judge the TU edge.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1712>
Some streams may have problematic OBUs at the beginning, which causes
the parse fail to detect the alignment and return error. For example,
there may be verbose OBUs before a valid sequence, which should be
discarded until we meet a valid sequence. We should let the parse
continue when we meet such cases, rather than just return error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1712>
