This is recommended by various specifications for such framerates, while
for integer framerates we continue using centiframes to allow for some
more accuracy.
Using N means that no rounding error accumulates, eventually leading to
outputting a packet with a different duration.
Some tools such as MediaInfo determine that a stream is variable
framerate if any packet has a different duration than the others, and
there is no reason I can see for not using the full 4 bytes of
resolution that the mp4 timescale offers.
Example problematic pipeline:
```
videotestsrc num-buffers=5001 ! video/x-raw,framerate=60000/1001,width=320,height=240 ! \
videoconvert ! x264enc bitrate=80000 speed-preset=1 tune=zerolatency ! h264parse ! \
video/x-h264,profile=high-10 ! mp4mux ! filesink location="result2.mp4"
```
This results in a media file that MediaInfo detects as variable
framerate because the 5000th packet has duration 99 instead of 100.
With this patch, the timescale is 60000 and all packets have duration
1001.
Related issue for context: https://bugzilla.gnome.org/show_bug.cgi?id=769041
Co-authored-by: Sebastian Dröge <sebastian@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3683>
gst_element_add_pad() is supposed to activate the pad if the element
state is >= PAUSED and the pad is not already active.
Unfortunately, before this patch, the activation was performed while the
element lock was still taken, which ended causing a deadlock in
gst_pad_start_task() as it attempted to post `stream-status` message in
the element, which also requires the element lock.
Elements could work around this bug by activating the pad manually
before adding it to the element.
This patch fixes the problem by performing pad activation only after the
element lock has been released.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3651>
The latency messages are non-deterministic and can arrive before/after
async-done or during state-changes as they are posted by e.g. sinks from
their streaming thread but bins are finishing asynchronous state changes
from a secondary helper thread.
To solve this, expect latency messages at any time and assert that we
receive one at some point during the test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3647>
The VAAPI vaQueryVideoProcPipelineCaps() requires the context as the
parameter. So far, we always pass VA_INVALID_ID and it can succeed.
But the API does not say that and in theory, a valid context is required.
Now the new platform really needs a valid context and so we have to
delay that query until the context is created.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3620>
If a discontinuity is detected in push mode, we need to clear the cached section
observations since they might have potentially changed.
This was only done properly when operating with TIME segments (dvb, udp,
adaptive demuxers, ...) but not with BYTE segments (such as with custom app/fd
sources).
We still don't want to flush out the PCR observations, since this might be
needed for seeking in push-based BYTE sources.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1650
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3600>
If the SETUP request returns an IPv6 server address in the Transport
field, we would generate an incorrect URI, and multiudpsink would fail
to initialize:
```
rtspsrc gstrtspsrc.c:9780:dump_key_value:<source> key: 'Transport', value: 'RTP/AVP;unicast;source=fe80::dc27:25ff:fe5e:bd13:8080;client_port=62696-62697;server_port=4000-4001'
...
rtspsrc gstrtspsrc.c:4595:gst_rtspsrc_stream_configure_udp_sinks:<source> configure RTP UDP sink for fe80::dc27:25ff:fe5e:bd13:8080:4000
...
multiudpsink gstmultiudpsink.c:1229:gst_multiudpsink_configure_client:<udpsink0> error: Invalid address family (got 23)
```
We can't look at stream->is_ipv6 because we can't rely on the server
returning the right value there. In the issue reported about this,
server reported itself as `KuP RTSP Server/0.1`, and the SDP was:
```
c=IN IP4
m=video 54608 RTP/AVP 96
a=rtpmap:96 H264/90000
```
So we need to parse the string value and figure out the family
ourselves.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1058
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3596>
If the driver does not support VIDIOC_CREATE_BUFS ioctl, the pool
configuration may get changed, which requires a validation. This would
fail to activate a pool in a case it shouldn't normally fail unless we
are out of memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2677>
... when rendering on external HWND. ShowWindow() will cause
synchronous message passing to window thread and then can be blocked.
At the same time, window thread can wait for GStreamer thread.
Instead of the synchronous call, queue the task to window message
and performs from the window thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3588>
Deadlock sequence:
* From a streaming thread, d3d11videosink sends synchronous message
to the parent window, so that internal (child) window can be
constructed on the parent window's thread
* App thread (parent window thread) is waiting for pipeline's
state change (to GST_STATE_NULL) but streaming thread is
blocked and waiting for app thread
To avoid the deadlock, GstD3D11WindowWin32 should send message
to the parent window asynchronously.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3573>
The rtpjitterbuffer test drop_messages_interval uses a GstClockTime for
the message drop interval. This property is defined as a guint. On
systems with 64-bit time_t but 32-bit uint, this can cause the
g_object_set function to fail to read the arguments properly.
Fixes: #1656
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3582>
