Part-of: <!1024>

François Laignel authored Apr 20, 2021 and Sebastian Dröge committed May 05, 2021

Instead of the deprecated gst_element_get_request_pad.

Part-of: <!958>

Split plugin into features including
dynamic types which can be indiviually
registered during a static build.

More details here:

gst-build!199
!661

Part-of: <gst-plugins-good!876>

Vivia Nikolaidou authored Dec 10, 2020 and GStreamer Marge Bot committed Dec 16, 2020

Might not drain correctly

Part-of: <!838>

!798
introduced a check in the need-new-fragment logic to avoid starting a
new fragment unless there has been some data on the reference stream,
but the check is done against the number of bytes that have been
received on the input, not the number that were released for output
into the current fragment.

Fix the check to remember and test against bytes that have been sent
for output.

This also fixes a problem where starting a new fragment fails to
request a new filename from the format-location signal.

Part-of: <!833>

When posting fragment-opened and fragment-closed messages,
put a debug statement in the logs

Part-of: <!833>

Change some g_assert into element errors so that they can be
caught and the pipeline shut down.

Part-of: <!833>

Jan Schmidt authored Oct 31, 2020 and Jan Schmidt committed Oct 31, 2020

Add a new state for ending the overall stream, and use it to decide
whether to pass the final EOS message up the bus instead of dropping
it. Fixes a small race that makes the testsuite sometimes not generate
the last fragment(s) sometimes because the wrong EOS gets
allowed through too early.

Part-of: <!798>

Jan Schmidt authored Oct 31, 2020 and Jan Schmidt committed Oct 31, 2020

Using the element state lock to avoid splitmuxsink shutting
down while doing element manipulations can lead to a deadlock on
shutdown if a fragment switch happens at exactly the wrong moment.

Use a private mutex and a shutdown boolean instead.

Part-of: <!798>

Jan Schmidt authored Oct 30, 2020 and Jan Schmidt committed Oct 31, 2020

If a pad gets into the check_completed_gop method and then
the underlying conditions change on the reference context,
things could get stuck in a busy loop when the context should
instead jump back out and wait for more data.

Part-of: <!798>

Jan Schmidt authored Oct 29, 2020 and Jan Schmidt committed Oct 31, 2020

Re-enable forwarding EOS messages from fragments that are completing
asynchronously, so that splitmuxsink itself won't go EOS until they
are complete. This was disabled to work around a bug in core that
is fixed in
gstreamer!683

Part-of: <!798>

Jan Schmidt authored Sep 17, 2020 and Jan Schmidt committed Oct 31, 2020

If there has been no bytes from the reference stream muxed into
the current fragment, then time can't have advanced, there's no
GOP... this fragment would be broken or empty, so wait for some
data on the reference buffer.

Part-of: <!798>

- Release the split mux lock while removing the probes

- Flush the sinkpad to unblock other pads

- Turn check_completed_gop into a do while statement, when
  waking up we want to recheck whether the current GOP is
  ready for sending

Part-of: <!719>

Jan Alexander Steffens authored Jul 31, 2020 and GStreamer Marge Bot committed Aug 04, 2020

* Trying to disconnect a stream from a running splitmuxsink by flushing
  it results in the FLUSH_START blocking in the stream queue's
  gst_pad_pause_task because the flush did not unblock
  complete_or_wait_on_out, so add a check for ctx->flushing there.

* Add a GST_SPLITMUX_BROADCAST_INPUT so check_completed_gop notices
  flushing changed and the incoming push is unblocked.

* Pass the FLUSH_STOP along to the muxer without waiting.

Part-of: <!687>

Tim-Philipp Müller authored Jun 26, 2020 and GStreamer Marge Bot committed Jun 26, 2020

Make explicit that the returned strings need to be g_free()-able.

Fixes #753

Part-of: <!652>

Part-of: <!644>

The calculated threshold for timecode might be varying depending on
"max-size-timecode" and framerate.
For instance, with framerate 29.97 (30000/1001) and
"max-size-timecode=00:02:00;02", every fragment will have identical
number of frames 3598. However, when "max-size-timecode=00:02:00;00",
calculated next keyframe via gst_video_time_code_add_interval()
can be different per fragment, but this is the nature of timecode.
To compensate such timecode drift, we should keep track of expected
timecode of next fragment based on observed timecode.

In case we cannot rely on max-size-timecode for split decision,
post error instead of crashing

If the start of the GOP is >= the requested running time, put it into a
new fragment. That is, split-at-running-time would always ensure that a
split happens as early as possible after the given running time.

Previously it was comparing against the current incoming timestamp,
which does not tell us what we actually want to know as it has no direct
relation to the GOP start/end.

If we get a keyframe exactly at the requested running time we would only
split on the next keyframe afterwards due to wrong usage of > vs. >=.

splitmuxsink should requst keyframe depending on configured
threshold and previously requested time in order to avoid too many
keyframe request.

The queued time includes the duration of the last queued frame
(i.e., new keyframe) so the condition check should not be inclusive.
Note that the new fragment will be cut excluding the last frame
and therefore if the condition is inclusive way,
the fragment might have one frame shorter duration for all keyframe
stream such as jpeg or all-inter video streams.

Since the commit 94bb76b6, splitmuxsink
will split fragments based on queued time and the threshold of that.
So don't need to store the next timecode for split decision.

The change of various criteria for split decision while muxing is on progress
wouldn't work well as expected.

Not only the requested keyframe time, the queued size should be
a criterion for the split decision of timecode based mode
(same as max-size-time based split case).

Jan Schmidt authored Mar 19, 2020 and GStreamer Marge Bot committed Mar 19, 2020

Reset the splitmuxsink completely when changing states so that
it can be reused.

Fixes gst-plugins-bad#1241

Seungha Yang authored Mar 12, 2020 and GStreamer Marge Bot committed Mar 19, 2020

Split the decision for keyframe request and fragmentation in order to
ensure periodic keyframe request.

Sebastian Dröge authored Jan 27, 2020 and GStreamer Marge Bot committed Jan 29, 2020

If not configuring the sinks via the "location" property this can be
useful to know for which sink the fragment was actually opened/closed,
especially if finalization of the fragments is happening asynchronously.

GValue might have null object.

(gst-inspect-1.0:10304): GStreamer-CRITICAL ...
    gst_object_ref_sink: assertion 'object != NULL' failed

Sebastian Dröge authored Dec 12, 2019 and GStreamer Marge Bot committed Dec 13, 2019

Applications might handle locations and generally configuration of the
sink by themselves instead of having splitmuxsink set the location on
the sink. Nonetheless it makes sense to increment the fragment_id that
is passed to the signal so that applications know which fragment is
requested.

Stéphane Cerveau authored Dec 05, 2019 and Olivier Crête committed Dec 05, 2019

Allow to change the fragment-id start index.

Seungha Yang authored Oct 07, 2019 and Tim-Philipp Müller committed Nov 18, 2019

An application might try to access splitmuxsink from sync message handler
by g_object_{get,set} which takes lock also. In general, we don't
take lock around message handler.

fakesink does not support "location" property and was generating
a warning.

Jan Schmidt authored Jul 31, 2019 and Jan Schmidt committed Sep 06, 2019

Add a property which explicitly maps splitmuxsink pads to the
muxer pads they should connect to, overriding the implicit logic
that tries to match pads but yields arbitrary names.

Jan Schmidt authored Jul 26, 2019 and Jan Schmidt committed Sep 06, 2019

When running in async-finalize mode, request new pads from the muxer
using the same names as old pads, instead of letting the muxer assign
new ones based on the pad template name.

Jan Schmidt authored Jul 26, 2019 and Jan Schmidt committed Sep 06, 2019

Add the G_SIGNAL_ACTION flag to the split-* signals on splitmuxsink,
and make some improvements to their docstrings

Jan Schmidt authored May 25, 2019 and Jan Schmidt committed Jul 15, 2019

The primary video stream is used to select fragment cut points
at keyframe boundaries. Auxilliary video streams may be
broken up at any packet - so fragments may not start with a keyframe
for those streams.

It's currently not made mandatory by aggregator, but it might
eventually be, and is more consistent behaviour

See gst-plugins-bad#977