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.

Most o the mentioned issues have been fixed and audio is also supported
if a supported encoder is found.

We currently only support the AAC codec (when an encoder is available).
It should be easy to support LPCM in theory, in practice the MPEGTS
muxer element does not support packing the raw audio data currently
though.

The metaprovider was unref'ing all providers that match the newly added
sink. This was simply a wrong initialization of the pointer array.

In WFD almost all rates default to 48kHz. So, to avoid re-sampling, set
the rate on the sink to 48kHz.

For now this adds a ScreencastPulseaudio class which creates a
gnome_screencast NULL sink and allows gettign a pipewire source for the
monitor source.

The NULL sink is currently not destroyed on shutdown, however, we do
make sure to only ever create one of them.

Many devices can request IDR frames if they need them. In that case, we
don't need to insert as many IDR frames into the stream, so increase the
GOP size for the encoder.

This means we do not assume it is an IDR request anymore.

Just force max_slice_num to 1 in that case.

The wrong table was used for the length.

This changes a few parameters. The only change in here that actually
fixes things in this case is forcing the slice count to be 1. There is
actually another underlying bug (will be fixed in following commits)
that caused a too high slice count to be set.

However, it doesn't hurt much to be on the safe side.

We can do better, but relying on the native resolution doesn't really
work, and picking the highest resolution is also wrong.

If we actually decode the EDID, then we could pick the best resolution
that works for the monitor in question.

This is a basic implementation to inject IDR frames. Note that it
currently assumes that any SET_PARAMS request is actually an IDR
request.

If the casting source asks for an IDR frame, then replying with an error
is a bad idea. Instead, just always return OK.

With this gnome-screencast will fall back to trying to use a simple
ximagesrc rather than the portal if the portal API is missing.

The WFD sink did not store the source ID and both sinks did not detect
an attachment failure correctly.

It is not a good idea to continously run the P2P find operation as it
requires changing channels on the card and could have major impacts on
wifi performance. So turn discovery off as soon as the sink list is not
visible.

Querying the SDP has no use and is not even possible at that point in
the process.

The default is not to suspend the pipeline. However, as we are
live-streaming, there is no point in letting the pipeline run, just
reset it.

Some of the getters return references, others don't. Fix the various
cases so we don't leak any objects.

This simplifies the interlacer a bit and decouples everything before the
encoder to run in a separate thread.

Unfortunately, it seems that sometimes the pipeline stays alive when
cancelling.