Age | Commit message (Collapse) | Author |
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1415>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1409>
|
|
Changes from https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/1355
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1403>
|
|
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1368>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1361>
|
|
The fragment duration is expressed in nanoseconds.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1348>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1318>
|
|
|
|
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/389
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1299>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1294>
|
|
gtk-rs will update soonish too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1280>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1280>
|
|
We would create another chunk that ends after the fragment end, and
would from then on consider the stream always filled for the chunk
because it starts after the current fragment end (i.e. nothing would go
into this fragment).
This is obviously wrong because the actual fragment end moved further
ahead because of the additional chunk.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1277>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1271>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1268>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1260>
|
|
The "Encapsulation of Opus in ISO Base Media File Format" [1] specifications,
§ 4.3.2 Opus Specific Box, indicates that data must be stored as big-endian.
In `write_dops`, `to_le_bytes` variants were used.
Related to [2].
[1] https://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
[2] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4875
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1247>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1243>
|
|
fragment end
Simply don't output anything for this stream and only include it in the
future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1229>
|
|
current chunk
There's not going to be any buffer to output for this stream in the
current chunk.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1229>
|
|
This reverts commit 04bb7b4db0fcf84283c07297b1577dd97564a0f9.
As Sebastian points out, the chunk PTS is already in running time, so
this was wrong from the start.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/363
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1219>
|
|
Also, apply auto-naming in the following cases
* When building from a non wildcard-named template, the name of the template is
automatically assigned to the Pad. User can override with a specific name by
calling `name()` on the `PadBuilder`.
* When building with a target and no name was provided via the above, the
GhostPad is named after the target.
See https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/448
Auto-naming discussion: https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/1255#note_1891181
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1197>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1210>
|
|
After calculating the earliest pts, the fragment_start_pts and
chunk_start_pts in State are updated. However, when checking if the
stream is filled, the previous start_pts (set to None) is used instead.
This means that chunk_filled and fragment_filled will be false the first
time aggregate() is called, assuming timeout is false, all_eos is false,
and the sinkpad is not EOS. This requires aggregate() having to be
called a second time before the first fragment is sent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1207>
|
|
Required to validate the manifest with https://beta.conformance.dashif.org/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1196>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1193>
|
|
Not sure why rustfmt updated those because of my previous change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1177>
|
|
Maybe a bit overkill for such simple example but more exemplary for
actual applications.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1177>
|
|
Git will de-duplicate the contents for us anyway, and
symlinks can cause problems with some versions of git
and also on Windows.
https://github.com/mesonbuild/meson/issues/11646
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4326
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1157>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1134>
|
|
We were currently returning a value based on the next chunk PTS, but the
expectation in GstAggregator is that we return a running time. This
resulted in spurious wakeups and warnings like:
0:00:01.501685123 1552995 0x55899715c1e0 WARN fmp4mux mux/fmp4/src/fmp4mux/imp.rs:1818:gstfmp4::fmp4mux::imp::FMP4Mux::drain_buffers:<fmp4mux0:sink_1> Don't have a complete GOP for the first stream on timeout in a live pipeline
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1127>
|
|
Specifically, get rid of now unneeded `&`.
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1096>
|
|
like mp4mux in -good does already
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1094>
|
|
like mp4mux in -good does already
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1094>
|
|
|
|
This works around non-determinism in aggregator where depending on
timing it can happen that it consumes all buffers from both pads or
waits for another buffer on one pad while the other one already has one.
The effect in this test was that it sometimes timed out. By providing
one more buffer it is guaranteed now that at this point the muxer is
beyond the end of the first fragment.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1081>
|
|
need more data for finishing a GOP
In other words, continue queueing buffers in sync from all streams until
all of them are ready for draining instead of stopping to queue buffers
on every stream that is already filled individually.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/310
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1081>
|
|
Either create further chunks if enough data is queued or simply start
the new fragment at a later time if the keyframe is later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1077>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1075>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1075>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1075>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1075>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1071>
|
|
Split many longer functions into multiple functions and simplify various
parts. Overall this is functionally still the same as before.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1068>
|
|
Allow outputting sub-fragments (chunks in CMAF terms) that are shorter
than the fragment duration and don't usually start on a keyframe. By
this the buffering requirements of the element is reduced to one chunk
duration, as is the latency.
This is used for formats like low-latency / LL-HLS and DASH.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1059>
|
|
Add it only to 'isofmp4mux', the onvif variant already does this and
CMAF and DASH are always single-stream so you rely on inter-container
synchronization via the running-time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1063>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1062>
|
|
The flags are based on the first sample of this fragment so writing it
into any trun but the first is not very useful.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1060>
|