mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-11-02 09:01:50 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
pipewire/src/examples/meson.build

140 lines
4.2 KiB
Meson
Raw Normal View History

examples: add video upload example Add an example of a node that makes a video available. Improve buffer reuse in stream. Add more video formats
2017-04-18 17:57:04 +02:00
executable('video-src',
'video-src.c',
add _GNU_SOURCE as compiler flag
2019-01-08 17:35:36 +01:00
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
meta: add cursor metadata and examples Add a moving and flashing circle cursor to video-src Render the cursor in video-play Alsa add VideoCrop metadata
2018-11-30 11:07:45 +01:00
dependencies : [pipewire_dep, mathlib],
examples: add video upload example Add an example of a node that makes a video available. Improve buffer reuse in stream. Add more video formats
2017-04-18 17:57:04 +02:00
)
examples: add example of memfd upload Add an example of a client that allocates the buffer memory and uploads the fds to the server.
2019-08-12 16:54:05 +02:00
executable('video-src-alloc',
'video-src-alloc.c',
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
examples: add example of memfd upload Add an example of a client that allocates the buffer memory and uploads the fds to the server.
2019-08-12 16:54:05 +02:00
dependencies : [pipewire_dep, mathlib],
)
example: add example of renegotiation Add an example of renegotiating a producer and consumer format.
2020-06-19 12:17:47 +02:00
executable('video-src-reneg',
'video-src-reneg.c',
c_args : [ '-D_GNU_SOURCE' ],
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
dependencies : [pipewire_dep, mathlib],
)
examples: add example audio source
2018-03-14 11:24:23 +01:00
executable('audio-src',
'audio-src.c',
add _GNU_SOURCE as compiler flag
2019-01-08 17:35:36 +01:00
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
examples: add example audio source
2018-03-14 11:24:23 +01:00
dependencies : [pipewire_dep, mathlib],
)
examples: add audio DSP source
2020-06-03 12:06:44 +02:00
executable('audio-dsp-src',
'audio-dsp-src.c',
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
examples: add audio DSP source
2020-06-03 12:06:44 +02:00
dependencies : [pipewire_dep, mathlib],
)
Add example to play sine wave Various build fixes and cleanups Move port_add to private and make node ports based on implementation. Improve pull based scheduling on remote nodes
2017-09-07 10:22:32 +02:00
executable('export-source',
'export-source.c',
add _GNU_SOURCE as compiler flag
2019-01-08 17:35:36 +01:00
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
build: Use mathlib for the libm dependency object The libm variable is defined in `spa`, but the top-level meson.build defines mathlib.
2018-01-24 11:54:18 +00:00
dependencies : [pipewire_dep, mathlib],
Add example to play sine wave Various build fixes and cleanups Move port_add to private and make node ports based on implementation. Improve pull based scheduling on remote nodes
2017-09-07 10:22:32 +02:00
)
video-play: add example video capture + playback
2017-04-21 12:36:46 +02:00
filter: add filter API The filter API is meant for making generic audio and video filters. It's like a pw_stream but with many in/out ports and no conversion. Eventually the pw_stream will be implemented with the filter. Add some example audio and video filters.
2019-10-29 11:59:58 +01:00
executable('audio-dsp-filter',
'audio-dsp-filter.c',
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
filter: add filter API The filter API is meant for making generic audio and video filters. It's like a pw_stream but with many in/out ports and no conversion. Eventually the pw_stream will be implemented with the filter. Add some example audio and video filters.
2019-10-29 11:59:58 +01:00
dependencies : [pipewire_dep, mathlib],
)
Add more generic export-spa example Replace the v4l2 example with a more generic version that can add any spa node to a remote graph Make the dictionary items const Add some info to nodes and factories. Add the node info to the node properties. We can then set the media.class directly on the node, instead of letting the monitor set it. Debug node info in spa-inspect. Do async operation on the audiotestsrc and videotestsrc differently.
2017-09-07 19:55:22 +02:00
executable('export-spa',
'export-spa.c',
add _GNU_SOURCE as compiler flag
2019-01-08 17:35:36 +01:00
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
build: Use mathlib for the libm dependency object The libm variable is defined in `spa`, but the top-level meson.build defines mathlib.
2018-01-24 11:54:18 +00:00
dependencies : [pipewire_dep, mathlib],
Add more generic export-spa example Replace the v4l2 example with a more generic version that can add any spa node to a remote graph Make the dictionary items const Add some info to nodes and factories. Add the node info to the node properties. We can then set the media.class directly on the node, instead of letting the monitor set it. Debug node info in spa-inspect. Do async operation on the audiotestsrc and videotestsrc differently.
2017-09-07 19:55:22 +02:00
)
examples: add export-spa-device example
2019-05-28 14:06:01 +02:00
executable('export-spa-device',
'export-spa-device.c',
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
examples: add export-spa-device example
2019-05-28 14:06:01 +02:00
dependencies : [pipewire_dep, mathlib],
)
examples: don't fail when alsa is not found Avoid building the session-manager when alsa was not found.
2020-01-27 10:46:19 +01:00
if alsa_dep.found()
executable('pipewire-media-session',
media-session: add flatpak module Add a module that gives full access to flatpak apps. Later we should do something more restrictive.
2020-07-16 12:50:33 +02:00
'media-session/access-flatpak.c',
Move portal module to session manager
2020-07-16 17:54:18 +02:00
'media-session/access-portal.c',
examples: don't fail when alsa is not found Avoid building the session-manager when alsa was not found.
2020-01-27 10:46:19 +01:00
'media-session/alsa-midi.c',
'media-session/alsa-monitor.c',
'media-session/alsa-endpoint.c',
'media-session/bluez-monitor.c',
'media-session/bluez-endpoint.c',
'media-session/media-session.c',
'media-session/session-manager.c',
'media-session/metadata.c',
'media-session/stream-endpoint.c',
'media-session/policy-ep.c',
'media-session/policy-node.c',
'media-session/v4l2-monitor.c',
'media-session/v4l2-endpoint.c',
Integrating libcamera
2020-04-20 12:26:50 +05:30
'media-session/libcamera-monitor.c',
examples: don't fail when alsa is not found Avoid building the session-manager when alsa was not found.
2020-01-27 10:46:19 +01:00
'media-session/suspend-node.c',
c_args : [ '-D_GNU_SOURCE' ],
install: true,
dependencies : [dbus_dep, pipewire_dep, alsa_dep, mathlib],
add media session example beginnings Add an example media session that runs as a separate program instead of a module
2018-08-02 11:25:27 +02:00
)
examples: don't fail when alsa is not found Avoid building the session-manager when alsa was not found.
2020-01-27 10:46:19 +01:00
endif
add media session example beginnings Add an example media session that runs as a separate program instead of a module
2018-08-02 11:25:27 +02:00
example: add example external bluez devices Add an example for how to monitor devices, and make nodes that can be used to stream bluetooth out of the daemon process.
2019-05-30 16:12:34 +02:00
executable('bluez-session',
'bluez-session.c',
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
example: add example external bluez devices Add an example for how to monitor devices, and make nodes that can be used to stream bluetooth out of the daemon process.
2019-05-30 16:12:34 +02:00
dependencies : [pipewire_dep, mathlib],
)
build fixes
2017-07-04 11:38:12 +02:00
if sdl_dep.found()
executable('video-play',
'video-play.c',
add _GNU_SOURCE as compiler flag
2019-01-08 17:35:36 +01:00
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
video: add support for RGBA with 16 and 32 bit float
2019-08-19 16:22:12 +02:00
dependencies : [pipewire_dep, sdl_dep, mathlib],
Work on unifying client and server Remove context and extensions, make client API also use the core. Make a new pw_remote object that keeps connections with remote instances. Remove introspection API, it's just as easy to connect to the registry and get updates like that. Expand the protocol a little to make it useful for making listeners and connections. Move protocol specific connection to the module. Make some new convenience methods. Make a factory to create nodes from spa objects Add an example of a local pipeline displaying a v4l2 source.
2017-07-11 12:24:03 +02:00
)
example: add example of renegotiation Add an example of renegotiating a producer and consumer format.
2020-06-19 12:17:47 +02:00
executable('video-play-reneg',
'video-play-reneg.c',
c_args : [ '-D_GNU_SOURCE' ],
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
dependencies : [pipewire_dep, sdl_dep, mathlib],
)
filter: add filter API The filter API is meant for making generic audio and video filters. It's like a pw_stream but with many in/out ports and no conversion. Eventually the pw_stream will be implemented with the filter. Add some example audio and video filters.
2019-10-29 11:59:58 +01:00
executable('video-dsp-play',
'video-dsp-play.c',
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
filter: add filter API The filter API is meant for making generic audio and video filters. It's like a pw_stream but with many in/out ports and no conversion. Eventually the pw_stream will be implemented with the filter. Add some example audio and video filters.
2019-10-29 11:59:58 +01:00
dependencies : [pipewire_dep, sdl_dep, mathlib],
)
Work on unifying client and server Remove context and extensions, make client API also use the core. Make a new pw_remote object that keeps connections with remote instances. Remove introspection API, it's just as easy to connect to the registry and get updates like that. Expand the protocol a little to make it useful for making listeners and connections. Move protocol specific connection to the module. Make some new convenience methods. Make a factory to create nodes from spa objects Add an example of a local pipeline displaying a v4l2 source.
2017-07-11 12:24:03 +02:00
executable('local-v4l2',
'local-v4l2.c',
add _GNU_SOURCE as compiler flag
2019-01-08 17:35:36 +01:00
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
move things around
2017-07-11 15:57:20 +02:00
dependencies : [pipewire_dep, sdl_dep],
build fixes
2017-07-04 11:38:12 +02:00
)
Integrating libcamera
2020-04-20 12:26:50 +05:30
Use remote to join nodes on remote graphs Make a new method that can take a local node and run it in a remote pipeline. This basically replaces all functionality of the streams and more. Add 2 examples for exporting a sink and a v4l2 node Make some more things const Cleanups Make it possible to do things when the node needs scheduling. The default node will schedule the local pipeline but the remote node might also schedule the remote pipeline.
2017-07-25 19:52:31 +02:00
executable('export-sink',
'export-sink.c',
add _GNU_SOURCE as compiler flag
2019-01-08 17:35:36 +01:00
c_args : [ '-D_GNU_SOURCE' ],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : join_paths(installed_tests_execdir, 'examples'),
export-sink: change contrast property
2018-02-07 18:16:01 +01:00
dependencies : [pipewire_dep, sdl_dep, mathlib],
Use remote to join nodes on remote graphs Make a new method that can take a local node and run it in a remote pipeline. This basically replaces all functionality of the streams and more. Add 2 examples for exporting a sink and a v4l2 node Make some more things const Cleanups Make it possible to do things when the node needs scheduling. The default node will schedule the local pipeline but the remote node might also schedule the remote pipeline.
2017-07-25 19:52:31 +02:00
)
build fixes
2017-07-04 11:38:12 +02:00
endif
Reference in a new issue Copy permalink