This is for the case where there answerer forces a specific media type
for a m-line, but he origin offer only has the other media type. In this
case, we will create a second transceiver on receiving the offer and add
the desired media type using renegotiation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2104>
First fail the offer creation if the mid of an existing offer doesn't
match a forced m-mline.
Then, for all newly added mlines, first look for a transceiver that
forces this m-line, then add a "floating" one, then the data channel.
And repeat this until we're out of transceivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2104>
The simple case where this breaks is if you add a
datachannel and want to add a new pad (a new media) after). Another
case where this is broken is if the order of the media is forced to
something different by the peer.
It's more simple to just split both things completely. In practice, the
pads will be named in the order in which they are allocated, so it
shouldn't change the current behaviour, just enable new ones.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2104>
The path caps describe the input caps that will select each path, don't
intersect those with the srcpad caps, which could be completely
different. Instead, when querying allowed caps for the srcpad, just
construct the union of all possible output caps from all path srcpads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2018>
When handling a caps query on the src pad, don't return the union
of input caps. Even when not active, a path element can be queried
for srcpad template caps, or for dropping paths the allowed downstream
caps is anything - as data will be dropped anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2018>
The default implementation was required when superframe parsing
was handled by vp9decoder. For instance, if a superframe consists
of multiple frames with show_existing_frame header, it was vague
that which GstVp9Picture should consume GstVideoCodecFrame.
After 1.18 release, we introduced vp9parse element and
superframe should be handled by upstream vp9parse elemenet now.
So, we don't need to care about the superframe at vp9decoder class
level anymore. Simply, a frame corresponding to show_existing_frame
can be dropped if subclass doesn't implement duplicate_picture().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2151>
DMABuf allocator already implements DMABuf Sync, meaning that doing
mmap/munmap (unless the mode have changed) is not required. In fact, on
systems with IOMMU it makes the kernel redo the mmu table which is visible
in the CPU usage.
This change reduces CPU usage when decoding
bbb_sunflower_2160p_60fps_normal.mp4 on RK3399 SoC from over 30% to
around 15%.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2152>
Implementation of mem_copy() virtual method for GstVaAllocator.
It's a deep copy where a new VA memory is popped out from the pool or,
if pool is empty, a new memory is allocated. The original memory is
mapped to read, and if its VAImage is not derived and size to copy is
the whole surface, the mapped VAImage of the original memory is put in
the new memory. Otherwise a slow memcpy is done between both memories.
Fixes: #1568
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2136>
Existing VP9 parser implementation doesn't provide information
required by other stateless decoding APIs (i.e., DXVA and NVDEC),
specifically loop filter and segmentation parameters might not exist
current frame. So parser needs to fill the information by using previously
parsed information.
We can update the gstvp9parser implementation so that it can provide
all information required by stateless decoding APIs with a huge API break,
or adding more ugly struct in it.
Instead doing as such, this commit introduce a new VP9 parser implementation.
What is different from existing one?
* All variables will follow the specification as much as possible:
VP9 Bitstream & Decoding Process Specification - v0.6 31st March 2016
* Parser will fill all the required information for decoding frame
to GstVp9FrameHeader struct. In case of old VP9 parser,
user needs to read additional data from parser's member variables.
* GstVp9StatefulParser object struct is completely completely opaque
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2112>
The picture buffer (V4L2 CAPTURE buffer) was being released immediatly
when the request was done. This was problematic since even after the
request is done, the picture buffer might still be used as a reference
and should not be reused for further decoding yet.
This change effectively bind the picture buffer lifetime to the request.
So that if the picture is never showned (decode only frame) or the request
queue is full before the buffer is displayed, the picture buffer will
remain alive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2142>
Different VA drives might have different definitions for RGB32 color
formats because different bit interpretation. Sadly the specification
doesn't clarify these interpretations. So VA users have to figure out
what's the correct mapping with it's rendering color format
definition.
This patch aims to fix the static map structure after the
VAImageFormats are queried. There is another static map with the
different interpretations of the RGB32 formats, and compare them with
the given VAImageFormat, then with the GStreamer color format, update
the mapping table.
Finally, some RGB32 color formats were added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2129>
