Make sure to always update next_cluster_offset, if next cluster offset
isn't known set it to zero. If next_cluster_offfset isn't updated it will
be the same as current and if the cluster parsing fails the same cluster
will be parsed again leading to duplication of the data in the cluster.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8855>
Due to race condition it was previously possible that
gst_element_add_pad was not completed for each RTSP stream before
signal 'no-more-pads' was emitted.
Race condition explained:
Lets say two RTSP streams are created: Video and Audio.
1. Callback new_manager_pad is called for the Video stream =>
stream->added=TRUE.
all_added=FALSE because both streams are not yet added.
Call gst_element_add_pad and emit signal 'pad-added' for Video stream.
2. Callback new_manager_pad is called for Audio stream =>
stream->added=TRUE.
all_added=TRUE because both streams are added.
Call gst_element_add_pad and emit signal 'pad-added' for Audio stream.
3. Lets say gst_element_add_pad for the audio stream completes before
the video stream. Since the audio stream already has all_added==TRUE
this will result in the signal 'no-more-pads' to be emitted before
gst_element_add_pad for the video stream is completed.
Solution is to move the logic that sets added=True and checks if all
streams are added to after gst_element_add_pad. This will make sure
signal 'no-more-pads' is not emitted until all code in
gst_element_add_pad is completed for all streams.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8832>
- LUT now supports various subsampling, interleaves, and bit depths.
- Replaces stride with GstVideoInfo pre_info to represent original data.
- Simplifies gst_row_align_buffer() with gst_video_frame_copy().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8598>
Since y4menc inherits from GstVideoEncoder, it negotiates upstream buffer pools
with GstVideoMeta support. Thus, certain decoders might use that meta for
frames with padded memory. Nonetheless y4menc assumes only linear memory video
frames, without padding.
This patch will copy frames using gst_video_frame_copy() if buffer has
GstVideoMeta or its video info is padded with its custom video info. Otherwise,
it ill call the agnostic gst_buffer_copy() for a shallow copy.
Supersedes: !5042Fixes: #2765
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8654>
There are 3 32bit integers per entry and not one more for all but the last.
Fixes a regression introduced in 5a9e80c01b4b49c6c7630a6d08b600114f38c0db
when playing back files that have one sample table entry per audio sample.
Merging the sample tables would've always failed because of the too strict size
check and one audio sample per GStreamer buffer would've been output, which
doesn't perform very well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8657>
For some cases, maybe the timestamp of gap event is smaller than
segment start value or larger than segment stop value in playback.
And the timestamp plus duration may exceed segment boundary. Need
check and clip the timestamp or duration before recalculating.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8517>
We cannot rely only on the DISCONT flag when deciding whether we need to
request a new key frame or not because it might be that the packet that just
came in with the DISCONT flag is actually the start of a keyframe.
This patch improves the logic to be the same as rtph265depay, by only requesting
a key frame if the packet with the DISCONT flag is not the first one of a FU; or
if its the first one, only request it when we could drop packets due to a
missing key frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8343>
This fix handles the case where the order of components in the cmpd box
does not correspond to the order used for a specific track. That
is the case where the uncC component_index values are something
other than 0, 1, 2, 3.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8483>
Checking whether rtpjitterbuffer actually timestamps the buffers according to
the RFC7273 clock definition and rtpjitterbuffer configuration required looking
at the DEBUG logs.
This commit adds an entry in the rtpjitterbuffer stats to indicate if
conditions are met for RFC7273 to be active.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7829>
Similar to qtdemux.
Tested against other Gst elements and MPV. Note that the later
apparently does not show correct results for flipped values.
In particular the Yaw value seems to get ignored by many clients.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8319>