Closes #22

The code assumed that openh264enc is always available and would fail
horribly if it was not. Make this slightly more explicit by logging an
error and quitting earlier.

Seems like we never reported back the quirks. This means we ended up
trying to force a keyframe even though the pipeline does not support it.
This is not a big deal, in the end it just results in a different debug
output.

We need to strip the stream ID for gstreamer to understand the
play/pause requests. The logic was horribly broken, but happened to work
in the way that it always stripped.

Fix a compile time warning by implementing the logic correctly.

The code was just not using the correct cleanup function for the type.

To configure the encoder we are currently attaching data to it.
Attaching the data happened on the surrounding bin though, which meant
that it couldn't be configured correctly later on.

Fix this by ensuring we set the encoder on the correct element.

When the reported codec support was set to the highest possible setting,
then we would fall through to warn that the setting is unsupported.

Simply add the relevant break to fix this.

It seems that there are users out there who have the XDG portals installed,
but no support for screencasting in mutter. Apparently, we receive
errors from the portal in that case, which resulted in us giving up
right away rather than trying a fallback.

Obviously these users should fix their setup and compile mutter with
pipewire support (so that screencasting is available). But we can try to
handle it better and simply fall back to X11 rather than erroring out
without any further feedback.

Also improve the error reporting a bit, so that we can see where exactly
the error came from in the future.

Fixes: #17

Usually the defaults are good enough for us. The exception is that we
may get routes through DHCP if the remote peer becomes the group owner.
We really don't want to set default routes for the P2P connection.

Set the appropriate flags in the IPvX configuration to avoid this from
happening. Also explicitly allow IPv6 configuration to fail.

Fixes: #16

This mostly address issue #1. The missing screenshot requires hosting
though, and is not added at this point.

Fixes #6

The vaapi h264 encoder seems to crash in that case, so we need to
disable the support for IDR refresh frames then.

Interlaced formats are not supported by vaapi and likely not useful
anyway.

Update the x264enc parameters, many of these may not be required, but
these parameters seem to work fine.

Without this the x264enc encoder will output a high profile with 4:4:4
color format. This is not permitted by miracast.

The x264enc encoder starts at 1000 hours of streaming time, this needs
to be handled in the QOS calculation.

This simply updates the API usage to the latest NetworkManager version.

Fixes #8

The switch was missing a break and would go into the disconnected state
rather than error state when an error occured. Fix this so that we end
up in the error state and the user needs to explicitly "stop" the error
stream before being able to re-start it.

The signal is emitted on the device, not the client.

There are pending API changes for the P2P related methods and classes.
This update works with the latest changes that are pending to be merged.

The constructor of the provider would always start the find operation.
That may not be necessary, so change it to only start the find when
discovery is enabled.

Without this discovery wouldn't be running properly after application
startup.

The openh264 codec sometimes needs a lot of time for a frame. As the
latency does not seem to be auto-adjusted, set it to 500ms explicitly.

500ms seems to work fine, it could be that less is also good enough, but
while high it is probably still alright.

Sometimes the encoder may not run in real-time. In particular the
openh264 encoder element will start having a lot of buffer in the queue
rather than dropping input buffers.

Generate QOS events if buffers start coming in late, to force the codec
to drop frames and ensure playback is smooth (without audio dropping
out).

Also adjust some default options, including limitting the video bitrate
so that the wifi link is not over-saturated.

We may not get any new frames from the shell for long periods if nothing
on the screen changes. So effectively disable the timeout and keep
sending the previous frame indefinately.