The complete handling on the control interface is currently dead.
We return with EOPNOTSUPP for the caller to know that a response
to such requests is not valid. The host however may ask
control interface why these control requests were not available.
For this the UVC_VC_REQUEST_ERROR_CODE_CONTROL is used. As an overall
exception for the control interface we just always return 0x06 as
an response which is representing "not implemented".
This patch is a necessary feature to properly pass the UVC Functionality
Test of the USB3CV Compliance Software.
Fixes: 69c17461392d ('uvcgadget: Properly implement GET_INFO control responses')
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7524>
For some third-party devices macOS sometimes reports silly framerates,
like 750003/6250 instead of 120/1. To avoid users having to exactly
pecify those values, we instead report the closest reasonable value in
caps. If it ends up being chosen, the additional logic in
setDeviceCaps() will reverse that process and pass the actual supported
value back to AVF, as most often the rounding causes us to fall just
outside the accepted threshold.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8745>
Depending on the system load the test 'video_capture_with_tags' may
fail or not. Reason is that 'videotestsrc' may emit a buffer before
the final caps negotiation on the recording pipeline has happened
after dynamic linking.
In that case there would be a caps change and because videorate does
no longer drop old buffers and caps on change but pushes duplicates if
required qtmux will notice a caps change and fail to link.
The problem is a synchronization problem in 'camerabin' which became
obvious with the changed behaviour of 'videorate'.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
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>
This happens on F42 with the JPEG decoders for some reason and trying to
actually use them with any resolution simply gives a "resolution not supported"
error.
A minimum of 64 is correctly reported though and trying to create caps with an
int range of [64, 0] gives critical warnings.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8736>
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>
