| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Odd heights, while generally handled by Gstreamer, can cause issues in
various places - most importantly hardware video en-/decoders and
GL/VK drivers - as in most cases 2x0 or 2x2 subsampled intermediate
pixel formats are used (such as I420, YUYV, NV12 etc.).
Thus ensure we always end up with an even height.
|
|
Most used widths can be devided by 4*3 as well as 16*9, resulting in
heights being multiples of two. There are two exceptions, though:
360 (/16*9=202.5) and 400 (/16*9=225).
Odd heights, while generally handled by Gstreamer, can cause issues in
various places - most importantly hardware video en-/decoders and
GL/VK drivers - as in most cases 2x0 or 2x2 subsampled intermediate
pixel formats are used (such as I420, YUYV, NV12 etc.).
Thus tweak the widths in question so they can be cleanly devided 16*9
and 4*3 with even results, as these are the most common ratios for
cameras.
|
|
Sources not capable of negotiating framerates, most notably the
libcamera Pipewire plugin, might still be able to honor a value
requested and otherwise usually just ignore it.
Thus setting a value that we can reasonably assume to be supported has
several benefits:
1. It potentially prevents the source from producing much higher fps than
useful for the usecase, causing resource waste.
2. It decreases the chances of running into fallback code paths which
are often badly optimized performance-wise. One example is that
currently the implicitly set framerate values cause regular
renegotiations (including buffer re-allocations) in pipewiresrc.
Another is the internal get_target_bitrate(), currently returning
uint.MAX.
3. If the source can only produce e.g. 15 fps, that's usually handled
without major issues.
Thus follow the example of Snapshot, which has been doing this for a
while and gets more testing with libcamera, and set framerate to 30/1.
|
|
Most cameras needing the fallback path are provided by libcamera,
which does not yet provide framerates. At the same time many such
cameras support very high resolutions - often in the 4K category -
and are paired with rather weak CPUs. Examples for this are popular
mobile phones such as the PinePhone Pro or the OnePlus6.
In order to archive a somewhat stable FPS count in such scenarios,
target a resolution of 720p as a compromise of quality and
performance.
|
|
An increasing number of video device providers, such as `pipewiresrc`
(in the upcoming 1.6 release) and `v4l2src` (since Gst 1.26), support
`memory:DMABuf` caps using the special `DMA_DRM` caps. This is not
expected and handled properly, thus filter out any non-default features.
|
|
This includes #1679 and works around an upstream bug in pipewire causing #1685
|
|
|
|
When the algorithm iterates over all the available v4l2 capabilities it tries to determine the best framerate for each one of YUYV (video/x-raw) modes presented by the hardware (best_fraction, line 357 in device.vala). Regardless of what's determined to be the "best" YUYV mode from within the conditional right after (line 385) the best fractional framerate will always point to the last iterated framerate, which might be an extremely low one, like 7 or 5 FPS. When the framerate is then stored in the Gst.Structure (line 394) the fractional framerate will always be that last value which might be different than the correct one as calculated by best_fps (line 386). This workaround solves this issue by only updating best_fraction when the conditional in line 385 is satisfied.
from issue #1195
|
|
before call started
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
