jp9000
/
obs-studio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
obs-studio/libobs/obs-source.h

516 lines
15 KiB
C
Raw Normal View History

first commit
2013-09-30 19:37:13 -07:00
/******************************************************************************
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
Copyright (C) 2013-2014 by Hugh Bailey <obs.jim@gmail.com>
first commit
2013-09-30 19:37:13 -07:00
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
With the permission of my fellow contributors, I'm switching obs-studio back to GPL v2+ to prevent issues between this project and the original OBS project, and for personal reasons to avoid legal ambiguity (not political reasons, I admittedly would prefer GPL v3+)
2013-12-02 21:24:38 -08:00
the Free Software Foundation, either version 2 of the License, or
first commit
2013-09-30 19:37:13 -07:00
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
******************************************************************************/
modernize header guards to #pragma once
2013-10-14 04:21:15 -07:00
#pragma once
first commit
2013-09-30 19:37:13 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
#include "obs.h"
Some documentation improvements in obs-source.h
2014-10-12 10:54:49 -07:00
/**
* @file
* @brief header for modules implementing sources.
*
* Sources are modules that either feed data to libobs or modify it.
*/
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
#ifdef __cplusplus
extern "C" {
#endif
Move enum obs_source_type to obs-source.h
2014-02-12 11:57:51 -08:00
enum obs_source_type {
OBS_SOURCE_TYPE_INPUT,
OBS_SOURCE_TYPE_FILTER,
OBS_SOURCE_TYPE_TRANSITION,
libobs: Add source type OBS_SOURCE_TYPE_SCENE Helps identify a scene without having to compare its type name to "scene".
2015-12-29 15:48:45 -08:00
OBS_SOURCE_TYPE_SCENE,
Move enum obs_source_type to obs-source.h
2014-02-12 11:57:51 -08:00
};
UI: Implement stereo balancing
2017-10-08 03:15:28 -07:00
enum obs_balance_type {
OBS_BALANCE_TYPE_SINE_LAW,
OBS_BALANCE_TYPE_SQUARE_LAW,
OBS_BALANCE_TYPE_LINEAR,
};
Fix drawing bug with async video sources Before, async video sources would flicker because they were only being drawn when they were updated. So when updated, they'd draw that frame, then it would stop drawing it until it updated again. This fixes that issue and they should now draw properly. Also, fix a few other minor bugs and issues relating to async video, and make it so that non-async video filters can be properly applied to them. For the purposes of testing, change the 'test-random' source to an async video source that updates every quarter of a second with a new random face. Also fix a bug where non-async video sources wouldn't have filter effects applied properly.
2014-04-13 02:22:28 -07:00
UI: Add source icons
2019-07-27 21:59:16 -07:00
enum obs_icon_type {
OBS_ICON_TYPE_UNKNOWN,
OBS_ICON_TYPE_IMAGE,
OBS_ICON_TYPE_COLOR,
OBS_ICON_TYPE_SLIDESHOW,
OBS_ICON_TYPE_AUDIO_INPUT,
OBS_ICON_TYPE_AUDIO_OUTPUT,
OBS_ICON_TYPE_DESKTOP_CAPTURE,
OBS_ICON_TYPE_WINDOW_CAPTURE,
OBS_ICON_TYPE_GAME_CAPTURE,
OBS_ICON_TYPE_CAMERA,
OBS_ICON_TYPE_TEXT,
OBS_ICON_TYPE_MEDIA,
OBS_ICON_TYPE_BROWSER,
OBS_ICON_TYPE_CUSTOM,
};
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* @name Source output flags
first commit
2013-09-30 19:37:13 -07:00
*
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* These flags determine what type of data the source outputs and expects.
* @{
*/
/**
* Source has video.
first commit
2013-09-30 19:37:13 -07:00
*
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* Unless SOURCE_ASYNC_VIDEO is specified, the source must include the
* video_render callback in the source definition structure.
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_VIDEO (1 << 0)
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Source has audio.
first commit
2013-09-30 19:37:13 -07:00
*
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* Use the obs_source_output_audio function to pass raw audio data, which will
* be automatically converted and uploaded. If used with SOURCE_ASYNC_VIDEO,
* audio will automatically be synced up to the video output.
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_AUDIO (1 << 1)
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
Fix drawing bug with async video sources Before, async video sources would flicker because they were only being drawn when they were updated. So when updated, they'd draw that frame, then it would stop drawing it until it updated again. This fixes that issue and they should now draw properly. Also, fix a few other minor bugs and issues relating to async video, and make it so that non-async video filters can be properly applied to them. For the purposes of testing, change the 'test-random' source to an async video source that updates every quarter of a second with a new random face. Also fix a bug where non-async video sources wouldn't have filter effects applied properly.
2014-04-13 02:22:28 -07:00
/** Async video flag (use OBS_SOURCE_ASYNC_VIDEO) */
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_ASYNC (1 << 2)
Fix drawing bug with async video sources Before, async video sources would flicker because they were only being drawn when they were updated. So when updated, they'd draw that frame, then it would stop drawing it until it updated again. This fixes that issue and they should now draw properly. Also, fix a few other minor bugs and issues relating to async video, and make it so that non-async video filters can be properly applied to them. For the purposes of testing, change the 'test-random' source to an async video source that updates every quarter of a second with a new random face. Also fix a bug where non-async video sources wouldn't have filter effects applied properly.
2014-04-13 02:22:28 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Source passes raw video data via RAM.
first commit
2013-09-30 19:37:13 -07:00
*
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* Use the obs_source_output_video function to pass raw video data, which will
* be automatically uploaded at the specified timestamp.
first commit
2013-09-30 19:37:13 -07:00
*
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* If this flag is specified, it is not necessary to include the video_render
* callback. However, if you wish to use that function as well, you must call
* obs_source_getframe to get the current frame data, and
* obs_source_releaseframe to release the data when complete.
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_ASYNC_VIDEO (OBS_SOURCE_ASYNC | OBS_SOURCE_VIDEO)
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Source uses custom drawing, rather than a default effect.
first commit
2013-09-30 19:37:13 -07:00
*
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* If this flag is specified, the video_render callback will pass a NULL
* effect, and effect-based filters will not use direct rendering.
first commit
2013-09-30 19:37:13 -07:00
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_CUSTOM_DRAW (1 << 3)
first commit
2013-09-30 19:37:13 -07:00
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
/**
* Source supports interaction.
Some documentation improvements in obs-source.h
2014-10-12 10:54:49 -07:00
*
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
* When this is used, the source will receive interaction events
* if they provide the necessary callbacks in the source definition structure.
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_INTERACTION (1 << 5)
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
libobs: Implement composite sources (skip) (Note: This commit breaks libobs compilation. Skip if bisecting) Adds a "composite" source type which is used for sources that composite one or more sub-sources. The audio_render callback is called for composite sources to allow those types of sources to do custom processing of the audio of its sub-sources.
2015-12-17 06:46:10 -08:00
/**
* Source composites sub-sources
*
* When used specifies that the source composites one or more sub-sources.
* Sources that render sub-sources must implement the audio_render callback
* in order to perform custom mixing of sub-sources.
*
* This capability flag is always set for transitions.
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_COMPOSITE (1 << 6)
libobs: Implement composite sources (skip) (Note: This commit breaks libobs compilation. Skip if bisecting) Adds a "composite" source type which is used for sources that composite one or more sub-sources. The audio_render callback is called for composite sources to allow those types of sources to do custom processing of the audio of its sub-sources.
2015-12-17 06:46:10 -08:00
libobs: Add source output flag OBS_SOURCE_DO_NOT_DUPLICATE Certain types of sources (display captures, game captures, audio device captures, video device captures) should not be duplicated. This capability flag hints that the source prefers references over full duplication.
2016-01-12 16:25:47 -08:00
/**
* Source should not be fully duplicated
*
* When this is used, specifies that the source should not be fully duplicated,
* and should prefer to duplicate via holding references rather than full
* duplication.
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_DO_NOT_DUPLICATE (1 << 7)
libobs: Add source output flag OBS_SOURCE_DO_NOT_DUPLICATE Certain types of sources (display captures, game captures, audio device captures, video device captures) should not be duplicated. This capability flag hints that the source prefers references over full duplication.
2016-01-12 16:25:47 -08:00
libobs: Add source capability flag for deprecation
2016-09-14 16:27:45 -07:00
/**
* Source is deprecated and should not be used
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_DEPRECATED (1 << 8)
libobs: Add source capability flag for deprecation
2016-09-14 16:27:45 -07:00
libobs: Implement audio monitoring Adds functions to turn on audio monitoring to allow the user to hear playback of an audio source over the user's speaker. It can be set to turn off monitoring and only output to stream, or it can be set to output only to monitoring, or it can be set to both. On windows, audio monitoring uses WASAPI. Windows also is capable of syncing the audio to the video according to when the video frame itself was played. On mac, it uses AudioQueue. On linux, it's not currently implemented and won't do anything (to be implemented).
2017-02-05 21:37:35 -08:00
/**
* Source cannot have its audio monitored
*
audio-monitoring: Add ability to monitor Outputs (Note: This commits also modifies the linux-pulseaudio, mac-capture, and win-wasapi plugins) Do not prevent the targeted output device from being monitored if the selected monitor output device is a different one. Closes jp9000/obs-studio#872
2017-04-04 16:14:11 -07:00
* Specifies that this source may cause a feedback loop if audio is monitored
* with a device selected as desktop audio.
*
libobs: Implement audio monitoring Adds functions to turn on audio monitoring to allow the user to hear playback of an audio source over the user's speaker. It can be set to turn off monitoring and only output to stream, or it can be set to output only to monitoring, or it can be set to both. On windows, audio monitoring uses WASAPI. Windows also is capable of syncing the audio to the video according to when the video frame itself was played. On mac, it uses AudioQueue. On linux, it's not currently implemented and won't do anything (to be implemented).
2017-02-05 21:37:35 -08:00
* This is used primarily with desktop audio capture sources.
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_DO_NOT_SELF_MONITOR (1 << 9)
libobs: Implement audio monitoring Adds functions to turn on audio monitoring to allow the user to hear playback of an audio source over the user's speaker. It can be set to turn off monitoring and only output to stream, or it can be set to output only to monitoring, or it can be set to both. On windows, audio monitoring uses WASAPI. Windows also is capable of syncing the audio to the video according to when the video frame itself was played. On mac, it uses AudioQueue. On linux, it's not currently implemented and won't do anything (to be implemented).
2017-02-05 21:37:35 -08:00
libobs: Add ability to disable source types Because it would be troublesome to add the ability to remove source types (in case for example a script fails to reload), instead make it so source types can be temporarily disabled while the program is running.
2017-12-25 12:20:54 -08:00
/**
* Source type is currently disabled and should not be shown to the user
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_SOURCE_CAP_DISABLED (1 << 10)
libobs: Add ability to disable source types Because it would be troublesome to add the ability to remove source types (in case for example a script fails to reload), instead make it so source types can be temporarily disabled while the program is running.
2017-12-25 12:20:54 -08:00
libobs: Add the ability to make sources obsolete This allows the ability to do things such as change defaults or properties of sources without necessarily breaking older user configurations that had older defaults or properties.
2020-01-15 01:47:53 -08:00
/**
* Source type is obsolete (has been updated with new defaults/properties/etc)
*/
#define OBS_SOURCE_CAP_OBSOLETE OBS_SOURCE_CAP_DISABLED
libobs: Add "monitoring by default" source cap (This also modifies the UI module) Adds the ability for a source to monitor by default. This is mainly aimed at browser sources, so that they do not stop outputting audio by default like they used to.
2019-07-26 00:02:31 -07:00
/**
* Source should enable monitoring by default. Monitoring should be set by the
* frontend if this flag is set.
*/
#define OBS_SOURCE_MONITOR_BY_DEFAULT (1 << 11)
libobs: Add audio lines Adds the "audio_line" internal source type as a bare source type for the sole purpose of outputting audio, and the obs_source_info::audio_mix callback which allows mixing of those audio lines, which is then treated as normal audio for the source. Audio line objects should be added as sub-sources when multiple audio lines from a single source are needed, then mixed together with the audio_mix callback. The difference between the new obs_source_info::audio_mix callback and obs_source_info::audio_render is that obs_source_info::audio_mix (along with the audio_line source) are only one track, and it outputs audio to the source automatically via obs_source_output_audio() when the call completes. This allows the mixed audio to be treated like a normal source's audio, in that you can filter it, change its volume, or monitor it. This change was necessary because the CEF (used with the browser source) outputs multiple audio streams at once to a single browser source, so it's the program's responsibility to mix those streams together itself.
2019-08-21 14:35:40 -07:00
/** Used internally for audio submixing */
#define OBS_SOURCE_SUBMIX (1 << 12)
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/** @} */
first commit
2013-09-30 19:37:13 -07:00
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
typedef void (*obs_source_enum_proc_t)(obs_source_t *parent,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
obs_source_t *child, void *param);
Add functions to enumerate source children/tree
2014-02-20 16:44:42 -08:00
libobs: Store circular audio buffer on source itself (skip) (Note: This commit breaks libobs compilation. Skip if bisecting) Removes audio lines and stores the circular buffer for the audio on the source itself.
2015-12-17 04:28:35 -08:00
struct obs_source_audio_mix {
struct audio_output_data output[MAX_AUDIO_MIXES];
};
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Source definition structure
*/
struct obs_source_info {
first commit
2013-09-30 19:37:13 -07:00
/* ----------------------------------------------------------------- */
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/* Required implementation*/
first commit
2013-09-30 19:37:13 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/** Unique string identifier for the source */
const char *id;
/**
* Type of source.
*
Make some admends to obs-source.h documentation
2014-02-12 07:38:49 -08:00
* OBS_SOURCE_TYPE_INPUT for input sources,
* OBS_SOURCE_TYPE_FILTER for filter sources, and
* OBS_SOURCE_TYPE_TRANSITION for transition sources.
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
*/
enum obs_source_type type;
/** Source output flags */
uint32_t output_flags;
/**
* Get the translated name of the source type
*
(API Change) libobs: Pass type data to get_name callbacks API changed from: obs_source_info::get_name(void) obs_output_info::get_name(void) obs_encoder_info::get_name(void) obs_service_info::get_name(void) API changed to: obs_source_info::get_name(void *type_data) obs_output_info::get_name(void *type_data) obs_encoder_info::get_name(void *type_data) obs_service_info::get_name(void *type_data) This allows the type data to be used when getting the name of the object (useful for plugin wrappers primarily). NOTE: Though a parameter was added, this is backward-compatible with older plugins due to calling convention. The new parameter will simply be ignored by older plugins, and the stack (if used) will be cleaned up by the caller.
2015-09-16 01:30:51 -07:00
* @param type_data The type_data variable of this structure
* @return The translated name of the source type
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
*/
(API Change) libobs: Pass type data to get_name callbacks API changed from: obs_source_info::get_name(void) obs_output_info::get_name(void) obs_encoder_info::get_name(void) obs_service_info::get_name(void) API changed to: obs_source_info::get_name(void *type_data) obs_output_info::get_name(void *type_data) obs_encoder_info::get_name(void *type_data) obs_service_info::get_name(void *type_data) This allows the type data to be used when getting the name of the object (useful for plugin wrappers primarily). NOTE: Though a parameter was added, this is backward-compatible with older plugins due to calling convention. The new parameter will simply be ignored by older plugins, and the stack (if used) will be cleaned up by the caller.
2015-09-16 01:30:51 -07:00
const char *(*get_name)(void *type_data);
added support for jansson, added new output files, made some adjustments to the API, fixed a UI subclass issue
2013-11-13 05:24:20 -08:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Creates the source data for the source
*
* @param settings Settings to initialize the source with
Fix various typos across multiple modules
2017-03-19 04:35:51 -07:00
* @param source Source that this data is associated with
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* @return The data associated with this source
*/
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
void *(*create)(obs_data_t *settings, obs_source_t *source);
first commit
2013-09-30 19:37:13 -07:00
Fix an issue with async (video) source destruction obs_source_output_video can cause cached frames to be freed twice if called with a partially destroyed source, among other undesirable effects; freeing the source private data right after the destroy signal has been processed ensures proper behavior
2014-05-04 12:01:46 -07:00
/**
* Destroys the private data for the source
*
* Async sources must not call obs_source_output_video after returning
* from destroy
*/
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
void (*destroy)(void *data);
first commit
2013-09-30 19:37:13 -07:00
Fix drawing bug with async video sources Before, async video sources would flicker because they were only being drawn when they were updated. So when updated, they'd draw that frame, then it would stop drawing it until it updated again. This fixes that issue and they should now draw properly. Also, fix a few other minor bugs and issues relating to async video, and make it so that non-async video filters can be properly applied to them. For the purposes of testing, change the 'test-random' source to an async video source that updates every quarter of a second with a new random face. Also fix a bug where non-async video sources wouldn't have filter effects applied properly.
2014-04-13 02:22:28 -07:00
/** Returns the width of the source. Required if this is an input
* source and has non-async video */
(API Change) Unsquish libobs API callback names Renamed: To: ------------------------------------------------------- obs_source_info::getname obs_source_info::get_name obs_source_info::getwidth obs_source_info::get_width obs_source_info::getheight obs_source_info::get_height obs_output_info::getname obs_output_info::get_name obs_encoder_info::getname obs_encoder_info::get_name obs_service_info::getname obs_service_info::get_name
2014-08-04 14:38:26 -07:00
uint32_t (*get_width)(void *data);
Add source properties window (very preliminary) - Add a properties window for sources so that you can now actually edit the settings for sources. Also, display the source by itself in the window (Note: not working on mac, and possibly not working on linux). When changing the settings for a source, it will call obs_source_update on that source when you have modified any values automatically. - Add a properties 'widget', eventually I want to turn this in to a regular nice properties view like you'd see in the designer, but right now it just uses a form layout in a QScrollArea with regular controls to display the properties. It's clunky but works for the time being. - Make it so that swap chains and the main graphics subsystem will automatically use at least one backbuffer if none was specified - Fix bug where displays weren't added to the main display array - Make it so that you can get the properties of a source via the actual pointer of a source/encoder/output in addition to being able to look up properties via identifier. - When registering source types, check for required functions (wasn't doing it before). getheight/getwidth should not be optional if it's a video source as well. - Add an RAII OBSObj wrapper to obs.hpp for non-reference-counted libobs pointers - Add an RAII OBSSignal wrapper to obs.hpp for libobs signals to automatically disconnect them on destruction - Move the "scale and center" calculation in window-basic-main.cpp to its own function and in its own source file - Add an 'update' callback to WASAPI audio sources
2014-03-23 01:07:54 -07:00
Fix drawing bug with async video sources Before, async video sources would flicker because they were only being drawn when they were updated. So when updated, they'd draw that frame, then it would stop drawing it until it updated again. This fixes that issue and they should now draw properly. Also, fix a few other minor bugs and issues relating to async video, and make it so that non-async video filters can be properly applied to them. For the purposes of testing, change the 'test-random' source to an async video source that updates every quarter of a second with a new random face. Also fix a bug where non-async video sources wouldn't have filter effects applied properly.
2014-04-13 02:22:28 -07:00
/** Returns the height of the source. Required if this is an input
* source and has non-async video */
(API Change) Unsquish libobs API callback names Renamed: To: ------------------------------------------------------- obs_source_info::getname obs_source_info::get_name obs_source_info::getwidth obs_source_info::get_width obs_source_info::getheight obs_source_info::get_height obs_output_info::getname obs_output_info::get_name obs_encoder_info::getname obs_encoder_info::get_name obs_service_info::getname obs_service_info::get_name
2014-08-04 14:38:26 -07:00
uint32_t (*get_height)(void *data);
Add source properties window (very preliminary) - Add a properties window for sources so that you can now actually edit the settings for sources. Also, display the source by itself in the window (Note: not working on mac, and possibly not working on linux). When changing the settings for a source, it will call obs_source_update on that source when you have modified any values automatically. - Add a properties 'widget', eventually I want to turn this in to a regular nice properties view like you'd see in the designer, but right now it just uses a form layout in a QScrollArea with regular controls to display the properties. It's clunky but works for the time being. - Make it so that swap chains and the main graphics subsystem will automatically use at least one backbuffer if none was specified - Fix bug where displays weren't added to the main display array - Make it so that you can get the properties of a source via the actual pointer of a source/encoder/output in addition to being able to look up properties via identifier. - When registering source types, check for required functions (wasn't doing it before). getheight/getwidth should not be optional if it's a video source as well. - Add an RAII OBSObj wrapper to obs.hpp for non-reference-counted libobs pointers - Add an RAII OBSSignal wrapper to obs.hpp for libobs signals to automatically disconnect them on destruction - Move the "scale and center" calculation in window-basic-main.cpp to its own function and in its own source file - Add an 'update' callback to WASAPI audio sources
2014-03-23 01:07:54 -07:00
first commit
2013-09-30 19:37:13 -07:00
/* ----------------------------------------------------------------- */
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/* Optional implementation */
Add a way to get default settings - Implement a means of obtaining default settings for an input/output/encoder. obs_source_defaults for example will return the default settings for a particular source type. - Because C++ doesn't have designated initializers, use functions in the WASAPI plugin to register the sources instead.
2014-03-07 05:55:21 -08:00
/**
* Gets the default settings for this source
*
* @param[out] settings Data to assign default settings to
libobs: Add obs_source_info::get_defaults2 Uses type_data to get the type-specific data of a source type
2017-08-29 09:29:56 -07:00
* @deprecated Use get_defaults2 if type_data is needed
Add a way to get default settings - Implement a means of obtaining default settings for an input/output/encoder. obs_source_defaults for example will return the default settings for a particular source type. - Because C++ doesn't have designated initializers, use functions in the WASAPI plugin to register the sources instead.
2014-03-07 05:55:21 -08:00
*/
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
void (*get_defaults)(obs_data_t *settings);
Add a way to get default settings - Implement a means of obtaining default settings for an input/output/encoder. obs_source_defaults for example will return the default settings for a particular source type. - Because C++ doesn't have designated initializers, use functions in the WASAPI plugin to register the sources instead.
2014-03-07 05:55:21 -08:00
Some documentation improvements in obs-source.h
2014-10-12 10:54:49 -07:00
/**
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* Gets the property information of this source
*
Remove majority of warnings There were a *lot* of warnings, managed to remove most of them. Also, put warning flags before C_FLAGS and CXX_FLAGS, rather than after, as -Wall -Wextra was overwriting flags that came before it.
2014-02-14 14:13:36 -08:00
* @return The properties data
libobs: Add obs_source_info::get_properties2 Uses type_data to get the type-specific data of a source type
2017-08-29 09:45:36 -07:00
* @deprecated Use get_properties2 if type_data is needed
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
*/
(API Change) Pass data to get_properties when possible
2014-09-29 08:36:13 -07:00
obs_properties_t *(*get_properties)(void *data);
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Updates the settings for this source
*
* @param data Source data
* @param settings New settings for this source
*/
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
void (*update)(void *data, obs_data_t *settings);
first commit
2013-09-30 19:37:13 -07:00
Separate source activation for main/aux views Split off activate to activate and show callbacks, and split off deactivate to deactivate and hide callbacks. Sources didn't previously have a means to know whether it was actually being displayed in the main view or just happened to be visible somewhere. Now, for things like transition sources, they have a means of knowing when they have actually been "activated" so they can initiate their sequence. A source is now only considered "active" when it's being displayed by the main view. When a source is shown in the main view, the activate callback/signal is triggered. When it's no longer being displayed by the main view, deactivate callback/signal is triggered. When a source is just generally visible to see by any view, the show callback/signal is triggered. If it's no longer visible by any views, then the hide callback/signal is triggered. Presentation volume will now only be active when a source is active in the main view rather than also in auxilary views. Also fix a potential bug where parents wouldn't properly increment or decrement all the activation references of a child source when a child was added or removed.
2014-02-23 16:46:00 -08:00
/** Called when the source has been activated in the main view */
first commit
2013-09-30 19:37:13 -07:00
void (*activate)(void *data);
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
Separate source activation for main/aux views Split off activate to activate and show callbacks, and split off deactivate to deactivate and hide callbacks. Sources didn't previously have a means to know whether it was actually being displayed in the main view or just happened to be visible somewhere. Now, for things like transition sources, they have a means of knowing when they have actually been "activated" so they can initiate their sequence. A source is now only considered "active" when it's being displayed by the main view. When a source is shown in the main view, the activate callback/signal is triggered. When it's no longer being displayed by the main view, deactivate callback/signal is triggered. When a source is just generally visible to see by any view, the show callback/signal is triggered. If it's no longer visible by any views, then the hide callback/signal is triggered. Presentation volume will now only be active when a source is active in the main view rather than also in auxilary views. Also fix a potential bug where parents wouldn't properly increment or decrement all the activation references of a child source when a child was added or removed.
2014-02-23 16:46:00 -08:00
* Called when the source has been deactivated from the main view
* (no longer being played/displayed)
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
*/
first commit
2013-09-30 19:37:13 -07:00
void (*deactivate)(void *data);
Separate source activation for main/aux views Split off activate to activate and show callbacks, and split off deactivate to deactivate and hide callbacks. Sources didn't previously have a means to know whether it was actually being displayed in the main view or just happened to be visible somewhere. Now, for things like transition sources, they have a means of knowing when they have actually been "activated" so they can initiate their sequence. A source is now only considered "active" when it's being displayed by the main view. When a source is shown in the main view, the activate callback/signal is triggered. When it's no longer being displayed by the main view, deactivate callback/signal is triggered. When a source is just generally visible to see by any view, the show callback/signal is triggered. If it's no longer visible by any views, then the hide callback/signal is triggered. Presentation volume will now only be active when a source is active in the main view rather than also in auxilary views. Also fix a potential bug where parents wouldn't properly increment or decrement all the activation references of a child source when a child was added or removed.
2014-02-23 16:46:00 -08:00
/** Called when the source is visible */
void (*show)(void *data);
/** Called when the source is no longer visible */
void (*hide)(void *data);
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Called each video frame with the time elapsed
*
* @param data Source data
* @param seconds Seconds elapsed since the last frame
*/
first commit
2013-09-30 19:37:13 -07:00
void (*video_tick)(void *data, float seconds);
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Called when rendering the source with the graphics subsystem.
*
* If this is an input/transition source, this is called to draw the
* source texture with the graphics subsystem using the specified
* effect.
*
* If this is a filter source, it wraps source draw calls (for
* example applying a custom effect with custom parameters to a
* source). In this case, it's highly recommended to use the
* obs_source_process_filter function to automatically handle
* effect-based filter processing. However, you can implement custom
* draw handling as desired as well.
*
* If the source output flags do not include SOURCE_CUSTOM_DRAW, all
Make some admends to obs-source.h documentation
2014-02-12 07:38:49 -08:00
* a source needs to do is set the "image" parameter of the effect to
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* the desired texture, and then draw. If the output flags include
Fix various typos across multiple modules
2017-03-19 04:35:51 -07:00
* SOURCE_COLOR_MATRIX, you may optionally set the "color_matrix"
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* parameter of the effect to a custom 4x4 conversion matrix (by
* default it will be set to an YUV->RGB conversion matrix)
*
* @param data Source data
* @param effect Effect to be used with this source. If the source
* output flags include SOURCE_CUSTOM_DRAW, this will
* be NULL, and the source is expected to process with
* an effect manually.
*/
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
void (*video_render)(void *data, gs_effect_t *effect);
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Called to filter raw async video data.
*
* @note This function is only used with filter sources.
*
libobs: Clarify filter-related comments Certain callbacks and API functions were a bit vague on when and how they were supposed to be used.
2015-03-07 09:37:07 -08:00
* @param data Filter data
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* @param frame Video frame to filter
* @return New video frame data. This can defer video data to
* be drawn later if time is needed for processing
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
struct obs_source_frame *(*filter_video)(
void *data, struct obs_source_frame *frame);
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Called to filter raw audio data.
*
* @note This function is only used with filter sources.
*
libobs: Clarify filter-related comments Certain callbacks and API functions were a bit vague on when and how they were supposed to be used.
2015-03-07 09:37:07 -08:00
* @param data Filter data
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* @param audio Audio data to filter.
* @return Modified or new audio data. You can directly modify
* the data passed and return it, or you can defer audio
libobs: Clarify filter-related comments Certain callbacks and API functions were a bit vague on when and how they were supposed to be used.
2015-03-07 09:37:07 -08:00
* data for later if time is needed for processing. If
* you are returning new data, that data must exist
* until the next call to the filter_audio callback or
* until the filter is removed/destroyed.
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
*/
(API Change) Rename filtered_audio structure Reanmed filtered_audio to obs_audio_data, to improve the naming and prefix with obs_ for the sake with consistency with the rest of the API
2014-08-02 08:32:53 -07:00
struct obs_audio_data *(*filter_audio)(void *data,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
struct obs_audio_data *audio);
Add functions to enumerate source children/tree
2014-02-20 16:44:42 -08:00
/**
(API Change) libobs: Rename funcs relating to active child sources Renames: ---------------------------------------- obs_source_add_child obs_source_remove_child obs_source_enum_sources obs_source_enum_tree obs_source_info::enum_sources To: ---------------------------------------- obs_source_add_active_child obs_source_remove_active_child obs_source_enum_active_sources obs_source_enum_active_tree obs_source_info::enum_active_sources These functions/callbacks had misleading names: they originally implied any child sources, when they actually meant active child sources that are being used to render video or audio. It's important that the function names represent their actual purpose.
2015-12-22 04:59:02 -08:00
* Called to enumerate all active sources being used within this
* source. If the source has children that render audio/video it must
* implement this callback.
Add functions to enumerate source children/tree
2014-02-20 16:44:42 -08:00
*
libobs: Clarify filter-related comments Certain callbacks and API functions were a bit vague on when and how they were supposed to be used.
2015-03-07 09:37:07 -08:00
* @param data Filter data
Add functions to enumerate source children/tree
2014-02-20 16:44:42 -08:00
* @param enum_callback Enumeration callback
* @param param User data to pass to callback
*/
(API Change) libobs: Rename funcs relating to active child sources Renames: ---------------------------------------- obs_source_add_child obs_source_remove_child obs_source_enum_sources obs_source_enum_tree obs_source_info::enum_sources To: ---------------------------------------- obs_source_add_active_child obs_source_remove_active_child obs_source_enum_active_sources obs_source_enum_active_tree obs_source_info::enum_active_sources These functions/callbacks had misleading names: they originally implied any child sources, when they actually meant active child sources that are being used to render video or audio. It's important that the function names represent their actual purpose.
2015-12-22 04:59:02 -08:00
void (*enum_active_sources)(void *data,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
obs_source_enum_proc_t enum_callback,
void *param);
Add preliminary saving/loading of scene/sources This saves scenes/sources from json on exit, and properly loads it back up when starting up the program again, as well as the currently active scene. I had to add a 'load' and 'save' callback to the source interface structure because I realizes that certain sources (such as scenes) operate different with their saved data; scenes for example would have to keep track of their settings information constantly, and that was somewhat unacceptable to make it functional. The optional 'load' callback will be called only after having loaded setttings specifically from file/imported data, and the 'save' function will be called only specifically when data actually needs to be saved. I also had to adjust the obs_scene code so that it's a regular input source type now, and I also modified it so that it doesn't have some strange custom creation code anymore. The obs_scene_create function is now simply just a wrapper for obs_source_create. You could even create a scene with obs_source_create manually as well.
2014-04-26 23:47:50 -07:00
/**
* Called when saving a source. This is a separate function because
* sometimes a source needs to know when it is being saved so it
* doesn't always have to update the current settings until a certain
* point.
*
* @param data Source data
* @param settings Settings
*/
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
void (*save)(void *data, obs_data_t *settings);
Add preliminary saving/loading of scene/sources This saves scenes/sources from json on exit, and properly loads it back up when starting up the program again, as well as the currently active scene. I had to add a 'load' and 'save' callback to the source interface structure because I realizes that certain sources (such as scenes) operate different with their saved data; scenes for example would have to keep track of their settings information constantly, and that was somewhat unacceptable to make it functional. The optional 'load' callback will be called only after having loaded setttings specifically from file/imported data, and the 'save' function will be called only specifically when data actually needs to be saved. I also had to adjust the obs_scene code so that it's a regular input source type now, and I also modified it so that it doesn't have some strange custom creation code anymore. The obs_scene_create function is now simply just a wrapper for obs_source_create. You could even create a scene with obs_source_create manually as well.
2014-04-26 23:47:50 -07:00
/**
* Called when loading a source from saved data. This should be called
* after all the loading sources have actually been created because
* sometimes there are sources that depend on each other.
*
* @param data Source data
* @param settings Settings
*/
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
void (*load)(void *data, obs_data_t *settings);
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
/**
* Called when interacting with a source and a mouse-down or mouse-up
* occurs.
Some documentation improvements in obs-source.h
2014-10-12 10:54:49 -07:00
*
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
* @param data Source data
* @param event Mouse event properties
* @param type Mouse button pushed
* @param mouse_up Mouse event type (true if mouse-up)
* @param click_count Mouse click count (1 for single click, etc.)
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
void (*mouse_click)(void *data, const struct obs_mouse_event *event,
int32_t type, bool mouse_up, uint32_t click_count);
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
/**
* Called when interacting with a source and a mouse-move occurs.
*
* @param data Source data
* @param event Mouse event properties
* @param mouse_leave Mouse leave state (true if mouse left source)
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
void (*mouse_move)(void *data, const struct obs_mouse_event *event,
bool mouse_leave);
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
/**
* Called when interacting with a source and a mouse-wheel occurs.
*
* @param data Source data
* @param event Mouse event properties
* @param x_delta Movement delta in the horizontal direction
* @param y_delta Movement delta in the vertical direction
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
void (*mouse_wheel)(void *data, const struct obs_mouse_event *event,
int x_delta, int y_delta);
Add interaction support to libobs
2014-09-14 13:31:57 -07:00
/**
* Called when interacting with a source and gain focus/lost focus event
* occurs.
*
* @param data Source data
* @param focus Focus state (true if focus gained)
*/
void (*focus)(void *data, bool focus);
/**
* Called when interacting with a source and a key-up or key-down
* occurs.
*
* @param data Source data
* @param event Key event properties
* @param focus Key event type (true if mouse-up)
*/
void (*key_click)(void *data, const struct obs_key_event *event,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
bool key_up);
libobs: Refactor source volume transition design This changes the way source volume handles transitioning between being active and inactive states. The previous way that transitioning handled volume was that it set the presentation volume of the source and all of its sub-sources to 0.0 if the source was inactive, and 1.0 if active. Transition sources would then also set the presentation volume for sub-sources to whatever their transitioning volume was. However, the problem with this is that the design didn't take in to account if the source or its sub-sources were active anywhere else, so because of that it would break if that ever happened, and I didn't realize that when I was designing it. So instead, this completely overhauls the design of handling transitioning volume. Each frame, it'll go through all sources and check whether they're active or inactive and set the base volume accordingly. If transitions are currently active, it will actually walk the active source tree and check whether the source is in a transitioning state somewhere. - If the source is a sub-source of a transition, and it's not active outside of the transition, then the transition will control the volume of the source. - If the source is a sub-source of a transition, but it's also active outside of the transition, it'll defer to whichever is louder. This also adds a new callback to the obs_source_info structure for transition sources, get_transition_volume, which is called to get the transitioning volume of a sub-source.
2014-12-27 22:16:10 -08:00
libobs: Add filter_remove callback for sources Adds a source callback function that is used when a filter is removed from a source. This ensures that any data that might be associated with that source can be cleaned up if necessary.
2015-03-07 09:33:08 -08:00
/**
* Called when the filter is removed from a source
*
* @param data Filter data
* @param source Source that the filter being removed from
*/
void (*filter_remove)(void *data, obs_source_t *source);
libobs: Add private data to definition structures This is useful for allowing the ability to have private data associated with the object type definition structures. This private data can be useful for things like plugin wrappers for other languages, or providing dynamically generated object types.
2015-09-15 22:39:11 -07:00
/**
* Private data associated with this entry
*/
void *type_data;
/**
* If defined, called to free private data on shutdown
*/
void (*free_type_data)(void *type_data);
libobs: Implement composite sources (skip) (Note: This commit breaks libobs compilation. Skip if bisecting) Adds a "composite" source type which is used for sources that composite one or more sub-sources. The audio_render callback is called for composite sources to allow those types of sources to do custom processing of the audio of its sub-sources.
2015-12-17 06:46:10 -08:00
bool (*audio_render)(void *data, uint64_t *ts_out,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
struct obs_source_audio_mix *audio_output,
uint32_t mixers, size_t channels,
size_t sample_rate);
libobs: Add func to enum active and inactive child tree
2017-01-16 09:51:40 -08:00
/**
* Called to enumerate all active and inactive sources being used
* within this source. If this callback isn't implemented,
* enum_active_sources will be called instead.
*
* This is typically used if a source can have inactive child sources.
*
* @param data Filter data
* @param enum_callback Enumeration callback
* @param param User data to pass to callback
*/
void (*enum_all_sources)(void *data,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
obs_source_enum_proc_t enum_callback,
void *param);
libobs: Add transition callbacks for starting/stopping
2017-07-19 09:24:10 -07:00
void (*transition_start)(void *data);
void (*transition_stop)(void *data);
libobs: Add obs_source_info::get_defaults2 Uses type_data to get the type-specific data of a source type
2017-08-29 09:29:56 -07:00
/**
* Gets the default settings for this source
libobs: Call both get_defaults and get_defaults2 Unlike get_properties, there is not reason to not call get_defaults if it is given in addition to get_defaults2. Additonally this fixes the bug with 'init_encoder' which would only ever call get_defaults, resulting in broken encoders if those used get_defaults2.
2019-07-10 10:37:52 -07:00
*
* If get_defaults is also defined both will be called, and the first
* call will be to get_defaults, then to get_defaults2.
libobs: Add obs_source_info::get_defaults2 Uses type_data to get the type-specific data of a source type
2017-08-29 09:29:56 -07:00
*
* @param type_data The type_data variable of this structure
* @param[out] settings Data to assign default settings to
*/
void (*get_defaults2)(void *type_data, obs_data_t *settings);
libobs: Add obs_source_info::get_properties2 Uses type_data to get the type-specific data of a source type
2017-08-29 09:45:36 -07:00
/**
* Gets the property information of this source
*
* @param data Source data
* @param type_data The type_data variable of this structure
* @return The properties data
*/
obs_properties_t *(*get_properties2)(void *data, void *type_data);
libobs: Add audio lines Adds the "audio_line" internal source type as a bare source type for the sole purpose of outputting audio, and the obs_source_info::audio_mix callback which allows mixing of those audio lines, which is then treated as normal audio for the source. Audio line objects should be added as sub-sources when multiple audio lines from a single source are needed, then mixed together with the audio_mix callback. The difference between the new obs_source_info::audio_mix callback and obs_source_info::audio_render is that obs_source_info::audio_mix (along with the audio_line source) are only one track, and it outputs audio to the source automatically via obs_source_output_audio() when the call completes. This allows the mixed audio to be treated like a normal source's audio, in that you can filter it, change its volume, or monitor it. This change was necessary because the CEF (used with the browser source) outputs multiple audio streams at once to a single browser source, so it's the program's responsibility to mix those streams together itself.
2019-08-21 14:35:40 -07:00
bool (*audio_mix)(void *data, uint64_t *ts_out,
struct audio_output_data *audio_output,
size_t channels, size_t sample_rate);
UI: Add source icons
2019-07-27 21:59:16 -07:00
/** Icon type for the source */
enum obs_icon_type icon_type;
first commit
2013-09-30 19:37:13 -07:00
};
Remove the weird size stuff from OBS_DECLARE_MODULE Instead of doing this, just use macros to handle this situation. Also, fix a minor bug in AAC encoder
2014-04-05 01:43:59 -07:00
EXPORT void obs_register_source_s(const struct obs_source_info *info,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
size_t size);
Remove the weird size stuff from OBS_DECLARE_MODULE Instead of doing this, just use macros to handle this situation. Also, fix a minor bug in AAC encoder
2014-04-05 01:43:59 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
Fix various typos across multiple modules
2017-03-19 04:35:51 -07:00
* Registers a source definition to the current obs context. This should be
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
* used in obs_module_load.
*
* @param info Pointer to the source definition structure
*/
Remove the weird size stuff from OBS_DECLARE_MODULE Instead of doing this, just use macros to handle this situation. Also, fix a minor bug in AAC encoder
2014-04-05 01:43:59 -07:00
#define obs_register_source(info) \
obs_register_source_s(info, sizeof(struct obs_source_info))
first commit
2013-09-30 19:37:13 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
#ifdef __cplusplus
}
#endif