GitLab

Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.

If a non-reference stream is behind the reference stream by an amount of
time smaller than the alignment threshold (in nsec), it counts as being
after it.

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

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

We only accept new caps if they are basically the same. We don't want to
reset anything as if the caps are new, otherwise various state could get
out of sync with the current run.

Adding a 0-byte memory has not much effect.

Also add some debug output.

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

We don't have any space reserved for this in the moov and the
pre-finalized moov would have broken A/V synchronization. Error out here
now

We have some padding added after the initial moov, so a bigger updated
moov can be handled to some degree and is expected. Previously we just
ignored the padding and errored out in cases when the padding would've
just been enough.

CID 1405994

This ensures that cookies are stored and used as set by the server, and
shared with other souphttpsrc that use the same SoupSession.

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

souphttpsrc now shares its SoupSession with other elements in the
pipeline via GstContext if possible (session-wide settings are all the
defaults), or if the context was forced by the application.

This allows multiple souphttpsrcs to reuse connections, cookies, etc.

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

This sets up a moov with the correct sample positions beforehand and
only works with constant framerate, I-frame only streams.

Currently only support for ProRes and raw audio is implemented but
adding new codecs is just a matter of defining appropriate maximum frame
sizes.

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

When muxing raw audio, we have no way of storing timestamps but are just
storing a continuous stream of audio samples. If the difference between
the expected and the real timestamp becomes to big, we should error out
instead of silently creating files with wrong A/V sync.

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

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

Don't need to print the function name, gstreamer does it for you.

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

Re-arrange order of index entry struct members to avoid padding
bytes in the middle of the struct, thus potentially reducing the
overall size of the struct and reducing memory used by the index.
On Linux x86_64 the size goes down from 32 bytes to 24 bytes for
each index entry.

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