Advertise conversion to HW-accelerated codecs (eg. HW_VDPAU, RPI4_8)
only if probe (which now works in the same way as regular init since
HEAD^) would initialize to an accelerated codec.
This would prevent situations, when eg. `--param use-hw-accel=vaapi -d
gl` is used, in which case HW_VDPAU was selected as a display codec,
although not intended.
We want rather mimic the actual initialization in the probe.
Also avoid errors like:
````
[lavc hevc @ 0x7f4b0c002700] A hardware frames or device context is required for hardware accelerated decoding.
[lavc hevc @ 0x7f4b0c002700] Failed setup for format vdpau: hwaccel initialisation returned error.
````
Currently, if probing, hw acceleration is skipped, but this will change
so this is done in preparation to this.
Also print in verbose mode now (it is now more useful to debug).
Previously, if '--param use-hw-accel' was specified but the hw
acceleration was not compiled-in, unknown parameter was reported.
This is not entirely acurate and can be a little misleading, rather
print that the support is not enabled directly.
With current zfec code, fec_init() needs to be called prior to fec_new(),
otherwise the later one returns NULL.
\+ updated submodule to the current zfec version (requiring fec_init();
but UG will compile with the older zfec version as well)
Warn in the same way as when non-4:2:0 video is encoded - intra refresh
might be problematic as well.
Do not warn if enabled explicitly (`:intra_refresh`).
getchar() must not be used to read a character when there are more than
one at once because otherwise won't next select() return and the key
will remain in the stdio buffer.
Fixed:
``
(sleep 2; printf '\x18M'; sleep 50 ) | ./build/bin/uv -s testcard -r alsa --param disable-keyboard-control=no
```
when the 'M' key was not processed immediately but just at the end of
the process.
In addition to already existing "mute", that toggled mutte for the
receiver, [un]mute-{sender,receiver} was added, which mutes or unmutes
the sender or receiver.
Split the common part out into its own section. Now all pipewire stuff
(audio cap/play, video cap/disp, screen_pw) can be disabled all together
with --disable-pipewire
the check is perhaps unneeded - restoring twice won't hurt
More importantly, it didn't restore the TIO when sequence restore_tio()
-> set_tio() is called repeatedly. Concretely, entering interactive cmds:
1. Ctrl-X - unlock control
2. 'c' - one-time command mode
3. 'help<cr>' -
4. 'c' - one-time command mode
5. 'help<cr>' -
the second "help" was not echoed, because restore_tio() was called before
3, but second run of the function was not run. Moreover, after 5, the saved TIO
will be perhaps replaced by the curend one by set_tio().
