GitLab

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

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

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

If new headers arrive after we are initialized, we need to make
sure that they are indeed valid.

A vorbis bitstream always begins with three header packets and must
be in order.

Also some streams have unframed (invalid?) headers that might
confuse and disrupt the decoding process.

Therefore if ever we see new headers, we accumulate them and once
we get a non-header packet we check them to make sure that:
* We have at least 3 headers
* They are the expected ones (identification, comments and setup)
* They are in order
* Any other "header" is ignored

If those conditions are met, we reset and reconfigure the decoder

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

Buffering messages are only sent for the active group (in case there
is more than one).

If the inactive group posts buffering messages we keep the last one
around and will post it once it becomes the playing one.

After eos, decodebin3 enters a loop sending eos events which causes high cpu usage.

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

In order to flush out multiqueue, we send again a STREAM_START and
then a EOS event.

The problem was that was that we might end up pushing out on the
output of multiqueue (and therefore decodebin3) a series of:
* EOS / STREAM_START / EOS

Apart from the uglyness of such output, If decodebin3 is used with
elements such as concat on their output, they might potentially
block on that second STREAM_START.

In order to make sure we don't end up in that situation we send
a custom STREAM_START event when refreshing multiqueue (which we
drop on the output) and we don't special case EOS events on streams
on which we already got EOS.

At worst we now end up sending at most two EOS on the output of
multiqueue (and decodebin3).

Similar in vein to the playbin2 architecture except that uridecodebin3
are prerolled much earlier and all streams of the same type are
fed through a 'concat' element.

This keeps the philosphy of having all elements connected as soon
as possible.

The 'about-to-finish' signal is emitted whenever one of the uridecodebin
is about to finish, allowing the users to set the next uri/suburi.

The notion of a group being active has changed. It now means that the
uridecodebin3 has been activated, but doesn't mean it is the one
currently being outputted by the sinks (i.e. curr_group and next_group).
This is done via detecting GST_MESSAGE_STREAM_START emission by playsink
and figuring out which group is really playing.

When the current group changes, a new thread is started to deactivate
the previous one and optionnaly fire 'about-to-finish'.

Apologies for the big commit, but it wasn't really possible to split it
in anything smaller.

* Switch to uridecodebin3 instead of managing urisourcebin and decodebin3
ourselves. No major architectural change with this.

* Reconfigure sinks/outputs when needed. This is possible thanks to the
various streams-related API. Instead of blocking new pads and waiting
for a (fake) no-more-pads to decide what to connect, we instead reconfigure
playsink and the combiners to whatever types are currently selected. All of
this is done in reconfigure_output().
  New pads are immediately connected to (combiners and) sinks, allowing
immediate negotiation and usage.

* Since elements are always connected, the "cached-duration" feature is gone
and queries can reach the target elements.

* The auto-plugging related code is currently disabled entirely until
we get the new proper API.

* Store collections at the GstSourceGroup level and not globally

* And more comments a bit everywhere

NOTE: gapless is still not functional, but this opens the way to be able
to handle it in a streams-aware fashion (where several uridecodebin3 can
be active at the same time).

With push-based sources, urisourcebin will emit this signal when
the stream has been fully consumed.

This signal can be used to know when the source is done providing
data.

In the same vein as old uridecodebin except that it also
accepts a suburi and uses urisourcebin and decodebin3 internally

Those properties doesn't exist on playbin3, don't emit a notify for that

That property doesn't exist

Upstream might respond negatively to the event, whereas we actually
handled it.

We only need to take the input lock when adding/removing
inputs from the list.

The lock is never used

They were never used and we need a better system

It is not needed in the new streams-aware world

It was never used and makes no sense in the new streams-based world

The signals were never emitted from decodebin3. This needs
switching to a new signalling system

That signal is never emitted by decodebin3 and is handled differently

This is now handled directly via sinks and queries through pads

There's no reason to do async changing

Even if the input is monoscopic, the app might want to display
it in a different layout, to do side-by-side for VR for example,
so if the app changes the output-multiview-mode always use that.

Pass data with no caps and no streamheaders without
throwing a bunch of criticals

We can either receive an element that is floating or not and need to
accomodate that in the signal return values.  Do so by removing the
floating flag.

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

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

WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.

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

When the GstRTSPConnection class sends a RTSP over HTTP tunnelling
request, the HTTP Content-Type header is missing from the HTTP POST
request.

This isn't a problem with most servers, but there are servers that
rejects the request without there also being a Content-Type header.

RFC 1945:
Any HTTP/1.0 message containing an entity body should include a
Content-Type header field defining the media type of that body.

Apple Dispatch 28:
QuickTime Streaming uses the "application/x-rtsp-tunnelled" MIME
type in both the Content-Type and Accept headers. This reflects
the data type that is expected and delivered by the client and server.

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

Additions on top of

https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=32a17f313494cbadaf8ec4e337d742e8d7e1b67b
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=c8b99139b1ef3f8891548b0f2607a135917c338e

We don't really want type=NONE as input and it was already impossible
for that to occur with the other condtions.

CID #1427144