GitLab

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.

From 60aeef6 to 48a5d85

Make sure avc output doesn't contain SPS/PPS inline, but
byte-stream output does.

SPS/PPS are in the caps in this case and shouldn't be in
the stream data.

If no clock was provided directly by rtspsrc. This behaviour was removed
by f8013487 and results in rtspsrc not
providing the system clock via the rtpjitterbuffer.

As a result, if another element like an audio sink, provides a clock,
the pipeline would select that (when going to PAUSED/PLAYING again later).
Audio clocks usually don't progress in PAUSED, and thus our live source
won't be able to use the clock to produce data, making the sink never
preroll and everything is stuck.

Fixes stream where sample_description_id is specified in the tfhd

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

... unless the muxer uses the same audio pad template name as
splitmuxsink. We can't request a pad called "audio_0" on a muxer that
wants pads to be "sink_%d".

It's also done in gst_flv_demux_cleanup().

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

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

This reverts commit eeea2a7f.

It breaks EOS in some sender pipelines, see
https://bugzilla.gnome.org/show_bug.cgi?id=773218#c20

In push mode we process as much as possible in the adapter. When we receive
a DISCONT buffer which we can't match to an actual sample (based on the existing
sample table) and there is still data remaining in the incoming adapter,there is
one of two cases happening:
1) We are doing reverse playback, in which case we should flush out all pending
  data
2) We have leftover data from the previous incoming buffer... which we can't do
  anything about.

For the second case, make sure we flush out the remaining data so that we can start
parsing again from scratch.

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

Allows the application to know the exact status code that was returned
by the server in a programmatic fashion.

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

Fix unit test failure

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

They should have ideally the same timescale of the video track, which we
can't guarantee here as in theory timecode configuration and video
framerate could be different. However we should set a correct timescale
based on the framerate given in the timecode configuration, and not just
use the framerate numerator.

Make sure offset and neededbytes are properly resetted when all
streams are EOS in push-mode.

Avoids cases when some data might still be pushed by upstream (because
it didn't yet see the resulting GST_FLOW_EOS yet) and qtdemux gets
completely lost.

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