And create it only when starting the element.

Otherwise we constantly create/close event file descriptors,
every time we call g_socket_condition_timed_wait() or
g_socket_send_message(s)(), i.e. a lot. Which is not
particularly good for performance.

Can't create GCancellable in ::start() here because it's used
in client_new() which may be called via the add-client action
signal which may be called before the element is up and running.

Otherwise we constantly create/close event file descriptors,
every single time we call g_socket_condition_timed_wait() or
g_socket_receive_message(), i.e. twice per packet received!
This was not particularly good for performance.

Also only create GCancellable on start-up.

curpos is set and immediately after, set again. Remove the redundant
assignment.

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

And fix unref of the wrong one which will contain NULL
in an error code path.

Map output buffer after creating it and keep it mapped
until we're done with it instead of mapping/unmapping
it for every single input buffer.

It has been verified by use over time.

qtdemux creates a samples array and gets the timestamps for buffers by
accumulating their durations. When doing reverse playback of fragments,
accumulating samples will lead to wrong timestamps as the timestamps
should go decreasing from fragment to fragment and the accumulation
will produce wrong results.

In this case, when receiving a discont for fragmented reverse playback,
the previous samples information should be flushed before new data
is processed.

Implement binary search using gst_util_array_binary_search

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

Stats should be collected on the media rtp source not in the
sender one.

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

This new mode ensures that files will never exceed a certain duration
based on incoming buffer PTS (and duration if present)

Note:
* You need timestamped buffers (duh). If some of the incoming buffers don't
  have PTS, then it will just accept them in the current file

Use the same functions regardless of the mode we are using

This property can be used in combination with next-file=max-size
(and perhaps a future next-file=max-duration) to make sure that
each file part starts cleanly with a key frame and the appropriate headers.

In order for this property to work correctly, upstream elements should make
sure than any headers that need to be written in a standalone file are:
1) in the streamheader caps field
2) and/or in the stream as one or more buffers marked with GST_BUFFER_FLAG_HEADER
   that are just before the keyframe buffer

This is useful for MPEG-TS/MPEG-PS file segmenting in
combination with mpegtsmux or mpegpsmux.

Original patch by: Tim-Philipp Müller <tim@centricular.com>

From the API documentation: "Note that it is generally not
a good idea to reuse an existing cancellable for more
operations after it has been cancelled once, as this
function might tempt you to do. The recommended practice
is to drop the reference to a cancellable after cancelling
it, and let it die with the outstanding async operations.
You should create a fresh cancellable for further async
operations."

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

This reverts commit 1797c8f8.

This is fixed by the gtk-doc 1.23 release.
<para> cannot contain <refsect2>:
http://www.docbook.org/tdg/en/html/para.html
http://www.docbook.org/tdg/en/html/refsect2.html

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

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

So we can send them out once we found the next, consecutive sequence number in
case one is following.

... by using gst_rtp_buffer_compare_seqnum() and signed integers
instead of implictly using effects of integer over/underflows.

rtpjitterbuffer: When detecting a huge seqnum gap, wait for 5 consecutive packets before resetting everything

It might just be a late retransmission or spurious packet from elsewhere, but
resetting everything would mean that we will cause a noticeable hickup. Let's
get some confidence first that the sequence numbers changed for whatever
reason.

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

With gtkdoc 1.22, the XML generator fails when a itemizedlist is
followed by a refsect2. Workaround the issue by wrapping the
refsect2 into para.

Add 'name' and 'mean' fourccs, as we handle them. Right now each use would
trigger a warning.

It is needed to correctly negotiate caps with matroskamux
and most other muxers.

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

input_samples is the number of frames, but we used it as the number of
samples.

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

... by switching numerator and denominator when scaling.

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

The framerate very often is just an indication of the ideal framerate, not the
actual framerate of the stream. By just using the framerate, we confuse the
rate control algorithm algorithm as multiple frames will map to the same PTS
or have durations of 0.

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

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

Mostly gst-launch -> gst-launch-1.0
Use autovideosink/autoaudiosink more often.
Sprinkle some converters here and there.

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

Don't put filename in error message shown to user.

Fix a leak with the
validate.file.playback.change_state_intensive.samples_multimedia_cx_flac_Yesterday_flac
scenario.

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

The gst-launch script for example launch line to test qtdemux is
missing a queue before the decodebins, otherwise the gst-launch-1.0
command won't work.

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

This reverts commit d22ec496.

Application code might expect that it only gets external sources on those
signals, and get confused by this. If anything we would need to add new
signals.

Without this it seems impossible for an application to easily get notified
about the internal ssrcs that are created, e.g. sender sources, and also
to know when they are active and produce RTCP packets.

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

Guillaume Desmottes authored May 04, 2015 and Nicolas Dufresne committed May 05, 2015

handle_frame() is supposed to consume @frame, so if we don't call
gst_video_decoder_drop_frame() or gst_video_decoder_finish_frame() we have to
release it manually.

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