mirror of
https://gitlab.freedesktop.org/pipewire/pipewire.git
synced 2025-10-31 22:25:38 -04:00
Multimedia processing graphs
082463efd0
For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node. |
||
|---|---|---|
| doc | ||
| man | ||
| pipewire-alsa@dddaaf4db4 | ||
| pipewire-jack@0bc34d5301 | ||
| pipewire-pulseaudio@694ae6dd84 | ||
| po | ||
| spa | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| _config.yml | ||
| autogen.sh | ||
| check_missing_headers.sh | ||
| config.h.meson | ||
| COPYING | ||
| LICENSE | ||
| Makefile.in | ||
| meson.build | ||
| meson_options.txt | ||
| NEWS | ||
| PROTOCOL | ||
| pw-uninstalled.sh | ||
| README | ||
PipeWire
--------
PipeWire is a server and user space API to deal with multimedia
pipelines. This includes:
- Making available sources of video (such as from a capture devices or
application provided streams) and multiplexing this with
clients.
- Accessing sources of video for consumption.
- Generating graphs for audio and video processing.
Nodes in the graph can be implemented as separate processes,
communicating with sockets and exchanging multimedia content using fd
passing.
Building
--------
Pipewire uses the Meson and Ninja build system to compile. If you're not
familiar with these tools, the included "autogen.sh" script will
automatically run the correct meson/ninja commands, and output a Makefile.
It follows that there are two methods to build Pipewire, however both rely
on Meson and Ninja to actually perform the compilation:
$ ./autogen.sh
$ make
or the Meson/Ninja native method:
$ meson build
$ cd build
$ ninja
You can see the available meson options in meson_options.txt file.