GitLab

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

Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.

So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.

This slightly changes the behaviour of gst_audio_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.

If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.

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

It is faster than doing a query that propagates downstream and
should be enough

Removes the need for custom caps query handling and makes it more
correct from the beginning on the template. It is a bit uglier
to read because there is 1 entry per channel but makes code easier
to maintain.

It is faster than doing a query that propagates downstream and
should be enough

Allows subclasses to do their own handling of GstQuery and still
chain up to the parent class to handle the ones that they don't want
to handle

We were using the wrong variable ...

CID #1316477

When an upstream element wants to flush downstream, we need to take
all chains/groups into consideration.

To that effect, when a FLUSH_START event is seen, after having it
sent downstream we mark all those chains/groups as "drained" (as if
they had seen a EOS event on the endpads).

When a FLUSH_STOP event is received, we check if we need to switch groups.
This is done by checking if there are next groups. If so, we will switch
over to the latest next_group. The actual switch will be done when
that group is blocked.

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

When upstream events/queries reach sinkpads of unlinked groups (i.e.
no longer linked to the upstream demuxer), this patch attempts to find
the linked group and forward it upstream of that group.

This is done by adding upstream event/query probes on new group sinkpads
and then:
* Checking if the pad is linked or not (has a peer or not)
* If there is a peer, just let the event/query follow through normally
* If there is no peer, we find a pad to which to proxy it and return
  GST_PROBE_HANDLED if it succeeded (allowing the event/query to be properly
  returned to the initial called)

Note that this is definitely not thread-safe for the time being

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

Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer

This reverts commit 8a645924.

Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer

This reverts commit ea9b6a7e.

Avoids useless check of downstream caps when handling an
accept-caps query

Avoids useless check of downstream caps when handling an
accept-caps query

Add gst_audio_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary

API: gst_audio_decoder_set_use_default_pad_acceptcaps

Add gst_video_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary

API: gst_video_decoder_set_use_default_pad_acceptcaps

Use the object lock to protect the internal segment when updating
against access from getting the stats property.

Fix a critical in gst-inspect or when retrieving the stats
before any segment has arrived by checking whether the
segment has been initted..

When we see prefix NALs before a Subset SPS has been spotted,
it might just be because the stream was truncated at the
start, so don't count those as either 'bad' or 'good' packets.

Just for consistency. No need to keep data around.

Just for consistency with the preroll_segment

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

last_segment is only being updated in dequeue_buffer(),
which is only called from _pull_sample(). _pull_preroll()
simply re-uses an old or dummy segment while the actual
one sits and waits in the queue.

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

Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.

API: gst_video_decoder_sink_query_default

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

Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.

API: gst_audio_decoder_sink_query_default

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

Makes it easier to differentiate from other modules states unit test

Just let the internal element of the bin do it instead of forcing a
caps query to do it.

If the pixel-aspect-ratio is not fixed, try to get it as close
to 1/1 as possible

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

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

The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the audio tag.

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

Since the videorate element just duplicates or drops frames
to achieve the desired framerate, it can accept video/x-bayer media
(in any format), which are not present in the current caps.
Just add "video/x-bayer(ANY);" to the caps of the static pad template
(fixing line style to pass the indent commit hook).

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

There was a confusion, six depayloaders where passing through the
timestamp while the base class was re-timestamping to running
time. This inconstancy has been unnoticed has in most use cases
the incoming segment is [0, inifnity] in which case timestamps are
the same as running time. With DTS/PTS shifting added (to avoid
negative values) and pcapparse sending a different segment this
started being an issue.

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

gstvideoencoder.h:228: Warning: GstVideo: "@transform_meta"
parameter unexpected at this location:
 * @transform_meta: Optional. Transform the metadata on ...

Remove some whitespace and break lines longer than 80 columns

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

Push all pending events before pushing the gap. This ensures the
segment is pushed before the gap so it can be properly translated
to the running time

Includes unit test.

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

Otherwise, they will refer to freed memory

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

deadend_details need not be returned when the pad is not a deadend.
Hence checking if res value is TRUE and clearing the string instead of
passing it on

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

DTS is for encoded data and have no meaning for raw. It better to not
set it, as it's confusing.

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

If the initial seek fails because the pad is
flushing, then return GST_FLOW_FLUSHING instead
of an error.

Previous commit was incompletely applied.

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