When the stream resolution change it is needed to negotiate
a new pools and to update the caps.
Resolution change could occurs on a new sequence or a new
picture so move resolution change detection code in a common
function.
For memory allocation reasons, only allows resolution change
on non keyframe if the driver support remove buffer feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
We must drain the pending output picture so that subclass can renegotiate
the caps. Not doing so while still renegotiating would mean that the
subclass would have to do an allocation query before pushing the caps.
Pushing the caps now without this would also not work since these caps
won't match the pending buffers format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
Add helpers function to call VIDIOC_REMOVE_BUFS ioctl.
If the driver support this feature buffers are removed from the queue when:
- the pool when is detached from the decoded.
- the pool is released.
- allocation failed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
Use VIDIOC_CREATE_BUFS ioctl to create buffers instead of VIDIOC_REQBUFS
because it allows to create buffers also while streaming.
To prepare the introduction of VIDIOC_REMOVE_BUFFERS create
the buffers one per one instead of a range of them. This way
it can, in the futur, fill the holes.
gst_v4l2_decoder_request_buffers() is stil used to remove all
the buffers of the queue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
When a datachannel within a session is removed after proper close,
reference to the error_ignore_bin elements of the datachannel
appsrc/appsink were left in webrtcbin.
This caused the bin-objects to be left and not freed until the whole
webrtc session was terminated. Among other things that includes a thread
from the appsrc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7675>
We want to ensure the stream-collection is present on the pad (as a sticky
event) before we expose the pad.
This is more reliable since it will ensure it is present before any other event
is pushed through.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7609>
- Add mtd_meta_clear to allow specific analytics-meta to handle their clear
operation specific to their type.
- Clear mtd's attached when analytic-meta is freed. When the buffer where
analytics-meta is attached is not from a buffer pool
gst_analytics_relation_meta_clear will not be called unless we explicitly call
it in _free. This important otherwise _mtd_clear are not called and lead to
leak if embedded mtd's allocated memory
- Un-ref in transform if it's a copy
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6026>
FLUSH_STOP is meant to clear the flushing state of pads and elements
downstream, not to process data. Hence, a FLUSH_STOP should not
propagate sticky events. This is also consistent with how flushes are a
special case for probes.
Currently this is almost always the case, since a FLUSH_STOP is
__usually__ preceded by a FLUSH_START, and events (sticky or not) are
discarded while a pad has the FLUSHING flag active (set by FLUSH_START).
However, it is currently assumed that a FLUSH_STOP not preceded by a
FLUSH_START is correct behavior, and this will occur while autoplugging
pipelines are constructed. This leaves us with an unhandled edge case!
This patch explicitly disables sending sticky events when pushing a
FLUSH_STOP, instead of relying on the flushing flag of the pad, which
will break in the edge case of a FLUSH_STOP not preceded by a
FLUSH_START.
If sticky events are propagated in response to a FLUSH_STOP, the
flushing thread can end up deadlocked in blocking code of a downstream
pad, such as a blocking probe. Instead, those events should be
propagated from the streaming thread of the pad when handling a
non-flushing synchronized event or buffer.
This fixes a deadlock found in WebKit with playbin3 when seeks occur
before preroll, where the seeking thread ended up stuck in the blocking
probe of playsink:
https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1367
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7632>
H.266 NAL unit header syntax [1] is similar to H.265 NAL unit header syntax[2]:
```
H.265 H.266
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| NALType | LayerId | TID | |F|U| LayerId | NALType | TID |
+-------------+-----------+-----+ +-------------+-----------------+
Where
* F: `forbidden_zero_bit`: f(1)
* U: `nuh_reserved_zero_bit`: u(1) only H.266
* LayerId: `nuh_layer_id`: u(6)
* NALType: `nal_unit_type`: u(6) in H.265 and u(5) in H.266
* TID: `nuh_temporal_id_plus1`: u(3)
```
NAL unit types have different values:
| NALType | H.265 | H.266 |
|----------|------------------------------------|---------------------------|
| VPS | HEVC_NAL_VPS(32) | VVC_VPS_NUT(14) |
| SPS | HEVC_NAL_SPS(33) | VVC_SPS_NUT(15) |
| PPS | HEVC_NAL_PPS(34) | VVC_PPS_NUT(16) |
| IRAP | BLA_W_LP(19)..HEVC_NAL_CRA_NUT(21) | IDR_W_RADL(7)..CRA_NUT(9) |
Implementation of `h266_video_type_find` is based on `h265_video_type_find` with
next differences:
- NAL unit header syntax for H.265 and H.266
- Diff NAL unit types values
- Avoid checking nuh_layer_id is zero. H.266 conformance test suite[3] contains examples with more than one layer.
This typefind was tested with H.266 conformance test suite [3]. Also, with the help of fluster[4],
with H.264 and H.265 conformance test suites to avoid regresions. Pending test vectors to fix:
- 8b422_H_Sony_4
- DEBLOCKING_E_Ericsson_3
[1] https://www.itu.int/rec/T-REC-H.266
[2] https://www.itu.int/rec/T-REC-H.265
[3] https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft6/
[4] https://github.com/fluendo/fluster/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7339>
I wanted to check if an element had the SINK flag and realized it was
not displayed in gst-inspect.
The clock flags were already reported as part of the "clocking
capabilities" info but best to have them explicitly listed here as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7641>
