We should also take into account whether data is currently pending when checking
for gap on streams. It could very well be that some streams have very low
bitrate (and spread out) data. For those we don't want to push out a gap event.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
This is only enabled in push time mode. Furthermore it's only enabled for now if
PCR is to be ignored.
The problem is dealing with streams where the initial PTS/DTS observation might
be greater than following ones (from other PID for example). Before this patch,
this would result in sending buffers without any timestamp which would cause a
wide variety of issues.
Instead, pad segment and buffer timestamps with an extra
value (packetizer->extra_shift, default to 2s), to ensure that we can get valid
timestamps on outgoing buffers (even if that means they are before the segment
start).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
When using the following setup (the error can be reproduced using
simpler sender pipelines), the receiver resynchronises the clock on RTCP
packets. The effect was that a couple seconds were cut out of the
playback because an initial RTCP packet was dropped.
When sending out all RTCP packets (setting sync=FALSE on the RTCP
updsink), the playback is fine.
This syncs rtpsink with rtpsrc (where this property was already set).
gst-launch-1.0 filesrc location=899-en.mp3 \
! mpegaudioparse \
! mpg123audiodec \
! audioconvert \
! audioresample \
! avenc_g722 \
! rtpg722pay
! rtpsink uri=rtp://239.1.2.3:1234
gst-launch-1.0 uridecodebin rtp://239.1.2.3:1234?encoding-name=G722 \
! autoaudiosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/993>
When there are elements between the demuxer and the muxer that
introduce an offset to the running time, or when offsets are
set on pads by the application, this shift must be taken into
account when calculating the final pts_adjustement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>
mpegtsmux can receive SCTE sections from two origins: events
created by the application, and events forwarded downstream by
mpegtsdemux, containing sections that may not have been fully
parsed, and additional data to help tsmux translate times to
the correct domain, both for requesting keyframes and calculating
an accurate pts_adjustment.
The complete approach is documented further in a comment above
the relevant function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>
Instead of modifying the splice times in the incoming sections
to running time and expecting eg mpegtsmux to convert those back
to its local PES time domain, which might be impossible when
those splice times are encrypted or the specification is extended,
transmit the needed information to the muxer as separate fields in
the event:
* A pts offset field can be used by the muxer in order to calculate
a final pts_adjustment
* A rtime_map can be used by the muxer to determine the correct
running times at which it should request keyframes
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>
Makes it possible to support passing SCTE 35 cue points from
demuxer to muxer, while preserving correct timing.
This will also improve ex nihilo cue points injection, as splice
times and durations are now interpreted as running time values,
and may trigger key unit requests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/913>
