CBR isn't really ready yet; it requires low-delay mode, which limits
SVT-AV1 to three cores and also is pretty bad for quality in general.
(Also, its CBR isn't really CBR yet; see SVT-AV1 bug 1959.)
Anything less seemingly triggers a bug in the ALSA PulseAudio
plugin when used against PipeWire (audio just never starts playing).
It would be nice to generally have less latency here, but with the
current design based on large resampling queues, this isn't going
to be what causes it.
This was mostly so that people could sharpen the input if they wanted to
(even though unsharp mask is not the best sharpener). BlurEffect was added
mainly because it felt wrong that one could only use a compound effect and not
the underlying one.
This is probably unused; it is so expensive to send uncompressed data
across sockets, and it was made at a time where it was envisioned
that we do most of our encoding externally.
It's unlikely that a user would want 10-bit input but not 10-bit-output,
or the other way around. Having only one flag simplifies things for the
user (although not much in the code, as we're already fp16 internally
anyway).
Remove the web_security flag for newer CEF, since it is no longer available (https://bitbucket.org/chromiumembedded/cef/issues/3058/remove-cefbrowsersettingsweb_security).
This is for if you want just a monitor output without synchronizing
your entire stream chain to the output card (ie., you want to keep
some other camera as the master). Sound support is untested, and is
probably going to crackle a fair bit.
There's no GUI support for changing this currently.
This is useful for machines that don't have Quick Sync,
but where you want to have an archival copy on disk
in higher quality than what you streamed out.
This is useful primarily if you want Kaeru to rewrap the stream into
Metacube (for cubemap) and do nothing else with it. Only H.264
is supported for now, since everything else assumes that.
Currently, we only really support --http-mux=mpegts; other muxes seem
to have issues.
This is seemingly especially important when we have input format autodetect
and PAL input rates; it gives us one 59.97 fps frame, then a delay as the
card autodetects and resyncs (might be as much as 30–50 ms; not entirely sure),
and then a steady stream of 50 fps frames. This then causes us to overestimate
the jitter by a lot until we get more than 1000 frames and can reject that
very first event as the outlier it is.
Newer CEF hard-codes that icudtl.dat _must_ be in the same directory
as libcef.so, but the release tarballs have a different structure,
so this fails. This should be fine on installs, but it won't work
for running Nageru from the build directory. Search for the library
in the local directory instead, where we have a symlink. This makes
the build rpath point to ., which makes sure icudtl.dat is picked up
from the other symlink.
This is more relevant now that having multiple SRT cameras can lead to
decoding lots of videos at the same time. It would be possible to support
other mechanisms (e.g. VDPAU) in FFmpeg depending on what FFmpeg is
built against, but it's a bit cumbersome to do, so this is VA-API only for now.
When hot-unplugging capture cards, actually allow making them inactive.
This was an oversight; removed cards would always be replaced by fake ones.
However, this exposed a few tricky issues, like that the master card can
go away, that needed to be dealt with.
5 fps is pretty crappy, but evidently, 100 ms happens with SRT cards
all the time even when nothing is wrong. Perhaps a situation with
B-frames at 30 fps? I haven't really checked.
This is both useful for discoveirng the feature, and also should you be
on a hostile network where suddenly someone connects to you when you
don't want to. Existing connections will remain just fine.
This is a cleanup that should really have been done when we added
hotplug in the first place, but it's becoming even more relevant
now that SRT “cards” are supported.
Basically, empty slots can now be filled with nothing instead of
fake capture cards (which generate frames and take a little bit
of CPU time); we only instantiate fake capture cards if the slot is
below some certain minimum index or has been used by the theme.
(Cards that are unused are now “inactive” and will generally not
show up in the UI.) This means that the --num-cards parameter is now
largely irrelevant; it is only there for guaranteeing a minimum
amount of fake cards, for testing. Most users will be happy just using the
default of 2. There's also a new --max-num-cards in the unlikely case
that you want to leave some cards unused, e.g. for other applications
on the same machine.
This also unifies handling of regular capture cards, FFmpeg “cards”
and CEF “cards”; they are indexed pretty much the same way.
We initialized VA-API and enumerated configs etc. in three different
ways for H.264 encoding (Nageru), MJPEG encoding (Nageru) and MJPEG
decoding (Futatabi). Unify them into one shared function, to reduce
the amount of duplication.
This enables MJPEG encoding for video sources, but in practice,
only SRT cameras are enabled. There's VA-API support for 4:2:0 only,
by means of converting to NV12; if you had 4:2:2 or 4:4:4, you will
get fallback to libjpeg, which should handle that gracefully.
(If I actually had an SRT source doing 4:2:2, I might have added
more support, but it seems pretty narrow.)
Futatabi seemingly has some problems handling these files, but that
should be fixable.
projects / nageru / log