They're not recommended by the spec to include in the RTP packets but it
is valid to include them. Pion is including them.
When parsing the size fields also make sure to only take that much of a
payload unit and to skip any trailing data (which should not exist in
the first place).
Pion is also currently storing multiple OBUs in a single payload unit,
which is not allowed by the spec but can be easily handled with this
code now.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/560
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1612>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if cancellation should happen and reset this
later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if unlock() was called and reset this in
unlock_stop().
Also implement actual unlocking in s3hlssink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if unlock() was called and reset this in
unlock_stop().
Also actually implement unlock() / unlock_stop() for the sink, and don't
cancel in stop() as unlock() / unlock_stop() would've been called before
that already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if unlock() was called and reset this in
unlock_stop().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
- generate a new session id for every new client
use the session id in the resource url
- remove the producer-peer-id property in the WhipServer signaler as it
is redundant to have producer id in a session having only one producer
- read the 'producer-peer-id' property on the signaller conditionally
if it exists else use the session id as producer id
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1339>
- Add a new structure Session
- manage each producer using a session
- avoid send EOS when a session terminates, instead keep running
waiting for any new producer to connect
- Maintain a bin element per session
- each session bin encapsulates webrtcbin and the decoder if needed
as well as the parser and filter if requested by the application
(through request-encoded-filter)
- this will be helpful to cleanup the session's respective elements
when the corresponding producer terminates the session
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1339>
There is now two elements, rtpsend and rtprecv that represent the two
halves of a rtpsession. This avoids the potential pipeline loop if two
peers are sending/receiving data towards each other. The two halves can
be connected by setting the rtp-id property on each element to the same
value and they will behave like a combined rtpbin-like element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1426>
Can receive and recevie one or more RTP sessions containing multiple
pt/ssrc combinations.
Demultiplexing happens internally instead of relying on separate
elements.
Co-Authored-By: François Laignel <francois@centricular.com>
Co-Authored-By: Mathieu Duponchelle <mathieu@centricular.com>
Co-Authored-By: Sebastian Dröge <sebastian@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1426>