- Jan 04, 2021
-
-
Thibault Saunier authored
It was introduced in 1.16
-
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: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/798>
-
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: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/798>
-
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: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/798>
-
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 https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/683 Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/798>
-
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: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/719>
-
* 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: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/687>
-
Make explicit that the returned strings need to be g_free()-able. Fixes #753 Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/652>
-
-
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 94bb76b6b9c48981d3ad42a8c4370b9658db4229, 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).
-
Reset the splitmuxsink completely when changing states so that it can be reused. Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1241
-
Split the decision for keyframe request and fragmentation in order to ensure periodic keyframe request.
-
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 -
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.
-
Allow to change the fragment-id start index.
-
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.
-
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.
-
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.
-
Add the G_SIGNAL_ACTION flag to the split-* signals on splitmuxsink, and make some improvements to their docstrings
-
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 https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/977
-
Make the debug output less confusing by not mentioning a src pad when doing calculations on the sink pad side. Improve debug around why a GOP is considered overflowing a fragment
-
Makes debug output more useful
-
There is only a single sink element in async-finalize mode, and we would keep the running time from previous fragments set in that case. As we don't ever set the running time for the very last fragment on EOS, this would mean that the closing time reported for the very last fragment is the same as the closing time of the previous fragment.
-
Apart from the obvious drawbacks of hardcoding, the drawback here was that, if we subtracted 2 frames (instead of 2.6) from the target running time, we'd request the next keyframe a bit too far into the future, which would make our files split at the wrong position. https://bugzilla.gnome.org/show_bug.cgi?id=797293
-
Was previously: if ( x | y && a == b). Changed it into if ((x & y) && (a == b)).
-
For drop-frame framerates, when the expected next max timecode wraps around at the end of the day, we have to subtract the offset of the daily jam, otherwise we end up with a duration that's a few frames too long. https://bugzilla.gnome.org/show_bug.cgi?id=797270
-
-
