boolean return value is not sufficient for representing the reason
of error in most cases. For instance, any errors around new_sequence()
would mean negotiation error, not just *ERROR*.
And some subclasses will allocate buffer/memory/surface on new_picture()
but it could be failed because of expected error, likely flushing
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1019>
boolean return value is not sufficient for representing the reason
of error in most cases. For instance, any errors around new_sequence()
would mean negotiation error, not just *ERROR*.
And some subclasses will allocate buffer/memory/surface on new_picture()
but it could be failed because of expected error, likely flushing
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1019>
boolean return value is not sufficient for representing the reason
of error in most cases. For instance, any errors around new_sequence()
would mean negotiation error, not just *ERROR*.
And some subclasses will allocate buffer/memory/surface on new_picture()
but it could be failed because of expected error, likely flushing
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1019>
warning C4003: not enough arguments for function-like macro invocation 'warning'
G_STMT_END macro is extended to the below form with MSVC
__pragma(warning(push)) \
__pragma(warning(disable:4127)) \
while(0) \
__pragma(warning(pop))
So MSVC preprocessor will extend it further to
__pragma(VBI_CAT_LEVEL_LOG(push)) ...
Should rename warning() debug macro function therefore.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1018>
libgudev is a problematic dependency, particularly in sandboxed
environments, such as flatpak.
This patch implements a way to get the available VA devices using
brute-forced traverse of /dev/drm/renderD* directory. Thus usable in
those sandboxed environments.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1027>
When move the libgstva, libgudev dependency was moved as part of the
library, though it's not use by the library but the plugin. This patch
moves back libgudev dependency to the plugin.
Also HAVE_LIBDRM is move to the library which is the one who use it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1027>
Some decoding APIs support delayed output for performance reasons.
One example would be to request decoding for multiple frames and
then query for the oldest frame in the output queue.
This also increases throughput for transcoding and improves seek
performance when supported by the underlying backend.
Introduce support in the vp9 base class, so that backends that
support render delays can actually implement it.
Co-authored by Seungha Yang <seungha@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/987>
This patch contains two updates:
1. Instead of checking for dependency already checked just to verify a
version, we use the dependency version API.
2. Update the deprecated function get_pkgconfig_variable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/997>
It's possible to have installed MediaSDK environment
package (libmfx-dev in Debian) without libva environment package. This
setup will lead to a breakage of meson configuration.
The fix is to get the libva's driver directory variable after the
dependency is validated as found.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/998>
When using the following setup (the error can be reproduced using
simpler sender pipelines), the receiver resynchronises the clock on RTCP
packets. The effect was that a couple seconds were cut out of the
playback because an initial RTCP packet was dropped.
When sending out all RTCP packets (setting sync=FALSE on the RTCP
updsink), the playback is fine.
This syncs rtpsink with rtpsrc (where this property was already set).
gst-launch-1.0 filesrc location=899-en.mp3 \
! mpegaudioparse \
! mpg123audiodec \
! audioconvert \
! audioresample \
! avenc_g722 \
! rtpg722pay
! rtpsink uri=rtp://239.1.2.3:1234
gst-launch-1.0 uridecodebin rtp://239.1.2.3:1234?encoding-name=G722 \
! autoaudiosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/993>
When there are elements between the demuxer and the muxer that
introduce an offset to the running time, or when offsets are
set on pads by the application, this shift must be taken into
account when calculating the final pts_adjustement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>
mpegtsmux can receive SCTE sections from two origins: events
created by the application, and events forwarded downstream by
mpegtsdemux, containing sections that may not have been fully
parsed, and additional data to help tsmux translate times to
the correct domain, both for requesting keyframes and calculating
an accurate pts_adjustment.
The complete approach is documented further in a comment above
the relevant function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>
Instead of modifying the splice times in the incoming sections
to running time and expecting eg mpegtsmux to convert those back
to its local PES time domain, which might be impossible when
those splice times are encrypted or the specification is extended,
transmit the needed information to the muxer as separate fields in
the event:
* A pts offset field can be used by the muxer in order to calculate
a final pts_adjustment
* A rtime_map can be used by the muxer to determine the correct
running times at which it should request keyframes
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>
Makes it possible to support passing SCTE 35 cue points from
demuxer to muxer, while preserving correct timing.
This will also improve ex nihilo cue points injection, as splice
times and durations are now interpreted as running time values,
and may trigger key unit requests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>