GitLab

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

unmap will set rtpbuffer->buffer to NULL, so we need to
save the pointer to access it while the RTP buffer is
unmapped.

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

This was introduced when reshuffling the buffer unmaps
in commit bc14cdf5
rtp: rtpbasedepayload: add process_rtp_packet() vfunc

Fixes make check-valgrind.

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

textoverlay: Query downstream caps for checking if caps features are supported, not just accept-caps

accept-caps is not recursive and might stop at the next downstream element,
while caps queries are generally recursive. The next element might accept any
capsfeatures we want, but that doesn't mean that further downstream it will
also work.

Additionally for the future:
We should probably check if downstream *prefers* the
overlay meta, and only enforce usage of it if we can't handle
the format ourselves and thus would have to drop the overlays.
Otherwise we should prefer what downstream wants here.

the extents rectangle is what you need to know to properly position
a buffer that has been rendered in a surface of the ink rectangle
size. This patch make the placement on par with the placement we had
before without having to over allocate.

This patch also enable placement for vertical rendering. Note that
the halginement, valighment and line-alignment default are set to
the previous default when this property is set. This is for backward
compatibility, you can change the value after setting vertical render.

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

This patch uses the ink rectangle in order to compute the size
of the surface require to render. It also correctly compute the
transformation matrix as the ink_rect position might not be at
0, 0. Additionally, shadow_offset and outline_offset (which is
in fact the diameter of a dot, not a really an offset) is now
taken into account. Redundant matrix operation has been removed
for the vertical rendering.

Take note that the matrix operation in cairo are excuted in
reverse order.

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

In case of very short files we might end up seeking in
steps of a fraction of a second, which is silly and gives
the impression that seeking doesn't actually work. Make
minimum seek step a second instead.

* Only send the caps event once if the query had support for the
  overlay composition meta.
* Only do the allocation query if it is supported through caps.
* Send overlay_caps before doing allocation query rather then normal
  caps

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

The GstVideoOverlayComposition meta coordinates should always be
in stream scale, regardless of the window size downstream. This
way the sink can always scale the composition if the window size
have changed after a buffer (with his meta) was rendered before.

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

Also add a minimum amount of comment so we can understand what
is doing what.

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

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

We need to update the render when upstream composition changes
or if it was removed.

http://bugzilla.gnome.org/show_bug.cgi?id=751157

This avoids negotiating twice. Current the _setcaps() patch does
not clear the initial reconfigure flags, which lead to systematic
double renegotiation.

http://bugzilla.gnome.org/show_bug.cgi?id=751157

Remove the optimization to skip allocation query so we can
always have the latest window size information. Also, correctly
deal with the case where there is no window size information.

http://bugzilla.gnome.org/show_bug.cgi?id=751157

This is currently a limitation of BaseTransform base class. Which means
pretty much every filters out there.

http://bugzilla.gnome.org/show_bug.cgi?id=751157

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

* cache window size event and update handle ratio
* init width with 1, don't use 0
* don't update overlay when receiving same window size
* receive window size from allocation query

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

This makes pipelines with multiple textoverlay elements possible.
The meta data is collected from the upstream textoverlay element,
merged into a new GstVideoOverlayComposition and passed down downstream.

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