This allow simplifying the GstVideoInfo handling in the sinks. Instead
of having to update a video info for the import, the sink can simply pass the
video info associated with the caps and rely on the VideoMeta in the GstBuffer
to obtain the appropriate offset and stride.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
As we don't render into the widget directly, there is no "initial" draw
happening. As a side effect, the internal aspect ratio adapted display
width/height is never initialize leading to assertions when handling navigation
events.
gst_video_center_rect: assertion 'src->h != 0' failed
Simply queue a redraw after setting the widget format in order to fix the issue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
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>
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>
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>
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>
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>
The encoder does not support reconfiguration, and only deinitializing it
and then initializing it again causes deadlocks.
Also only reconfigure and drain the encoder if the video info has
actually changed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3957>
And also keep the default encoder settings but simply override them with
our own values that we care about.
This mirrors the encoder configuration behaviour from ffmpeg.
Add AVTP Raw Video Format de-payload support. The element supports only
GRAY16_LE output format, so:
- active pixels (no vertical blanking),
- progressive mode,
- 8 and 16-bit pixel depth,
- mono pixel format,
- grayscale colorspace.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1335>
Add AVTP Raw Video Format payload support. The element supports only GRAY16_LE
input format, so:
- active pixels (no vertical blanking),
- progressive mode,
- 8 and 16-bit pixel depth,
- mono pixel format,
- grayscale colorspace.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1335>
There is no byte-stream/au format for AV1 but only for H264, and the
encoder actually outputs obu-stream/tu instead of the annexb
stream-format that is similar to H264 byte-stream format.
Without this the encoder can't be used with elements that require a
specific AV1 stream-format, e.g. the MP4 or Matroska/WebM muxer.
This allows handling input buffers with non-default strides, which was
already handled fine by the element code.
Without this, potentially expensive conversion was needed.
The private data is not copied over for SVT AV1 encoder so this code
path would've never worked.
Instead of relying on the PTS, which is not required to be unique or
existing at all, we always take the oldest frame as AV1 has no frame
reordering / B frames.
