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

gst_bus_add_signal_watch() takes a ref on the bus which should be
released using gst_bus_remove_signal_watch().

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

GST_PKG_CONFIG_PATH is used in docs/plugins directory, so
AG_GST_PKG_CONFIG_PATH must be called to set it.

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

At the end of a range request, we don't want to return GST_FLOW_EOS otherwise
the last bytes we just read will be dropped by basesrc.

Instead just return GST_FLOW_OK (which was set just before) and let basesrc
handle the fact we are at the end of the segment.

The type detection would lead to assertion as it would try
to create a device without having found any type for it. It
also didn't detect MPLANE devices properly.

The monitor sets the object->element object as a GstObject. This
works for debug traces, but will assert for ELEMENT_ERROR. This
was the only case where that could happen. Add a check for that.

If we're at the end of a range request, read again to let libsoup
finalize the request. This allows to reuse the connection again later,
otherwise we would have to cancel the message and close the connection.

From f363b32 to f49c55e

We have to get rid of the message on EOS when the complete stream is read to
remember that we successfully finished handling this specific message.
Otherwise we will cancel it later and close the connection instead of reusing
it at a later time.

It might also make sense to reuse connections if a non-200 response is
received. As long as there was no connection error, the HTTP connection should
be re-usable.

Also stop fetching the internal source as this
functionality has been broken.

Most of those have V4L2 drivers these days enabling it make sure that it
this code is enabled in major distribution, hence that HW accelerated
decoder/encoder can be used on platforms that support it. The probes are
slightly increasing the first init of gstreamer library, though the
result is cached in the registry for later use.

When parsing NAL unit type in codec_data, check the 6bits of
NAL_unit_type only and do not require the array_completeness bit to be
0, since the default and mandatory value of array_completeness is 1 for
hvc1.

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

This fixes regression where M2M error out saying they have no output
format (the V4L2 CAPTURE side).

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

Fixes the build on FreeBSD, which does not have the latter.

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

After switching to using V4L2_CAP_DEVICE_CAPS we lost support for
multiplanar device types. After some research, it looks like
vcap.capabilities treated the multiplanar flag of output and capture
devices equally, but not the new device_caps.

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

And pass-through both of them.

Based on a patch by Göran Jönsson <goranjn@axis.com>

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

Otherwise we'll wait forever.

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

There's no real reason to avoid sending QOS/NAVIGATION events upstrea.
Some elements might want to have that information.

There's no real reason to avoid sending QOS/NAVIGATION events upstrea.
Some elements might want to have that information.

There's no real reason to avoid sending QOS/NAVIGATION events upstrea.
Some elements might want to have that information.

Also remove downstream-only CAPS event handling and minimize code

A typo in gst_v4l2_probe_and_register() caused a build error when building
with --enable-v4l2-probe. Fixing it.

gstv4l2.c: In function 'gst_v4l2_probe_and_register':
gstv4l2.c:150:25: error: 'struct v4l2_capability' has no member named 'capabilitites'
       device_caps = vcap.capabilitites;

Reynaldo H. Verdejo Pinochet authored Jul 01, 2016 and Nicolas Dufresne committed Jul 07, 2016

Instead of reimplementing the GST_CAPS_INTERSECT_FIRST
interection mode.

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

Reynaldo H. Verdejo Pinochet authored Jul 02, 2016 and Nicolas Dufresne committed Jul 07, 2016

The same physical device can export multiple devices. In
this case, the capabilities field now contains a union of
all caps available from all exported V4L2 devices alongside
a V4L2_CAP_DEVICE_CAPS flag that should be used to decide
what capabilities to consider. In our case, we need the
ones from the exported device we are using.

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

We should add all pads, no matter if they are linked or active or not at this
point. Skipping some that are not will cause different behaviour than with
other muxers.

This can only happen if a) upstream somehow gets around the CAPS event failing
or b) there never being any CAPS event.

The following code assumes that all pads have a codec-id.

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

Handle sprop-vps, sprop-sps and sprop-pps in caps instead of
sprop-parameter-sets.

rtph265pay works with byte-stream and hvc1 formats but not hev1 yet. It
handles profile-id, tier-flag and level-id in caps query.

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

Add per-stream tag lists, which are used to send nominal
bitrate tags. When remuxing FLV => FLV, this now passes
through the upstream bitrate.

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

The FLV header cannot be trusted to indicate video or
audio presence, as the comments already mention. Don't
delay pushing tags waiting for streams that might never
appear.

Tags are now pushed immediately after they change:
  - After parsing an onMetaData script object
  - After negotiating caps on a pad

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

As seen in the parent switch for object_type_id, the 4 possible values are
0x40, 0x66, 0x67 and 0x68. Fixing the nested switch to match these values.

Looks like it was a typo making them decimal instead of hexadecimal.

CID 1363328

There's a small window for a race condition otherwise.

If necessary, a demuxer will have to invent something here but this is only a
problem with non-conformant files anyway.