GitLab

... avoiding inefficiency proportional to file size

... so skipping to next cluster happens efficiently

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

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

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

Even though hooked up to the build system, it's clear that no one
has ever built or used this with GStreamer 1.x. It wants to link
against libgstinterfaces, which no longer exists. And uses 0.10-style
raw audio caps. And the last meaningful change was done in 2009.
Let's just remove it.

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

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

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

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

Demuxer already supported it.

We currently send data to the RTSP connection from multiple threads:
whenever a command is to be handled and whenever RTCP is generated. This
can cause data corruption or worse if both happen at the same time.

As such, protect gst_rtsp_connection_send() and gst_rtsp_connection_receive()
calls with a mutex. While this means that we hold a mutex during the IO
operation, this is not actually a problem as the IO operation can be
interrupted (gst_rtsp_connection_flush()) at any time and is blocking by
itself anyway.

The last entry will most likely get new samples added to it in "robust"
muxing mode, changing the samples_per_chunk and thus making it wrong to
keep the last two entries merged. It will run into an assertion later
when adding a new sample to the chunk.

Thanks to gdiener@cardinalpeak.com for the analysis of the bug and
proposal for a solution.

There might be other chunks after the data chunk, so clipping the chunk
size with the data size can lead to a negative number and all following
calculations go wrong and cause crashes or worse.

This was introduced in 3ac119bb.

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

They can cause us to deadlock, while we're waiting for a new frame and
upstream is waiting for the allocation query to be answered before
sending a frame

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

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

Avoiding warnings like:

    WARNING: Target "elements/audioamplify" has a path separator in its name.

remove not needed code about res variable.

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

When upstream does no use the v4l2videoenc pool, we need to activate
that internal pool. Though, we relied the driver to provide a minimum
required buffer, which Qualcomm Venus driver don't currently provide.

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

There is no difference between pushing out a buffer directly
with gst_rtp_base_depayload_push() and returning it from the
process function. The base class will just call _depayload_push()
on the returned buffer as well.

So instead of marshalling buffers through three layers and back,
just push them from one place in handle_nal() and always return
NULL from the process vfunc. This simplifies the code a little.

Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
for clarity. Push sounds like it means being pushed out, whereas
it might just be pushed into an adapter.

This change has the side-effect that multiple NALs in a single STAP
(such as SPS/PPS) may no longer be pushed out as a single buffer if
we output NALs in byte-stream format (i.e. not aggregate AUs), but
that shouldn't really make any difference to anyone.

This adds printing the actual value of any unknown RTCP PT
to the already existing WARNING log message.

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

CID #1409852

if pad wasn't present by now everything would have broken before

CID #1409854

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

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

This implements H264 encoding support using generic V4L2 interface. It is
reported to work with Samsung MFC driver, IXM.6 CODA driver and
Qualcomm mainline Venus driver. Other platform should be supported as
none of this work is platform specific.

The implementation consist of a GstV4l2VideoEnc base class, which
implements the core streaming functionality. This base class is implemented
by GstV4l2H264Enc class that implements the caps negotiation specific to
H264 profiles and level. This implementation supports hardware with multiple
H264 encoder. Though, to make it simplier to use, the first discovered H264
encoder will be named v4l2h264enc. Other encoder found during discovery will
have a unique name like v4l2video0h264enc.

This work is the combined work of multiple developpers in the last 3
years. Thanks to all of the contributors:

  Ayaka <ayaka@soulik.info>
  Frédéric Sureau <frederic.sureau@vodalys.com>
  Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
  Nicolas Dufresne <nicolas.dufresne@collabora.com>
  Pablo Anton <pablo.anton@vodalys-labs.com>

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

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

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

As of today, the MFC encoder often need to exceed that 1 MB
size for encoded buffer we fixed earlier for decoding.

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

Use the ::process_rtp_packet() vfunc to avoid mapping the
RTP buffer twice.

gst_rtp_buffer_get_payload_buffer() returns a new sub-buffer
which will always be writable, so no need to make it writable.

We had our own copies of those while the code was in -bad, but now
we can use the existing utility functions instead of re-implementing
them.

Every g_quark_from_static_string() is a hash table lookup serialised
on the global quark lock in GLib. Let's just look up the two quarks
we need once and cache them locally for future use. While we're at it,
add new utility functions for the two most commonly used tags
(audio + video). Make first argument a gpointer so we don't have to
cast and make the code ugly. These are used for logging purposes
only anyway.

While reusing aacparse caps were not set.This fix enables aacparse to reuse in same pipeline.

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