Created bmd_option type that is basically a variant (tagged union) to
encapsulate possible configuration values and also special values for
default and keep. Having this previously in int is cumbersome because
the special values as were defined (0, -1) collide with the default
semantics of bool.
It actually sets `profile=1dfd`. This is a complement to already
existing `half-duplex` option (that has on the other hand more more
complex semantic - it chooses the profile tailored for the device, since
the right one differs for eg. 8K Pro /4dhd/ and Duo/Quad 2 /2dhd/).
Although most of remaining (non-FourCC) constants is small (counting
from zero), there are some, like bmdDynamicRangeHDRStaticHLG, which is
defined as 1<<30. Reading small hex values is ok but big decimal not.
Part of the BMD constants are FourCCs, which are however impossible to read
if presented in decimal (hexadecimal would help a bit but not much).
As a solution detect if the value is a FourCC and if so, print ASCII
representation of it.
Also the commit message was incorrect - if single device is specified,
request either separate 3D tiles or the merged buffer (this is the new
DISPLAY_PROPERTY_VIDEO_SEPARATE_3D mode).
When profiles switching is required, it may be the important part so it
may be useful to print info which profile is active or being activated
even if there is no fail.
BMD Extreme 4K doesn't support profiles so do not warn (only in verbose)
if setting failed, provided that the profile was not selected
explicitly and query was E_NOINTERFACE.
merge pred prechozi komit a uprav
Added a mode SEPARATE_3D that is somehow inbetween MERGED and
SEPARATE_TILES - if receiving only 2 streams, 2 separated 3D streams are
expected, otherwise merged framebuffer is used.
Set 1-subdevice-full-duplex for 3D mode as it seems to be the only
supported (1 device half-duplex would work as well but it doesn't seem
to support 2 streams while full-duplex supports at least 2 streams in
the opposite direction, at least for 8K Pro).
using bound checking variants
Remained last one instance in utils/text.c, that does the checking by
itself and vsnprintf compat using vsprintf, that is not used, anyways.
Use shared handling of should_exit events how uv does it. Without that,
video_rxtx registering the should_exit callback for video_rxtx freezes
because noone is taking over.
Command to reproduce fixed behavior
$ hd-rum-transcode 8M 5004
[messaging] Warning: infinite wait for module without msg notifier. Please report!
Simplified relevant stacktrace:
- send_message_sync <-- freezes
- register_should_exit_callback
- video_rxtx::start
- video_rxtx::create
- hd_rum_decompress_init
see GH-307
The management of should_exit events should be also be shared with the
transcoding reflector that uses some parts that may depend upon this
functionality.
This is not purely a refactorization but slightly changes behavior,
namely the shared state cleanup is done in a destructor, not by
`uv.stop()` as it used to be.
see GH-307
The returned value was actually incorrect (counting also formatting
escape sequences and terminating nul byte).
Since the return value should not be important for the caller, it is
perhaps better not to complicate and don't return anything.
fixes warnings with Xcode 14.3 as in previous commit
+ allocate +1 in Log_output buffer - snprintf(MULL, 0...) returns number
of bytes without terminating '\0'. std::string storage isn't guaranteed
to be NULL-terminated (std::string("").at(0) throws an exception). The
buffer is somewhere preallocated 256 which prevents problem but it's
better not to rely upon it.
+ comment out some unused function in LDGM that also triggered the
warning but looked a bit suspicious so it was not clear how to fix
If color-space change is notified, the bit depth is not always the part
of the flags, so use a different value, to which 8-bit is implicitly
added in that case to suppress confusing: "Detected 12-bit signal, use
":codec=UYVY" to enforce 8-bit capture (old behavior)." message in such
a case.
If display mode was changed, reconfigure display; if color-space,
reconfigure only color space.
This prevents unneeded reconfiguration when eg. color space is detected
first and then display mode + CS.
This fixes the commit d6523202 that replaced incorrectly the Darwin
vesion numbers by the same but 10.<darwin>, which is not correct because
they don't match, eg. OS X Lion 10.7 has Darvin OS version 9. Also <=
was replaced by ifndef, which effectively needs version +1, so
original OS_VERSION_MAJOR<=11 (Lion 10.7) needed to be rewritten "ifndef
__MAC_10_8".
Note that since the affected macOS versions are very old, this was only
a minor issue (UG wouldn't be perhaps even possible to compile there).
