The problem is that even though the functions we are calling are
in-place transformation, orc automatically puts the restrict keyword
on all arguments. To silence that warning just create yet-another
variable containing the same value.

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

There is no GPLv2 code in this repo.

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

And also handle flushing, we might otherwise wait here forever when
flushing too.

Otherwise shutting down during EOS waiting will cause a deadlock.

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

It is possible that both application and the stream are waiting
currently, if for example the following happens:
  1) app is waiting because no buffer in appsink
  2) appsink providing a buffer and waking up app
  3) appsink getting another buffer and waiting because it's full now
  4) app thread getting back control

Previously step 4 would overwrite that the appsink is currently waiting,
so it would never be signalled again.

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

We used to get:

    gst_audio_format_from_string: assertion 'format != NULL' failed

Instead of trying to guess what profile to build, just get the possible
elements to use with the specified caps and determine the
EncodingProfile from it.

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

With the way caps negotiation work in encoders, the only way to ensure
that no downstream renegotiation is done in the encoder is to also lock
upstream caps. Anyway with the current behavior upstream of encoders
*require* to handle any file format so locking upstream format should
be safe.

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

If the output tag had been exposed, it never ever updated
even if we reset the tagmux using state change.

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

Ignore to handling a pad of decodebin3 which doesn't have corresponding output
when it is removed.

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

Michael Olbrich authored 6 years ago and Nicolas Dufresne committed 6 years ago

When frames are dropped or reordered then the serialized events are
collected and pushed with the next frame. This test verifies that the
order is preserved.

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

Matthias Fend authored 7 years ago and Nicolas Dufresne committed 6 years ago

Since events are pushed out in reverse order, newer events need to
be added at the front of event lists

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

Hyunjun Ko authored 7 years ago and Nicolas Dufresne committed 6 years ago

If we can guarantee the lifetime of the fd is longer than
the memory, we can use DONT_CLOSE flag not to close when release.
But it's not provided in gstdmabuf yet while gstfdmemory does.

For example, in case of using VA-API or MSDK, we would need this api.
Otherwise we should call dup to duplicate the fd.

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

qmlgl plugin will use this api

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

gstgldisplay_viv_fb.h is need by qmlgl plugin in gst-good package

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

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

Just like the autotools build.

Also don't use __bridge casts if ARC is not used, as is the case on 32
bit systems.

On 64 bit systems they're typedefs of each other but on 32 bit systems
not, and we pass the rect to an API that expects a NSRect

This reverts commit 35d0783f.

ayaka authored 8 years ago and Nicolas Dufresne committed 6 years ago

This pixel format is a fully packed variant of NV12, a luma
pixel would take 10bits in memory, without any filled bits
between pixels in a stride. The color range follows
the BT.2020 standard.

In order to get a performance in hardware memory
operation, it may expend the stride, append zero data at the
end of echo lines.

Signed-off-by: ayaka <ayaka@soulik.info>

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

Mostly related to out and array parameters

Mostly related to out and array parameters

Mostly related to out and array parameters

Mostly related to out and array parameters

Mostly related to out and array parameters.

Mostly related to out and array parameters.

In the situation described in
https://bugzilla.gnome.org/show_bug.cgi?id=795397,

downstream_caps consists of two structures, the first with
the preferred rate, if at all possible (44100), the second
containing the full range of allowed rates, as audioresample
correctly tries to negotiate passthrough caps.

As audioaggregator cannot perform rate conversion, it wants
to return a fixated rate in its getcaps implementation,
however it previously directly used the first structure in
the caps allowed downstream, without taking the filter into
consideration, to determine the rate to fixate to.

With this, we first intersect our downstream caps with the
filter, in order not to fixate to an unsupported rate.

This completes what commit 0de0f3b2 should have already done. :)

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

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

Not sure how that slept through but that case is possible and leads
to segfaults in any code path of the function right now.

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

Otherwise it won't be possible to specify some profiles such as

    video/x-h264,profile=(string)high-4:4:4

With this patch, we can do

    video/x-h264,profile=(string)high-4\:4\:4

Required is not a valid kwarg for cc.has_header()

The default implementation for packet loss handling previously
always sent a gap event.

While this is correct as long as we know the packet that was
lost was actually a media packet, with ULPFEC this becomes
a bit more complicated, as we do not know whether the packet
that was lost was a FEC packet, in which case it is better
to not actually send any gap events in the default implementation.

Some payloaders can be more clever about, for example VP8 can
use the picture-id, and the M and S bits to determine whether
the missing packet was inside an encoded frame or outside,
and thus whether if it was a media packet or a FEC packet,
which is why ulpfecdec still lets these lost events go through,
though stripping them of their seqnum, and appending a new
"might-have-been-fec" field to them.

This is all a bit terrible, but necessary to have ULPFEC
integrate properly with the rest of our RTP stack.

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

Simple optimization to reduce memory allocations.

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

Otherwise decodebin won't get notified about STREAM_COLLECTION comming
from the sources and thus will never get informored about it. Without
being informed about the stream collection decodebin won't be able to
select any streams. It ends up not creating any output for the streams
defined from outside parserbin.

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

Omar Akkila authored 6 years ago and Olivier Crête committed 6 years ago

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

The newly-added build definitions for test/icles relied
on dependencies that were only defined when the examples
are enabled, thus breaking meson build -Ddisable_examples=true

the meta initialization function is provided *after* the base implementation
fields have been set so do *NOT* reset them otherwise it would result
in corrupted GstMeta.

Instead explicitely set our fields to the default values we actually want.