| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Uses work by @hrxi in https://github.com/dino/dino/pull/1515
Co-Authored-By: hrxi <hrrrxi@gmail.com>
|
|
These warnings arecompiler annoyances where the vala compiler creates C code
that is usually unexpected in proper C code and thus triggers warnings.
|
|
It's all in libdino now anyway
|
|
|
|
- Incoming signatures are stored in the database and processed when needed
(to send PGP encrypted messages or to display them in the contact details)
- Outgoing signatures are stored in the database and cached until the key is
changed
|
|
|
|
The callbacks aren't used by libomemo-c. The callbacks passed appear to
be buggy because the return value of `gcry_md_read` is passed to `free`,
but it is supposed to be automatically freed on `gcry_md_reset`.
Additionally, `gcry_md_reset` is called before the return value of
`gcry_md_read` is used, which is also against the documentation:
https://www.gnupg.org/documentation/manuals/gcrypt-devel/Working-with-hash-algorithms.html
> `gcry_md_read` returns the message digest after finalizing the
> calculation. […] The returned message digest is allocated within the
> message context and therefore valid until the handle is released or
> reseted (using `gcry_md_close` or `gcry_md_reset`. […]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Fixes #1728
|
|
|
|
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.
|
|
|
|
related #1714
|
|
Make relevant plugins enabled by default (instead of auto-enabling them if
dependencies are met). Also make disabled plugins explicit in the summary.
|
|
|
|
|
|
|
|
|
|
This includes #1679 and works around an upstream bug in pipewire causing #1685
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This ensures we are never in an uninitialized state when processing audio data
|
|
|
|
|
|
|
|
|
|
|
|
|
