my fork of dino with basic QoL changes, not very maintained https://git.bwaaa.space/dino-but-good/atom?h=master 2026-10-23T14:59:59Z 2026-10-23T14:59:59Z Marvin W git@larma.de 2026-10-04T12:42:16Z urn:sha1:dba577f39c489b9db29960f2bf5cc78ac4f29d7b 2026-10-23T14:59:59Z Marvin W git@larma.de 2026-10-03T14:05:51Z urn:sha1:2413442905e31f34cb0f77c9167003b3725760fe 2025-11-15T14:55:43Z Robert Mader robert.mader@collabora.com 2025-10-12T18:54:18Z urn:sha1:afcc2f4037bcb7b63c04ce12600ccfd360e75719 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. 2025-11-15T14:55:43Z Robert Mader robert.mader@collabora.com 2025-10-12T21:26:40Z urn:sha1:bdb7e39ab5077de6ea21eb3925b8ae6ffa0f5009 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. 2025-10-06T19:23:44Z Robert Mader robert.mader@collabora.com 2025-09-19T09:54:33Z urn:sha1:a8bcc14ce47032df3c5baf25af18c4005567e663 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. 2025-10-06T19:23:22Z Robert Mader robert.mader@collabora.com 2025-07-20T03:32:12Z urn:sha1:518b40f3af7090405ec5ab141feeecf42183aa8a 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. 2025-10-06T19:22:58Z Robert Mader robert.mader@collabora.com 2025-07-20T01:50:45Z urn:sha1:e801d44b8472bf72ac04ed1c8faf6bd856f25def 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. 2025-05-23T21:08:28Z Jacques Comeaux jacquesrcomeaux@protonmail.com 2025-04-19T17:44:15Z urn:sha1:715b874801201390eb5ffe440acc4af171a9ddaa 2025-04-09T18:05:13Z Marvin W git@larma.de 2025-04-09T18:02:55Z urn:sha1:50eeb2f16dfa4342d50086404da068f5426cbe3c This includes #1679 and works around an upstream bug in pipewire causing #1685 2025-04-08T10:15:12Z fiaxh git@lightrise.org 2025-04-08T10:15:12Z urn:sha1:a21800860e00d4078fa2b339bc16087ea1f22bbc