GitLab

Set MARKER flag on first buffer after DTX.

According to RFC 3551 section 4.1 the marker bit needs to be set on
"the first packet after a silence period during which packets have
not been transmitted contiguously".

Part-of: <gstreamer/gst-plugins-good!967>

If enabled, the payloader won't transmit empty frames.

Can be tested using:
  opusenc dtx=true bitrate-type=vbr ! rtpopuspay dtx=true

Part-of: <gstreamer/gst-plugins-good!967>

ID3v2::FrameFactory::createFrame() versions not taking a Header have
been deprecated since v1.5 (Jan 2008).

Part-of: <gstreamer/gst-plugins-good!965>

The estimated packet-duration can sometimes end up as zero, and dividing
by that is never a good idea...

The test reproduces the scenario, and the fix is easy.

Part-of: <gstreamer/gst-plugins-good!966>

* Try to make variable and function names more clear.
* Add plenty of comments describing the logic step-by-step.
* Improve the logging around this, making the logs easier to read and
  understand when debugging these issues.

* Revise the logic of packets that are actually beyond saving in doing
  the following:
1. Do an optimistic estimation of which packets can still arrive.
2. Based on this, find which packets (and duration) are now hopelessly
   lost.
3. Issue an immediate lost-event for the hopelessly lost and then add
   lost/rtx timers for the ones we still hope to save, meaning that if
   they are to arrive, they will not be discarded.

* Revise the use of rtx-delay:
  Earlier the rtx-delay would vary, depending on the pts of the latest
  packet and the estimated pts of the packet it being issued a RTX for,
  but now that we aim to estimate the PTS of the missing packet accurately,
  the RTX delay should remain the same for all packets.
  Meaning: If the packet have a PTS of X, the delay in asked for a RTX
  for this packet is always a constant X + delay, not a variable one.

* Finally ensure that the chaotic "check-for-stall" tests uses timestamps
  that starts from 0 to make them easier to debug.

Part-of: <gstreamer/gst-plugins-good!952>

Part-of: <!962>

Ensure we receive a writable buffer to add the meta.

Fix #878

Part-of: <gstreamer/gst-plugins-good!962>

Part-of: <gstreamer/gst-plugins-good!964>

When updating timestamps and timer timeouts with a new offset, make sure that
the resulting value is valid (and not a negative (signed) value which ends up in
a massive (unsigned) value).

Fixes #571

Part-of: <gstreamer/gst-plugins-good!960>

The v4l2object is not a GstObject. Logging has to go through its dbg_obj
specially meant for this.

Part-of: <gstreamer/gst-plugins-good!959>

GstGLVideoItem is required to render input video in the overlay's qml.
And currently qmlgloverlay requires to set this GstGLVideoItem to its widget property.

Instead of fetching GstGLVideoItem from the overlay's root object (root-item prop),
and setting it back as a widget (widget prop),
proposing to use found GstGLVideoItem in the current object hierarchy (passed in qml-scene) by default.

Also useful in Python, which solves the issue when casting gpointer <=> QQuickItem* is required.

Part-of: <gstreamer/gst-plugins-good!919>

Would spew warnings on the rpi4 when calling into
gst_v4l2_object_get_codec_caps() from the probe_and_register()
function since the v4l2_debug category initialisation would
only be done later as part of the element/device provider
registration.

Also log things in the probe function to the v4l2 category
instead of the default category while we're at it.

Part-of: <gstreamer/gst-plugins-good!956>

We need to save the seek seqnum before the flush stop event
since that will start the basesrc task which may send the segment
event before we're ready.

Part-of: <gstreamer/gst-plugins-good!954>

Add the forceAspectRatio Q_PROPERTY to allow changing the aspect ratio
from QML code as well.

Part-of: <gstreamer/gst-plugins-good!937>

They're harmless, and some drivers at least return EINVAL
instead of ENOTTY for unsupported events (here: uvcvideo).

Part-of: <gstreamer/gst-plugins-good!955>

Part-of: <gstreamer/gst-plugins-good!950>

Part-of: <!949>

stop is not used after this point, nor do we create a new segment
here since 84725d62

Part-of: <gstreamer/gst-plugins-good!940>

This breaks the duration query and also the seeking query.

Broke in 5f1a732b

Part-of: <gstreamer/gst-plugins-good!940>

Assignments copy by value, we don't need to memcpy...

Part-of: <gstreamer/gst-plugins-good!940>

It might've been set to FLUSHING between the last check and the waiting,
and in that case we'd be waiting here forever now.

Part-of: <gstreamer/gst-plugins-good!944>

Part-of: <gstreamer/gst-plugins-good!942>

Part-of: <gstreamer/gst-plugins-good!942>

Part-of: <gstreamer/gst-plugins-good!942>

Part-of: <gstreamer/gst-plugins-good!943>

If the input DTS goes backward or is missing, the calculated
sample duration goes negative and wraps around to a very big
number. In that case, just write a sample with a duration of
0 and hope the problem is transient.

Part-of: <gstreamer/gst-plugins-good!914>

Seek events are sent upstream on each sink, so if we receive multiple
seeks with the same seqnum, we must only perform one seek, not N seeks
where N = the number of sinks in the pipeline connected to rtspsrc.

This is the same thing done by demuxers like qtdemux or matrsokademux.

Part-of: <gstreamer/gst-plugins-good!938>

The transport has no relation to whether a media can be seeked. The
range response having a duration is the correct thing to check for.

Part-of: <gstreamer/gst-plugins-good!939>

Part-of: <gstreamer/gst-plugins-good!939>

Part-of: <gstreamer/gst-plugins-good!515>

Part-of: <gstreamer/gst-plugins-good!515>

- Added support for planar pixel formats with depths greater than 8bits
  to transform_planar implementation
- Added a whole lot of new pixel formats to the support-list

Part-of: <gstreamer/gst-plugins-good!515>

- Moved declaration of supported pixel formats to private header, which
  can be shared between videocrop and aspectvideocrop

Part-of: <gstreamer/gst-plugins-good!515>

This code can be fragile, since it is very exacting in the timestamps
that it will accept. Add more logging so it's easier to debug issues
and figure out whether it's a bug in the calculation or something
wrong in the incoming buffers.

Part-of: <!934>

- h264depay
- h265depay
- sv3vdepay

Part-of: <gstreamer/gst-plugins-good!936>

gst_rtp_sbc_pay_flush_buffers() is a misleading name. A better name would
be gst_rtp_sbc_pay_drain_buffers(), because that's what it does, it drains
any leftover queued data and pushes it downstream. "Flushing" in GStreamer
typically means to throw away any queued data and not process/push it
downstream.
Signed-off-by: Michal Dzik <michal.dzik@streamunlimited.com>
Part-of: <gstreamer/gst-plugins-good!700>

GstAdapter must be flushed in some cases (flush, new segment, state change)
Without it, it may, for example, push some leftover buffer from old
segment in new segment. This, in general, breaks timestamps.
See GstAdapter documentation for more.
Signed-off-by: Michal Dzik <michal.dzik@streamunlimited.com>
Part-of: <gstreamer/gst-plugins-good!700>

Part-of: <gstreamer/gst-plugins-good!871>

Some streams have unknown colorimetry in caps, but v4l2object sets
default values for each primaries. It will cause check colorimetry
fail when do gst_v4l2_video_colorimetry_matches().

To fix this, need to keep the unknown colorimetry in caps same as
the default value set by v4l2object.

Part-of: <gstreamer/gst-plugins-good!923>

Otherwise, in the case of e.g. a deferred seek event, the segment stop
would be replaced with GST_CLOCK_TIME_NONE.

Part-of: <gstreamer/gst-plugins-good!929>