| Age | Commit message (Collapse) | Author |
|---|
|
at queue
Previously livesync was waiting for the start timestamp of the current
buffer after looking at the queue and right before pushing it
downstream. This meant that it generally looked too early at the queue
and especially that upstream had to provide the next buffer already at
the start timestamp of the previous one.
Instead, now wait before looking at the queue and wait for the end
timestamp of the previous buffer. Once the previous buffer has expired,
a new buffer really needs to be available or otherwise a filler buffer
has to be pushed downstream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1266>
|
|
I've looked at the GstQueue code again and tried making livesync behave
better with EOS. This isn't very well tested, though. My goal was to
make this look saner but I think this should be reviewed by someone who
knows the queue code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1266>
|
|
Spawning one task per message to send out instead of sending them out
sequentially from the one task used to poll the handler sometimes
resulted in peers receiving ICE candidates before SDP offers, triggering
hard to understand errors in the browser.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1253>
|
|
.. and log an error with advice on how to dispose of elements properly
from a tokio runtime.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1253>
|
|
|
|
|
|
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
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/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Assumes that caption stream's timeline starts from zero,
and maps timecode time_since_daily_jam() to PTS directly without
subtracting the first seen timecode.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Fix the following use case:
- main input of fallbackswitch is finite (a media file)
- fallback input is infinite (videotestsrc)
- main input is done and send eos, which is propagated downstream
- fallbackswitch switches to fallback, sending STREAM_START which reset
EOS downstream (aggregator does that)
- fallback input keeps pushing buffers forever.
Solve it by adding a 'stop-on-eos' property so fallbackswitch stops
pushing property once the main input is eos.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
And use MPL-2.0 for all that require GStreamer 1.20 or newer. The new
string is only allowed in 1.20 or newer and using it in older versions
causes failure to load the plugin.
All affected plugins are of course still MPL-2.0 licensed.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/374
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1248>
|
|
|
|
|
|
|
|
and add it up to subsequent transcripts.
This ensures synchronization is maintained even after the input stream
experiences a discontinuity and a gap in its timestamps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
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/1233>
|
|
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/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Both the delay-based *and* loss-based estimates should be computed instead of
just one. This ensures faster adaptation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
It's invalid to request pads with a pad template that is not part of the
element, and results in a critical warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
- Stop passing webrtcbin around without using it
- Stop using glib::closure as clippy complains when using a unit type
default-return
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
First off, we just created the session, we know stats_sigid is None
at this point.
Second, don't first assign the result of connecting on-new-ssrc to the
field, then the result of connection twcc-stats, that simply doesn't
make sense.
Finally, actually check that stats_sigid *is* None before connecting
twcc-stats, as I understand it this must have been the original
intention / behavior.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
If webrtcbin was disposed of at this point, simply return
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/345
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1233>
|
|
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/1233>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1215>
|
|
That was not making sense.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1215>
|
|
We used to pass all media keys and attributes to the caps which
incorrect. Instead we should be using only the keys from the map
and remove all information related to rtcp which is irrelevant
to create the transceiver.
This also simplifies the code.
New caps look like:
```
Caps(
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 96,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "VP8",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 102,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "H264",
packetization-mode: (gchararray) "1",
profile: (gchararray) "baseline",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 104,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "H264",
packetization-mode: (gchararray) "0",
profile: (gchararray) "baseline",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 106,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "H264",
packetization-mode: (gchararray) "1",
profile: (gchararray) "constrained-baseline",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 108,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "H264",
packetization-mode: (gchararray) "0",
profile: (gchararray) "constrained-baseline",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 127,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "H264",
packetization-mode: (gchararray) "1",
profile: (gchararray) "main",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 39,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "H264",
packetization-mode: (gchararray) "0",
profile: (gchararray) "main",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 98,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "VP9",
profile-id: (gchararray) "0",
},
application/x-rtp(memory:SystemMemory) {
media: (gchararray) "video",
payload: (gint) 100,
clock-rate: (gint) 90000,
encoding-name: (gchararray) "VP9",
profile-id: (gchararray) "2",
},
)
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1215>
|
|
Intended behavior is configuring audio convert/resample elements
only for the fallback stream and also fallback-audio-caps is set.
Video and image stream are doing it as intended already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1215>
|
|
I just wasted lots of time trying to figure out why my higher priority
pad wasn't used...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1215>
|
|
In certain cases, roundedcorners would negotiate to I420 even when user
supplied a non-zero border radius.
For example, the below pipeline leads to I420 being negotiated even
though a non-zero border radius was given. Ideally, this pipeline
should have failed at the negotiation stage.
```bash
gst-launch-1.0 -v \
videotestsrc num-buffers=1000 pattern=white ! \
video/x-raw,width=320,height=180 ! \
roundedcorners border-radius-px=10 ! videobox border-alpha=0 top=-10 left=-10 right=-10 bottom=-10 fill=yellow ! \
compositor name=comp sink_0::xpos=960 sink_0::ypos=0 sink_0::width=320 sink_0::height=180 sink_0::alpha=1.0 sink_1::xpos=960 sink_1::ypos=180 sink_1::width=320 sink_1::height=180 sink_1::alpha=1.0 \
sink_2::xpos=960 sink_2::ypos=360 sink_2::width=320 sink_2::height=180 sink_2::alpha=1.0 sink_3::xpos=0 sink_3::ypos=0 sink_3::width=960 sink_3::height=720 sink_3::alpha=1.0 ! \
video/x-raw,width=1280,height=720! x264enc ! mp4mux ! filesink location=test.mp4 \
videotestsrc num-buffers=1000 pattern=red ! \
video/x-raw,width=320,height=180 ! roundedcorners border-radius-px=10 ! comp. \
videotestsrc num-buffers=1000 pattern=blue ! \
video/x-raw,width=320,height=180 ! roundedcorners border-radius-px=10 ! comp. \
videotestsrc num-buffers=1000 pattern=green ! \
video/x-raw,width=960,height=720 ! roundedcorners border-radius-px=10 ! comp.
```
If border radius is non-zero, we should not really allow negotiation
to select I420. Fix this by returning only A420 for border-radius > 0
in `transform_caps` instead of returning both like earlier.
Another example of a simpler pipeline like below which would earlier work
```bash
gst-launch-1.0 videotestsrc pattern=red ! videoconvert ! video/x-raw,width=1923,height=1087,format=I420 ! roundedcorners border-radius-px=40 ! video/x-raw,format=I420 ! videoconvert ! gtksink
```
now fails with
```bash
WARNING: erroneous pipeline: could not link roundedcorners0 to videoconvert1, roundedcorners0 can't handle caps video/x-raw, format=(string)I420
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1215>
|
|
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/1215>
|
|
|
|
|
|
|
