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.

The g_object_set calls were setting 64bit integers but passing 32bit
integers, causing issues. Also, the intervideosink would drop buffers
which were late by 20ms, causing most buffers to be dropped straight
away.

This fixes the VESA table lookup and also crashes if a resolution is not
available.

If the user does not have a mutter with remote desktop enabled, then it
may be viable to use an X11 image source instead. This is a compile time
option only though, as we generally want to rely on the remote desktop
protocol and possibly portal in the future.

Adding this makes it possible to try on machines that don't have support
in mutter (e.g. ubuntu).

This makes it easier to test using e.g. VLC or totem.

This puts everything into one pipeline while still using the
intervideosink/intervideosrc.

With this one can testing streaming to e.g. VLC to check how well that
works.

The correct status enum state was not returned and the stream_sink
routine should return a reference to itself.

Othwerise free'ed memory might be accessed.

GByteArray needs to be freed using the g_byte_array_unref method which
also frees the segment when used in g_clear_pointer.

This enables detection for x264enc and switches to uses that when
available.