With mpeg4videoparse drop=false config-interval=N|-1 we might be
trying to insert a config before we have actually received one,
in which case we'll try to map a NULL buffer which will generate
lots of criticals.
Fixes#855
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1265>
Trying to reset before the pads have been deactivated races with the
streaming thread. There was also a buggy buffer clear leaving a dangling
`stored_frame` pointer around. Use `gst_interlace_reset` so this happens
properly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1039>
There are streams in the wild that have to add a SCTE-35 trigger in
another e.g. GA94 stream. Most encoders would replace the GA94
descriptor ID with the CUEI one temporarily, but there are some that
will add two registration ID descriptors, one with GA94 and one with
CUEI.
Failing to parse the CUEI registration ID in that case would return
FALSE in _stream_is_private_section , therefore setting it as known PES
and pushing packets downstream instead of calling handle_psi.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/979>
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>
