GitLab

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

This reverts commit 8fe478c8.

We're back to previous behaviour

When resurrecting a buffer, the subsequent free call can result
in the group-released handler being called again, which causes
a recursive loop.  This patch blocks the signal handler during
the time that it executes, ensuring that the loop will not occur.

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

Since 1.6, the transfer function for BT2020 has been changed from BT709
to BT2020_12. It's the same function, but with more precision. As a side
effect, the V4L2 colorpsace didn't match GStreamer colorspace. When
GStreamer ended up making a guess, it would not match anything supported
by V4L2 anymore. This this by using BT2020_12 for BT2020 colorspace and
BT2020 transfer function in replacement of BT709 whenever a 4K
resolution is detected.

The quirk to avoid probing interlacing didn't work anymore as the driver
is now name uvcvideo. This should slightly speed up camera startup.

Regression introduced by 86b427dc

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

Fixes a negotiation error seen when trying to playback of a .MOV file with
a mono AAC audio stream decoded by avcdec_aac that doesn't set channel-mask
field but sink was requiring channel-mask=0x3.

Do not allocate payload size outbuf if appending payload buffer.

The commit 137672ff attached payload
to the output buffer but forgot to remove payload allocation.  That
effectively doubled payload size and add zero'ed or random bytes.

Makes the following pipeline work again:

gst-launch-1.0 -v audiotestsrc wave=2 ! gsmenc ! rtpgsmpay ! rtpgsmdepay ! gsmdec ! autoaudiosink

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

This element was not checking if mapping the RTP buffer and the payload
worked, and was not checking if the RTX payload was large enough.

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

Get seqnum before unreffing the seek event.

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

Also fixes a crash caused by freeing an uninitialized mutex in an error
case.

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

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

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

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

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

Timecode trak is only supported for mov right now, not for mp4. That
code would otherwise create an invalid trak if the muxed video contained
timecode metadata.

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

Print the right one in debug output to get meaningful numbers.

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

It's more accurate and allows cancellation.

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

Such as 1.3.0 as on raspbian.

We were unnecessarily looping/goto-ing repeatedly when we had exactly
the amount of data as the free space, and also when the free space was
too small. This, as it turns out, is a very common scenario with
Directsound on Windows.

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

We have to do polling here because the event notification API that
Directsound exposes cannot be used with live playback since all events
must be registered in advance with the capture buffer, you cannot
add/remove them once playback has begun. Directsoundsrc had the same
problem.

See also: https://bugzilla.gnome.org/show_bug.cgi?id=781249

Since mss has no moov, default stsd entry should be created with media-caps.

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

That case is correctly handled below but not in the debug output.

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

If gst_segment_do_seek() fails, we shouldn't try seeking on that
resulting segment but just error out. Crashes further down the line
otherwise.