| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
