| 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.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add a field in `Xmpp.Xep.ExternalServiceDiscovery` to keep track
of the `expires` TURN service value and use it (divided by 2) to
restart periodically the external services discovery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Most Certificate Authorities don't support issuing X.509 certificates for onion
sites. However, it can still be useful to provide a certificate over Tor in
some circumstances, for instance to tie your alphanumeric Tor address to your
site's main identity.
Therefore, many Tor services provide self-signed certificates. This is OK,
since the onion service itself guarantees that you are connecting to the entity
you think you are.
Dino already allows self-signed certs when communicating over Tor (see
81a5505). However, the same exception does not exist yet for HTTP uploads and
downloads - causing these to fail over Tor.
Therefore, in this commit, we add the same exception for uploads/downloads, by
passing the host of the upload/download urls to the already existing invalid
certificate connection handler.
Note that this handler only allows certificates with type
TlsCertificateFlags.UNKNOWN_CA. This means the certificate of your server must
also include the onion http upload and download URLs in its certificate -
otherwise, the file transfer will fail with TlsCertificateFlags.BAD_IDENTITY.
|
