When the image is opaque but the output ProRes format has an alpha
component (4 component, 32 bits per pixel), Apple requires that we
signal that it should be ignored by setting the depth to 24 bits per
pixel. Not doing so causes the encoded files to fail validation.

So we set that in the caps and qtmux sets the depth value in the
container, which will be read by demuxers so that decoders can skip
those bytes entirely. qtdemux does this, but vtdec does not use this
information at present.

The sister change was made in qtmux and qtdemux in:
gstreamer/gst-plugins-good!1061

Part-of: <gstreamer/gstreamer!1489>

Standard interlace handling:
* If we have interlace-mode=interleaved and the field order, we just
  set it when creating the session
* If we have interlace-mode=(interleaved|mixed) and no field order, we
  set the field order on the first buffer

The encoder session does not support changing the FieldDetail after it
has started encoding frames, so we cannot support mixed streams
correctly.

Part-of: <gstreamer/gstreamer!1214>

This PropertyKey is not documented in any headers anywhere, so we need
to define it ourselves.

Part-of: <gstreamer/gstreamer!1214>

It looks like VideoToolbox doesn't support all our colorimetries.

Part-of: <gstreamer/gstreamer!1214>

For vtdec, we continue to prefer NV12; else we pick whatever
downstream wants. In the special case where we're decoding 10-bit or
12-bit ProRes formats, we will prefer AYUV64.

Part-of: <gstreamer/gstreamer!1214>

Otherwise it is quite difficult to figure out why the chain function
failed. Also assert not reached for case statements that should not be
hit.

Part-of: <gstreamer/gstreamer!1214>

We never advertise these formats, so these cases will never be hit.

Part-of: <gstreamer/gstreamer!1214>

Vivia Nikolaidou authored Aug 16, 2021 and GStreamer Marge Bot committed Oct 29, 2021

Theoretically the version number is incremented every time there's a new
section, but in a world of streaming we can't easily make that
assumption.

An example of a broken use case is when we're cat-ing two mpeg-ts files
together, which is equivalent of capturing a DVB stream while switching
channels. A set-top box would know that we switched the channels and
reset the demuxer, but in practice this might not happen.

Part-of: <!2555>

Stéphane Cerveau authored Feb 25, 2021 and Tim-Philipp Müller committed Oct 29, 2021

Support new API in 1.1.1
Update the supported input video format.
Update tests to use parse_launch

Part-of: <!2554>

Trying to reset before the pads have been deactivated races with the
streaming thread. There was also a buggy buffer clear leaving a dangling
`stored_frame` pointer around. Use `gst_interlace_reset` so this happens
properly.

Part-of: <!2553>

Mathieu Duponchelle authored Sep 08, 2021 and Tim-Philipp Müller committed Sep 08, 2021

hotdoc doesn't know about that symbol

Part-of: <!2518>

Thibault Saunier authored Mar 31, 2021 and Tim-Philipp Müller committed Sep 06, 2021

We can reset the URI to NULL and this fix a deadlock in that case or
when the URI was invalid.

Part-of: <!2512>

Edward Hervey authored Jun 03, 2021 and Tim-Philipp Müller committed Sep 06, 2021

This avoids sending out partial invalid data downstream which could cause
decoders (ex: `dvdlpmdec`) to error out.

Part-of: <!2511>

Jan Schmidt authored Aug 30, 2021 and Tim-Philipp Müller committed Sep 06, 2021

Having an unlimited input queue is very bad if the
encoder can't run at real-time. Eventually it will
consume all RAM. I don't really see any reason to
have more than 1 outstanding encoded frame, so
remove the queue and limit things to 1 pending frame.

Part-of: <!2510>

Seungha Yang authored Sep 02, 2021 and Tim-Philipp Müller committed Sep 02, 2021

The minimum possible size of valid CEA708 data is 3 bytes, not 7 bytes

Part-of: <!2507>

Mathieu Duponchelle authored Aug 05, 2021 and Tim-Philipp Müller committed Aug 30, 2021

Previously, the code was always assuming progressive input,
fix this by looking at the caps.

Part-of: <!2500>

This encoder advertises alignment=au as output format, which means
each output frame should contain a full decodable access unit.

The video encoder base class is not aware of our output alignment
and will output spurious buffers with just the SPS/PPS inside when
we call gst_video_encoder_set_headers(), which is broken because
each buffer is supposed to contain a full decodable access unit
in our case.

Just don't tell the base class about our headers, they will be
sent at the beginning of each IDR frame anyway.

Part-of: <!2478>

Part-of: <!2478>

This was putting a truncated SPS into the initial header instead
of the PPS because it was always reading from the beginning of the
bitstream buffer (pBsBuf) and not from the offset where the current
NAL is at in the bitstream buffer (psBsBuf + nal_offset).

This was broken in commit 17113695.

Fixes #1576

Part-of: <!2478>

Edward Hervey authored Aug 20, 2021 and Edward Hervey committed Aug 23, 2021

Part-of: <!2479>

Seungha Yang authored Aug 19, 2021 and Tim-Philipp Müller committed Aug 20, 2021

Negative stride value can be used in MediaFoundation to inform
whether memory layout is top-down or bottom-up manner. Note that
negative stride is allowed only for RGB, system memory.

See also
https://docs.microsoft.com/en-us/windows/win32/medfound/image-stride

Fixes: #1646
Part-of: <!2477>

Nicolas Dufresne authored Aug 18, 2021 and Tim-Philipp Müller committed Aug 18, 2021

The emulation bytes need to be removed as bytes, not bit. This fixes
decoding issues with files that have emulation bytes with the Cedrus
driver.

Part-of: <!2472>

He Junyan authored Aug 04, 2021 and Tim-Philipp Müller committed Aug 09, 2021

The GST_ELEMENT_ERROR will call the gst_object_get_path_string and
use gst_object_get_parent to get the full object path name, which
needs to lock the object. But we are already in a locked context and
so this will cause a deadlock, the pipeline can not exit normally.

Part-of: <!2460>

pipewiresrc outputs audio buffers without a valid duration, so we need
to calculate it manually in that case.

Upstream issue: pipewire/pipewire#1438

Part-of: <!2444>

Matthew Waters authored Jul 13, 2021 and Tim-Philipp Müller committed Jul 16, 2021

https://gitlab.gnome.org/GNOME/glib/-/issues/803

Basically, if destruction of a GSource and its associated GMainContext are
not synchronised, Then the GSource destruction can access freed
GMainContext resources and cause a crash.  This is not super common but
can happen.

Part-of: <!2416>

Follow-up from:
!2392

Part-of: <!2395>

Philippe Normand authored Jul 08, 2021 and GStreamer Marge Bot committed Jul 08, 2021

GstDashDemuxStream is not a GstObject, so use its pad as associated object when
emitting log messages.

Part-of: <!2392>

Seungha Yang authored Jul 08, 2021 and Tim-Philipp Müller committed Jul 08, 2021

Given caps does not need to be strictly subset of device caps.
Allow accept it if device caps and requested caps can intersect

Fixes: #1619
Part-of: <!2391>

Matthew Waters authored Jul 02, 2021 and GStreamer Marge Bot committed Jul 08, 2021

We can only convert from non-cdp to cdp within the confines of valid cdp
framerates.  The existing caps negotiation code was allowing any
framerate to convert to a cdp output which is incorrect and would hit an
assertion later.

Part-of: <!2388>

Edward Hervey authored Jun 21, 2021 and GStreamer Marge Bot committed Jul 08, 2021

Not having any *actual* ANC is totally fine and common usage with several MXF
variants.

In order to properly advance the streams, the essence handler returns an empty
GAP buffer which gets converted to a GST_EVENT_GAP.

Part-of: <!2387>

Youngsoo Lee authored Jun 30, 2021 and Tim-Philipp Müller committed Jul 08, 2021

The build fails on macos with the following error:
/usr/local/Cellar/opencv/4.5.0_5/include/opencv4/opencv2/core/mat.hpp:2226:15: error: no template named 'initializer_list' in namespace 'std'
      Mat_(std::initializer_list<_Tp> values);
fatal error: too many errors emitted, stopping now [-ferror-limit=]
 35 warnings and 20 errors generated.

Part-of: <!2386>

Sebastian Dröge authored Jun 10, 2021 and Tim-Philipp Müller committed Jun 24, 2021

Some elements will make use of the automatically generated names to
create new pads in future muxer instances, for example splitmuxsink.

Previously we would've created a pad with a random pid that would become
"sink_0", and then on a new muxer instance a pad "sink_0" and tsmux
would've then failed because 0 is not a valid PID.

Part-of: <gstreamer/gst-plugins-bad!2358>

Sebastian Dröge authored Jun 10, 2021 and Tim-Philipp Müller committed Jun 24, 2021

Previously pads might have been requested already (e.g. in NULL state),
then reset was called (e.g. because changing state) and then a new pad
was requested. Resetting is re-creating the internal muxer object and as
such resetting the pid counter, so the next requested pad would get the
same pid as the first requested pad which then leads to collisions.

Part-of: <gstreamer/gst-plugins-bad!2357>

Seungha Yang authored Jun 17, 2021 and Tim-Philipp Müller committed Jun 22, 2021

Some decoder implementations might drain out internal buffers and
reset its status on segment-done event. So, in case that
upstream stream-format is packetized but downstream supports only
byte-format, required codec-data might not be forwarded toward
downstream if such parameter set NAL units don't exist in inband
bitstream. Therefore, parse elements should re-send parameter set NAL
units like the case of flush event.

Part-of: <gstreamer/gst-plugins-bad!2351>

He Junyan authored Jun 15, 2021 and Tim-Philipp Müller committed Jun 22, 2021

The GST_H265_PROFILE_MAIN_444_10 profile should be compatible with
GST_H265_PROFILE_SCREEN_EXTENDED_MAIN_444_10, not the current
GST_H265_PROFILE_SCREEN_EXTENDED_MAIN_10.

Part-of: <gstreamer/gst-plugins-bad!2350>

Nicolas Dufresne authored Jun 02, 2021 and Tim-Philipp Müller committed Jun 02, 2021

We were doing our initial "empty" commit on the subsurface instead of the
toplevel surface. As an incidence, we should not have received a configure
event ever, not just on mutter. This fixes the following warning when using
mutter compositor (aka gnome-shell):

  waylandsink wlwindow.c:304:gst_wl_window_new_toplevel: The compositor did not send configure event.

Part-of: <gstreamer/gst-plugins-bad!2300>

Seungha Yang authored May 25, 2021 and Tim-Philipp Müller committed Jun 01, 2021

That would cause negotiation issue

Part-of: <gstreamer/gst-plugins-bad!2293>

Seungha Yang authored May 25, 2021 and Tim-Philipp Müller committed Jun 01, 2021

Query caps should return caps which represent the element can accept,
not resulting format.

Fixing negotiation error with
gst-launch-1.0 videotestsrc ! video/x-raw,framerate=25/1 ! interlace field-pattern=0 ! fakesink

Part-of: <gstreamer/gst-plugins-bad!2293>