GitLab

Erroneous value made "TUNE" overwrite "TUNNING_FAIL" ....

When retrieving the `mxfdemux.structure` property, it leads to an
assertion as metadatas need to be resolved for the call to
mxf_metadata_base_to_structure to be valid.

We have to pass the "height" as height = vmeta->offset[1] / width to the
API, which of course does not work well for formats with only a single
plane. Use the whole memory size instead of the offset in that case.

Previous commit let demux call gst_uri_downloader_cancel() on _demux_reset().
Note that, _demux_reset() called during PAUSED_TO_READY and READY_TO_PAUSED.
And, it will set "cancelled" on uridownloader which blocks the use of
uridownloader. The issue is that, subclass can use the uridownloader not only
live streaming for manifest update, but also for fetching another manifests
such as variant and rendition m3u8 of hls streaming. So to unblock it,
demux should clear "cancelled" before processing initial manifest.

https://bugzilla.gnome.org/show_bug.cgi?id=783401

before broadcasting preroll.

The deadlock was as follows:

-> The subclass pushes a buffer on a newly-created stream in T1
-> We take the preroll lock in T1, to handle_preroll
-> The demuxer is stopped in T2, we take the MANIFEST_LOCK
-> T1 starts blocking because it received a reconfigure event
   and needs to take the MANIFEST_LOCK
-> T2 deadlocks because it now wants the preroll_lock.

https://bugzilla.gnome.org/show_bug.cgi?id=783255

Make sure the manifest update loop is stopped before proceeding with the
resetting of the manifest data. Otherwise, the updates loop will try to
use it and it leads to a segfault

https://bugzilla.gnome.org/show_bug.cgi?id=783028

https://bugzilla.gnome.org/show_bug.cgi?id=783028

As we release the MANIFEST_LOCK in stop_tasks,
demux->priv->old_streams can be set, we need to free these
otherwise we may end up trying to dispose elements in the
READY state.

https://bugzilla.gnome.org/show_bug.cgi?id=783256

This is wrong because:
* If the rate is negative we should check for the *previous* period
* adaptivedemux already does the proper checks before calling this
  method

GstSegment position is a guint64 and not a gint64

CID #1409910

The live seeking range was only checked when doing actual seeks. This was
assuming that the rate would always be 1.0 (i.e. the playback would
advance in realtime, and therefore fragments would always be available
since the seeking window moves at the same rate).

With non-1.0 rates, this no longer becomes valid, and therefore we need
to check whether we are still within the live seeking range when advancing.

https://bugzilla.gnome.org/show_bug.cgi?id=783075

If a manifest has non-zero presentation time offset
(i.e., earliest presentation time specified by sidx box is not zero),
the initial sidx position shouldn't be zero. Since we cannot define
exact sidx position until parsing sidx box, set the value to unknown.

https://bugzilla.gnome.org/show_bug.cgi?id=782693

https://bugzilla.gnome.org/show_bug.cgi?id=783626

This can happen with real files

Set the pts and dts on the frame that we receive from the msdk.
Also fix the inverted logic in setting sync points, previously we
were marking all frames as sync points except IDRs.

https://bugzilla.gnome.org/show_bug.cgi?id=782801

Usage of GstValueArray was wrong and frame-stride does not exist in
rawvideoparse

Also swap the linktype after we detected that we need to do
byteswapping. Fixes a problem with reading pcap files generated
on a machine with different endianness.

GL_RGB565 is sized internal glformat, the corresponding glformat
should be GL_RGB and type is GL_UNSIGNED_SHORT_565. Otherwise will
return GL_INVALID_ENUM when creating texture.

https://bugzilla.gnome.org/show_bug.cgi?id=783066

tags could potentially be NULL

What we want is to retry downloading the fragment on 4xx/5xx errors
however returning EOS will cause waiting for a manifest update for live
(which may be a really long time) or stop everything for non-live.

Change that to only return EOS/ERROR once we've reached the error limit.

https://bugzilla.gnome.org/show_bug.cgi?id=776609

With the macOS/iOS implementations, the active thread can change
multiple times over the life of a pipeline which would expose a race in
the thread tracking.

Fix by taking a ref on the active thread while the context is active.

https://bugzilla.gnome.org/show_bug.cgi?id=779202

The latter is not used/available anymore since years. Also fix a typo
in the include path for the Cocoa GL display header.

https://bugzilla.gnome.org/show_bug.cgi?id=782771

https://bugzilla.gnome.org/show_bug.cgi?id=782736

The audio packet times can be completely unrelated to the video stream
time, depending on the card. While this looks like a bug in the driver,
just always using the video stream time (which is correct) works as a
workaround for now.

It's needed by e.g. qmlglsink.

https://bugzilla.gnome.org/show_bug.cgi?id=782921

Instead of just bpp * width, which might be more than we can copy.

If upstream supports both, but downstream supports only jpc, j2c
would have been selected as the first in the caps.

https://bugzilla.gnome.org/show_bug.cgi?id=782221

The main advantage is that our sleeps can be interrupted in case of
an src_reset(). Earlier, we would need to wait for a read to complete
before we could do a reset, which could take a long time.

https://bugzilla.gnome.org/show_bug.cgi?id=781249

Otherwise fall back to glDrawBuffers. Also check if glReadBuffer exists
before using it.

glDrawBuffer does not exist for GLES, only glDrawBuffers does.

https://bugzilla.gnome.org/show_bug.cgi?id=782376