mirror of
https://gitlab.freedesktop.org/pipewire/pipewire
synced 2024-10-14 20:02:38 +00:00
doc: fix typos
Signed-off-by: Siwon Kang <siwon.kang@daimler.com>
This commit is contained in:
parent
e59c4675a7
commit
f7b22b934c
|
@ -44,7 +44,7 @@ Upon connecting to a server, it will broadcast its state. Clients
|
||||||
should listen for these state changes and cache them. There is no
|
should listen for these state changes and cache them. There is no
|
||||||
need (or mechanism) to query the state of the server.
|
need (or mechanism) to query the state of the server.
|
||||||
|
|
||||||
The server also have a registry object that, when listening to,
|
The server also has a registry object that, when listening to,
|
||||||
will broadcast the presence of global objects and any changes in
|
will broadcast the presence of global objects and any changes in
|
||||||
their state.
|
their state.
|
||||||
|
|
||||||
|
@ -129,7 +129,7 @@ life cycle management.
|
||||||
|
|
||||||
A proxy to a PipeWire registry object. It emits events about the
|
A proxy to a PipeWire registry object. It emits events about the
|
||||||
available objects on the server and can be used to bind to those
|
available objects on the server and can be used to bind to those
|
||||||
objects in order call methods or receive events from them.
|
objects in order to call methods or receive events from them.
|
||||||
|
|
||||||
### `struct pw_module`
|
### `struct pw_module`
|
||||||
|
|
||||||
|
@ -193,7 +193,7 @@ do the connection for the client and then hands the connection socket
|
||||||
to the client.
|
to the client.
|
||||||
|
|
||||||
All objects in PipeWire have per client permission bits, currently
|
All objects in PipeWire have per client permission bits, currently
|
||||||
READ, WRITE, EXECUTE and METADATA. A client can not see an objects
|
READ, WRITE, EXECUTE and METADATA. A client can not see an object
|
||||||
unless it has READ permissions. Similarly, a client can only execute
|
unless it has READ permissions. Similarly, a client can only execute
|
||||||
methods on an object when the EXECUTE bit is set and to modify the
|
methods on an object when the EXECUTE bit is set and to modify the
|
||||||
state of an object, the client needs WRITE permissions.
|
state of an object, the client needs WRITE permissions.
|
||||||
|
|
|
@ -20,7 +20,7 @@ The framework is used to build a modular daemon that can be configured to:
|
||||||
## Motivation
|
## Motivation
|
||||||
|
|
||||||
Linux has no unified framework for exchanging multimedia content between
|
Linux has no unified framework for exchanging multimedia content between
|
||||||
applications or even devices. Im most cases, developers realized that
|
applications or even devices. In most cases, developers realized that
|
||||||
a user-space daemon is needed to make this possible:
|
a user-space daemon is needed to make this possible:
|
||||||
|
|
||||||
* For video content, we typically rely on the compositor to render our
|
* For video content, we typically rely on the compositor to render our
|
||||||
|
@ -33,7 +33,7 @@ a user-space daemon is needed to make this possible:
|
||||||
|
|
||||||
None of these solutions (with perhaps to some extend Wayland), however,
|
None of these solutions (with perhaps to some extend Wayland), however,
|
||||||
were designed to support the security features that are required when
|
were designed to support the security features that are required when
|
||||||
daeling with flatpaks or other containerized applications. PipeWire
|
dealing with flatpaks or other containerized applications. PipeWire
|
||||||
aims to solve this problem and provides a unified framework to run both
|
aims to solve this problem and provides a unified framework to run both
|
||||||
consumer and Pro audio as well as video capture and processing in a
|
consumer and Pro audio as well as video capture and processing in a
|
||||||
secure way.
|
secure way.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
# PipeWire Tutorial
|
# PipeWire Tutorial
|
||||||
|
|
||||||
Welcome to the PipeWire tutorial. The goal is to learn to
|
Welcome to the PipeWire tutorial. The goal is to learn
|
||||||
PipeWire API step-by-step with simple short examples.
|
PipeWire API step-by-step with simple short examples.
|
||||||
|
|
||||||
1) Getting started ([tutorial 1](tutorial1.md)).
|
1) Getting started ([tutorial 1](tutorial1.md)).
|
||||||
|
|
|
@ -155,7 +155,7 @@ and a callback + data.
|
||||||
&data);
|
&data);
|
||||||
```
|
```
|
||||||
|
|
||||||
We using `pw_stream_new_simple()` but there is also a `pw_stream_new()` that
|
We are using `pw_stream_new_simple()` but there is also a `pw_stream_new()` that
|
||||||
takes an existing `struct pw_core` as the first argument and that requires you
|
takes an existing `struct pw_core` as the first argument and that requires you
|
||||||
to add the event handle manually, for more control. The `pw_stream_new_simple()`
|
to add the event handle manually, for more control. The `pw_stream_new_simple()`
|
||||||
is, as the name implies, easier to use because it creates a `struct pw_context`
|
is, as the name implies, easier to use because it creates a `struct pw_context`
|
||||||
|
@ -225,7 +225,7 @@ Now we're ready to connect the stream and run the main loop:
|
||||||
pw_main_loop_run(data.loop);
|
pw_main_loop_run(data.loop);
|
||||||
```
|
```
|
||||||
|
|
||||||
To connect we specify that we have an `PW_DIRECTION_OUTPUT` stream. `PW_ID_ANY`
|
To connect we specify that we have a `PW_DIRECTION_OUTPUT` stream. `PW_ID_ANY`
|
||||||
means that we are ok with conneting to any consumer. Next we set some flags:
|
means that we are ok with conneting to any consumer. Next we set some flags:
|
||||||
|
|
||||||
* `PW_STREAM_FLAG_AUTOCONNECT` automatically connect this stream. This instructs
|
* `PW_STREAM_FLAG_AUTOCONNECT` automatically connect this stream. This instructs
|
||||||
|
@ -242,7 +242,7 @@ And last we pass the extra parameters for our stream. Here we only have the
|
||||||
allowed formats (`SPA_PARAM_EnumFormat`).
|
allowed formats (`SPA_PARAM_EnumFormat`).
|
||||||
|
|
||||||
Running the mainloop will then start processing and will result in our
|
Running the mainloop will then start processing and will result in our
|
||||||
`process` callback to be called. Let have a look at that function now.
|
`process` callback to be called. Let's have a look at that function now.
|
||||||
|
|
||||||
The main program flow of the process function is:
|
The main program flow of the process function is:
|
||||||
|
|
||||||
|
|
|
@ -178,7 +178,7 @@ static const struct pw_stream_events stream_events = {
|
||||||
};
|
};
|
||||||
```
|
```
|
||||||
|
|
||||||
Because we are a capture stream and we can accept a wide range of different
|
Because we capture a stream of a wide range of different
|
||||||
video formats and resolutions, we have to describe our accepted formats in
|
video formats and resolutions, we have to describe our accepted formats in
|
||||||
a different way:
|
a different way:
|
||||||
|
|
||||||
|
@ -262,7 +262,7 @@ Now we're ready to connect the stream and run the main loop:
|
||||||
pw_main_loop_run(data.loop);
|
pw_main_loop_run(data.loop);
|
||||||
```
|
```
|
||||||
|
|
||||||
To connect we specify that we have an `PW_DIRECTION_INPUT` stream. `PW_ID_ANY`
|
To connect we specify that we have a `PW_DIRECTION_INPUT` stream. `PW_ID_ANY`
|
||||||
means that we are ok with connecting to any producer. We also allow the user
|
means that we are ok with connecting to any producer. We also allow the user
|
||||||
to pass an optional target id.
|
to pass an optional target id.
|
||||||
|
|
||||||
|
@ -280,7 +280,7 @@ negotiated between our stream and the camera. This is always something that
|
||||||
is compatible with what we enumerated in the EnumFormat param when we
|
is compatible with what we enumerated in the EnumFormat param when we
|
||||||
connected.
|
connected.
|
||||||
|
|
||||||
Let's take a look a how we can parse the format in the `param_changed`
|
Let's take a look at how we can parse the format in the `param_changed`
|
||||||
event:
|
event:
|
||||||
|
|
||||||
```c
|
```c
|
||||||
|
@ -296,7 +296,7 @@ First check if there is a param. A NULL param means that it is cleared. The id
|
||||||
of the param tells you what param it is. We are only interested in Format
|
of the param tells you what param it is. We are only interested in Format
|
||||||
param (`SPA_PARAM_Format`).
|
param (`SPA_PARAM_Format`).
|
||||||
|
|
||||||
We can parse the media type and subtype as follows and ensure that it is
|
We can parse the media type and subtype as below and ensure that it is
|
||||||
of the right type. In our example this will always be true but when your
|
of the right type. In our example this will always be true but when your
|
||||||
EnumFormat contains different media types or subtypes, this is how you can
|
EnumFormat contains different media types or subtypes, this is how you can
|
||||||
parse them:
|
parse them:
|
||||||
|
|
|
@ -173,7 +173,7 @@ We're also quitting the mainloop after we get the info to nicely stop
|
||||||
our tutorial application.
|
our tutorial application.
|
||||||
|
|
||||||
When we stop the application, don't forget to destroy all proxies that
|
When we stop the application, don't forget to destroy all proxies that
|
||||||
you created or they will be leaked:
|
you created. Otherwise, they will be leaked:
|
||||||
|
|
||||||
```c
|
```c
|
||||||
/* ... */
|
/* ... */
|
||||||
|
|
Loading…
Reference in a new issue