There were two problems with frame copy:
1. The input video info are from the format color, not form the allocated VA
surface, it's needed to update the sink video info according with the
allocator's data.
2. The parameters of `gst_video_frame_copy()` were backwards.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2007>
transform_size() basetransform vmethod is used when there's no output buffer
pool and allocates a system memory buffer. With VA this cannot be allowed, since
it needs VASurfaces to process.
Thus transform_size() is not required, but to play safe let's return FALSE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2007>
* Don't mention explicitly that API is MT safe, this implies that
other API is not. GStreamer API is assumed to be MT safe, thread
safety should only be explicitly mentioned when API is *not* MT safe
* Don't repeat what annotations are stating with respect to ownership
transfer, nullability
* Document enumeration members in standalone comments, so that their
Since tag is accounted for by gobject-introspection
* Misc cleanup / typo fixes / addition of links
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/748>
* Don't mention explicitly that API is MT safe, this implies that
other API is not. GStreamer API is assumed to be MT safe, thread
safety should only be explicitly mentioned when API is *not* MT safe
* Don't repeat what annotations are stating with respect to ownership
transfer, nullability
* Document virtual methods in standalone comments, so that parameters
can be documented. This is not critical here, as parameters do not
need annotations / specific documentation, but serves as an up to
date example
* Document enumeration members in standalone comments, so that their
Since tag is accounted for by gobject-introspection
* Misc cleanup / typo fixes / addition of links
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/747>
We should query the downstream element to answer a precise allocation
query when the passthrough mode is enabled.
The current way still decides the allocation by the postproc itself. The
pipeline such as:
gst-launch-1.0 -v filesrc location=xxx.264 ! h264parse ! vaapih264dec ! \
vaapipostproc ! fakevideosink silent=false sync=true
will lose some info such as the GST_VIDEO_META_API_TYPE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/413>
Unlike other stateless decoder implementations (e.g., VA),
our DPB pool cannot be grown since we are using
texture array (pre-allocated, fixed-size d3d11 texture pool).
So, if there's no more available texture to use,
there's no way other than copying it to downstream's
d3d11 buffer pool. Otherwise deadlock will happen.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2003>
In listener mode, gst_stats() returns an independent set of
statistics for every connected caller. Having the caller's IP and port
present in each structure allows to correlate the statistics with a
particular caller that has been announced by "caller-added" signal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1772>
Using RTP header extensions is currently not convenient. Users have to
handle signals from the RTP payloader and instantiate the extension
element themselves, making it impossible to use with gst-launch.
Adding a property allowing the payloader to automatically try creating
extensions. This should help simple use cases and testing using
gst-launch.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1022>
It's purely for informative reasons. `du` will fail on the sources dir
if a branch name has unicode in it due to an MSYS/MinGW bug. The long
term fix is to from MSYS/MinGW to MSYS/MinGW-W64 or MSYS2/MinGW-W64.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-ci/-/merge_requests/395>
Currently the send_func() runs in a thread of its own which is started
the first time we enter handle_new_sample(). It runs in an outer loop
until priv->continue_sending is FALSE, which happens when a TEARDOWN
request is received. We use a local variable, cont, which is initialized
to TRUE, meaning that we will always enter the outer loop, and at the
end of the outer loop we assign it the value of priv->continue_sending.
Within the outer loop there is an inner loop, where we wait to be
signaled when there is more data to send. The inner loop is exited when
priv->send_cookie has changed value, which it does when more data is
available or when a TEARDOWN has been received.
But if we get a TEARDOWN before send_func() is entered we will get stuck
in the inner loop because no one will increase priv->session_cookie
anymore.
By not entering the outer loop in send_func() if priv->continue_sending
is FALSE we make sure that we do not get stuck in send_func()'s inner
loop should we receive a TEARDOWN before the send thread has started.
Change-Id: I7338a0ea60ea435bb685f875965f5165839afa20
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/187>
If there are 3 or more known atoms in a row, it's likely that this is
actually MOV/MP4 even if we don't find any other known atoms. If 5 or
more are found then this is most certainly MOV/MP4 and we can return.
Also if a moov and mdat atom is found, this is definitely a MOV/MP4 file
and can be used as such, independent of anything else following the
mdat.
Fixes typefinding of various MOV files that have no `ftyp` atom but
otherwise a valid file structure followed by some garbage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1013>
