Preparations for Portals + PipeWire camera, part 2 #9103
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sorry, this is a painful commit to review :( Until now, the only consumer of the PipeWire code is the screen cast portal code. This portal code only ever has one PipeWire connection, and one PipeWire stream, every time a monitor or a window is selected. This is reflected on obs_pipewire, which only handles a single stream for any given connection. For cameras and audio, however, a single PipeWire connection can and most likely always will provide multiple streams. For example, computers with multiple webcams will have one PipeWire connection reporting multiple PipeWire nodes, one node for each camera. This commit breaks this one-stream-per-connection assumption, and makes obs_pipewire_connect_stream() return an independent object (obs_pipewire_stream) that represents a single stream. The screencast portal code continues to only ever have one connection and one stream.
Make obs_pipewire hold a list of streams created by itself, and destroy these streams when closing the connection.
So far we've been treating format info on a per-connection basis, but now that a single connection is capable of hosting multiple streams, and each stream might negotiate a different format, it is necessary to move format info to each stream individually.
And use it instead of exhaustively open coding each field of the anonymous struct into the arguments of the lookup function.
The media API requires it's own format (enum video_format) and bytes per pixel (bpp).
We'll need to peek information about the source to determine how to process frames, so store it for later usage.
GeorgesStavracas
added
Enhancement
Cameras and audio streams will use the async output routines, but not screencasting. This needs to be handled differently in the processing callback. As it is, the code is starting to get a bit messy, as we're now dealing with two different frame processing approaches. Later on, this code will be cleaned up and split in more logical pieces. Co-authored-by: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
The D-Bus signal subscription is a very boring aspect of the portals infrastructure that shouldn't really matter when reading the code of pipewire.c. Move it out to its natural place, portal.c.
GeorgesStavracas
force-pushed
the
gbsneto/pipewire-unified-wrappers-part2
branch
from
8013f88
to
88f686a
Compare
|
Ubuntu 22.04 No regression noticed as of latest commit. |
This is a workaround to the compiler complaining about directive arguments being null.
GeorgesStavracas
force-pushed
the
gbsneto/pipewire-unified-wrappers-part2
branch
from
88f686a
to
f8d2594
Compare
|
Would you like me to start working on a version of #6207 that uses the wrappers? |
Eventually, but I don't think it's worth investing that time on this iteration of the wrappers. I think it'll be worth for you to rebase on top of a (future) part 3 of the PipeWire cleanups, but I'm still working on it. |
|
Let's go \o/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is the second batch of commits from #6669, rebased on top of
masterand adjusted to the most recent changes.The biggest change that this round of preparations introduce is making the PipeWire code able to handle async sources. There are no actual async sources that use PipeWire, but this is such a big change that I reasoned it's better reviewed independently from the next - and even bigger - reworks.
There should be no functional changes to the screencapture code.
Motivation and Context
I don't want code reviewers crying in a corner when reviewing the PipeWire camera merge request, so let's go incremental and chop choppy and handle this massive amount of code in digestible chunks 馃檪
How Has This Been Tested?
Types of changes
Checklist: