If we can calculate timestamps for buffers, then set the duration
on outgoing buffers based on the number of samples depayloaded.
This can fix the muxing to mp4, where otherwise the last packet
in a muxed file will have 0 duration in the mp4 file.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6456>
Some driver doesn't implement enum_framesize. The maximum supported
size can be got by trying format with a very large size. Also need
to set max_width/max_height for this case, otherwise default encoded
buffer size 256kB is too small.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6430>
When we're doing a state change from PLAYING to NULL, first we invoke
gst_rtspsrc_loop_send_cmd_and_wait (..., CMD_CLOSE, ...) during
PAUSED_TO_READY which will schedule a TEARDOWN to happen async on the
task thread.
The task thread will call gst_rtspsrc_close(), which will send the
TEARDOWN and once it's complete, it will call gst_rtspsrc_cleanup()
without taking any locks, which frees src->streams.
At the same time however, the state change in the app thread will
progress further and in READY_TO_NULL it will call gst_rtspsrc_stop()
which calls gst_rtspsrc_close() a second time, which accesses
src->streams (without a lock again), which leads to simultaneous
access of src->streams, and a segfault.
So the state change and the cleanup are racing, but they almost always
complete sequentially. Either the cleanup sets src->streams to NULL or
_stop() completes first. Very rarely, _stop() can start while
src->streams is being freed in a for loop. That causes the segfault.
This is unlocked access is unfixable with more locking, it just leads
to deadlocks. This pattern has been observed in rtspsrc a lot: state
changes and cleanup in the element are unfixably racy, and that
foundational issue is being addressed separately via a rewrite.
The bandage fix here is to prevent gst_rtspsrc_stop() from accessing
src->streams after it has already been freed by setting src->state to
INVALID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6330>
And also re-timestamp them with the current buffer's PTS.
Not doing so keeps the timestamps of event packets as
GST_CLOCK_TIME_NONE or the timestamp of the previous buffer, both of
which are bogus.
Making sure that (especially) the first packet has a valid timestamp
allows putting e.g. the NTP timestamp RTP header extension on it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6298>
Parse the speed and scale in the server's response
*before* the range, so that the range start/stop
are swapped (or not swapped) correctly based
on the server's actual chosen values. Otherwise,
the old rate from the segment is used - what the
last seek asked for, but not necessarily what
the server chooses.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6295>
If input height and parsed one are identical, do not consider it as interlaced
Fixing below pipeline:
gst-launch-1.0 videotestsrc ! video/x-raw,format=I420,width=640,height=10 \
! jpegenc ! jpegparse ! jpegdec ! videoconvert ! autovideosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6181>
After a flushing seek, rtspsrc doesn't reset the last_ret value for
streams, so might immediately shut down again when it resumes pushing
buffers to pads due to a cached `GST_FLOW_FLUSHING` result
Prevent a stored flushing value from immediately stopping
playback again by resetting pad flows before (re)starting
playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6137>
Because this depayloader may build several output buffers within one
process run we push them all into a GstBufferList and push them out at
once to make sure that each buffer gets notified about each header
extension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5378>
Because this depayloader may build several output buffers within one
process run we push them all into a GstBufferList and push them out at
once to make sure that each buffer gets notified about each header
extension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5378>
Because this depayloader may build several output buffers within one
process run we push them all into a GstBufferList and push them out at
once to make sure that each buffer gets notified about each header
extension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5378>
Because this depayloader may build several output buffers within one
process run we push them all into a GstBufferList and push them out at
once to make sure that each buffer gets notified about each header
extension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5378>
Because this depayloader may build several output buffers within one process
run we push them all into a GstBufferList and push them out at once to
make sure that each buffer gets notified about each header extension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5378>
