Pushing the buffer via gst_pad_push () in transform_ip () function
causes downstream elements to process the buffer with a reference
count > 1. This leads to performance issue if there are downstream
elements which modify the buffer memory.
However, in drop-only mode this reference is not required.
So, let GstBaseTransform push the buffer in drop-only mode.
Fixes#4258
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9532>
Some WebRTC implementations such as Pion are unhappy if the
profile-level-id isn't returned with a compatible profile as the
RFC requires. Let's try to reform it
In practice, the correct way to do this would be to not use caps
intersection, but to instead implement the correct RFC compliant
SDP O/A negotiation of formats.
Include a unit test written by Philippe Normand
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9031>
When using the custom WebKitMediaSrc element (used by WebKit and able to
perform an initial seek in playbin), a stall caused by streamsynchronizer
was detected during an initial seek. The flow of events revealed that the
intertwining of the initial configuration of the streams with the reset
caused by the flush events from the seek left streamsynchronizer in an
inconsistent state:
streamsynchronizer0:sink_0 (video) events, starting before the seek:
stream-start --> Sets the stream to wait
flush-stop --> Clears the stream wait flag
caps
tag
segment
stream-collection
(buffers start to come and flow properly)
streamsynchronizer0:sink_1 (audio) events, happening after seek:
(no flush events, because the stream hadn't been initialized when the seek happened)
stream-start --> Sets the stream to wait
caps
segment
(stalled because the stream is in wait mode!)
The code in streamsynchronizer expects that all the streams are in wait
state before releasing all of them at once. The flush on the video stream
broke that assumption and that's why the audio stream is never released in
that scenario.
Avoiding the clearing of the wait flag on flush-stop isn't an actual solution
to the problem, as it creates other side effects and at least makes the
gst-editing-services/seek_with_stop test to timeout. The alternate solution
implemented in this patch consists on analyzing if the other streams different
from the one newly added (after the flush) aren't waiting (which would mean
that they've all been unlocked after all of them were waiting before), and,
in that case, mark the new stream as also not waiting.
A new test_stream_start_wait test case has been added to demonstrate this
problem. The test case creates a video stream, pushes a buffer, then
simulates a seek by pushing flush-start, flush-stop, stream-start and segment
events. Note that the flush-stop clears the video stream waiting flag.
After that, a new audio stream is created and stream-start and new segment
events are sent. Note that stream-start will set the audio stream to wait.
Then a buffer is pushed on each stream. In the failing case, the test hangs.
In the working case (after this fix), the test runs properly because the
fact of having seen a stream-start also helps to clear the wait flag.
A second new test_stream_start_wait_sparse test has also been added to prove
that this mechanism can also work with sparse streams (a special case of the
current stream-start handling code). This test behaves like the previous one,
but there's no video buffer after the seek (it'll come in the future, as the
stream is sparse, but actually never comes). The buffer after the seek in the
audio stream starts at its due time. Streamsynchronizer is able to ignore
the wait for the video stream and produce audio buffers on time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4544>
Similar to NV12_10LE40, this is a 422 variant. This format is also named
NV20 (20bit per pixels) in other stack and is produced by rkvdec
decoder.
Co-authored-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5612>
The 'new-pref' property sets the preference to use the new (next)
instead of the old (previous) buffer. The default is set to 0.5 to get
a similar behaviour as before the change.
Value 0.0 makes sure that only frames are shown where it's known that
the frame content is visible at that time, always show the old frame
until the new frame timestamp is reached.
Then, if the next buffer replaces the previous buffer the new buffer
is pushed as often as possible until PTS is reached. Before the new
buffer was only pushed once the new next buffer arrived.
Use GstClockTimeDiff because it's known that the current buffer time
is inside the time interval of previous buffer and next buffer the
calculation can be done with building absolute values. Special macros
are not needed here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
gst_video_time_code_to_date_time() simply calculated the date time based on
adding the hours/minutes/seconds to the daily jam. This causes a gap every full
minute (except for every 10th minute) with drop-frame timecodes as the first 2
(29.97fps) or 4 (59.94fps) timecodes are skipped (not frames!), e.g. with
29.97fps:
timecode: 12:00:59;28 12:00:59;29 12:01:00;02 12:01:00;03
time : 12:00:59.950 12:00:59.983 12:01:00.017 12:01:00.050
and not
time : 12:00:59.934 12:00:59.968 12:01:00.067 12:01:00.100
|-- gap of 2 frames --|
The correct calculation would be to use gst_video_time_code_nsec_since_daily_jam()
and add that to the daily jam.
Also add a test for this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8649>
Variable f1 is never used, so just skip that loop for now.
The test has never actually tested actual resampling because of
that bug it seems, and the test fails if fixed to actually resample.
For now we just avoid the pointless 126*12 pipelines that were just
testing the same thing (nothing) over and over again.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7827>
The typefind code was rejecting content smaller than 128 bytes making it
impossible to play files with very small srt files.
But those can actually be properly detected so fix typefind to allow
smaller content and try its best with it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6937>
