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>
|
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
|
2013-12-02 21:24:38 -08:00
|
|
|
the Free Software Foundation, either version 2 of the License, or
|
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/>.
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
2013-10-14 04:21:15 -07:00
|
|
|
#pragma once
|
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 "util/c99defs.h"
|
2013-09-30 19:37:13 -07:00
|
|
|
#include "util/darray.h"
|
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 "util/dstr.h"
|
2013-09-30 19:37:13 -07:00
|
|
|
#include "util/threading.h"
|
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 "callback/signal.h"
|
|
|
|
|
#include "callback/proc.h"
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
|
#include "graphics/graphics.h"
|
|
|
|
|
|
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 "media-io/audio-resampler.h"
|
2013-09-30 19:37:13 -07:00
|
|
|
#include "media-io/video-io.h"
|
|
|
|
|
#include "media-io/audio-io.h"
|
|
|
|
|
|
|
|
|
|
#include "obs.h"
|
2014-01-17 05:24:34 -08:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
#define NUM_TEXTURES 2
|
|
|
|
|
|
2013-11-20 14:00:16 -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
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
|
/* core */
|
|
|
|
|
|
|
|
|
|
struct obs_module {
|
|
|
|
|
char *name;
|
|
|
|
|
void *module;
|
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
|
|
|
extern void free_module(struct obs_module *mod);
|
|
|
|
|
|
|
|
|
|
|
2013-11-20 14:00:16 -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
|
|
|
/* core */
|
2013-11-20 14:00:16 -08:00
|
|
|
|
2014-02-05 20:03:06 -08:00
|
|
|
struct obs_core_video {
|
2013-11-20 14:00:16 -08:00
|
|
|
graphics_t graphics;
|
|
|
|
|
stagesurf_t copy_surfaces[NUM_TEXTURES];
|
2013-11-26 21:26:14 -08:00
|
|
|
texture_t render_textures[NUM_TEXTURES];
|
|
|
|
|
texture_t output_textures[NUM_TEXTURES];
|
2014-02-05 19:36:21 -08:00
|
|
|
bool textures_rendered[NUM_TEXTURES];
|
|
|
|
|
bool textures_output[NUM_TEXTURES];
|
2013-11-20 14:00:16 -08:00
|
|
|
bool textures_copied[NUM_TEXTURES];
|
2014-02-09 04:51:06 -08:00
|
|
|
struct source_frame convert_frames[NUM_TEXTURES];
|
2014-02-05 19:36:21 -08:00
|
|
|
effect_t default_effect;
|
|
|
|
|
stagesurf_t mapped_surface;
|
2013-11-20 14:00:16 -08:00
|
|
|
int cur_texture;
|
|
|
|
|
|
|
|
|
|
video_t video;
|
|
|
|
|
pthread_t video_thread;
|
|
|
|
|
bool thread_initialized;
|
|
|
|
|
|
2013-12-06 05:38:19 -08:00
|
|
|
uint32_t base_width;
|
|
|
|
|
uint32_t base_height;
|
2013-11-20 14:00:16 -08:00
|
|
|
};
|
|
|
|
|
|
2014-02-05 20:03:06 -08:00
|
|
|
struct obs_core_audio {
|
2014-01-31 23:49:50 -08:00
|
|
|
/* TODO: sound output subsystem */
|
2013-11-20 14:00:16 -08:00
|
|
|
audio_t audio;
|
|
|
|
|
};
|
|
|
|
|
|
2013-11-20 17:36:46 -08:00
|
|
|
/* user sources, output channels, and displays */
|
2014-02-05 20:03:06 -08:00
|
|
|
struct obs_core_data {
|
2013-12-20 18:35:12 -08:00
|
|
|
/* arrays of pointers jim? you should really stop being lazy and use
|
|
|
|
|
* linked lists. */
|
2013-11-20 14:00:16 -08:00
|
|
|
DARRAY(struct obs_display*) displays;
|
|
|
|
|
DARRAY(struct obs_source*) sources;
|
Add preliminary output/encoder interface
- First, I redid the output interface for libobs. I feel like it's
going in a pretty good direction in terms of design.
Right now, the design is so that outputs and encoders are separate.
One or more outputs can connect to a specific encoder to receive its
data, or the output can connect directly to raw data from libobs
output itself, if the output doesn't want to use a designated encoder.
Data is received via callbacks set when you connect to the encoder or
raw output. Multiple outputs can receive the data from a single
encoder context if need be (such as for streaming to multiple channels
at once, and/or recording with the same data).
When an encoder is first connected to, it will connect to raw output,
and start encoding. Additional connections will receive that same
data being encoded as well after that. When the last encoder has
disconnected, it will stop encoding. If for some reason the encoder
needs to stop, it will use the callback with NULL to signal that
encoding has stopped. Some of these things may be subject to change
in the future, though it feels pretty good with this design so far.
Will have to see how well it works out in practice versus theory.
- Second, Started adding preliminary RTMP/x264 output plugin code.
To speed things up, I might just make a direct raw->FFmpeg output to
create a quick output plugin that we can start using for testing all
the subsystems.
2014-01-16 21:34:51 -08:00
|
|
|
DARRAY(struct obs_output*) outputs;
|
|
|
|
|
DARRAY(struct obs_encoder*) encoders;
|
2013-11-20 14:00:16 -08:00
|
|
|
|
|
|
|
|
obs_source_t channels[MAX_CHANNELS];
|
|
|
|
|
pthread_mutex_t sources_mutex;
|
|
|
|
|
pthread_mutex_t displays_mutex;
|
Add preliminary output/encoder interface
- First, I redid the output interface for libobs. I feel like it's
going in a pretty good direction in terms of design.
Right now, the design is so that outputs and encoders are separate.
One or more outputs can connect to a specific encoder to receive its
data, or the output can connect directly to raw data from libobs
output itself, if the output doesn't want to use a designated encoder.
Data is received via callbacks set when you connect to the encoder or
raw output. Multiple outputs can receive the data from a single
encoder context if need be (such as for streaming to multiple channels
at once, and/or recording with the same data).
When an encoder is first connected to, it will connect to raw output,
and start encoding. Additional connections will receive that same
data being encoded as well after that. When the last encoder has
disconnected, it will stop encoding. If for some reason the encoder
needs to stop, it will use the callback with NULL to signal that
encoding has stopped. Some of these things may be subject to change
in the future, though it feels pretty good with this design so far.
Will have to see how well it works out in practice versus theory.
- Second, Started adding preliminary RTMP/x264 output plugin code.
To speed things up, I might just make a direct raw->FFmpeg output to
create a quick output plugin that we can start using for testing all
the subsystems.
2014-01-16 21:34:51 -08:00
|
|
|
pthread_mutex_t outputs_mutex;
|
|
|
|
|
pthread_mutex_t encoders_mutex;
|
2014-01-23 16:00:42 -08:00
|
|
|
|
|
|
|
|
volatile bool valid;
|
2013-11-20 14:00:16 -08:00
|
|
|
};
|
|
|
|
|
|
2014-02-05 20:03:06 -08:00
|
|
|
struct obs_core {
|
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
|
|
|
DARRAY(struct obs_module) modules;
|
|
|
|
|
DARRAY(struct obs_source_info) input_types;
|
|
|
|
|
DARRAY(struct obs_source_info) filter_types;
|
|
|
|
|
DARRAY(struct obs_source_info) transition_types;
|
|
|
|
|
DARRAY(struct obs_output_info) output_types;
|
|
|
|
|
DARRAY(struct obs_encoder_info) encoder_types;
|
|
|
|
|
DARRAY(struct obs_service_info) service_types;
|
|
|
|
|
DARRAY(struct obs_modal_ui) modal_ui_callbacks;
|
|
|
|
|
DARRAY(struct obs_modeless_ui) modeless_ui_callbacks;
|
|
|
|
|
|
|
|
|
|
signal_handler_t signals;
|
|
|
|
|
proc_handler_t procs;
|
2013-12-26 22:10:15 -08:00
|
|
|
|
2013-11-20 14:00:16 -08:00
|
|
|
/* segmented into multiple sub-structures to keep things a bit more
|
|
|
|
|
* clean and organized */
|
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
|
|
|
struct obs_core_video video;
|
|
|
|
|
struct obs_core_audio audio;
|
|
|
|
|
struct obs_core_data data;
|
2013-09-30 19:37:13 -07:00
|
|
|
};
|
|
|
|
|
|
2014-02-05 20:03:06 -08:00
|
|
|
extern struct obs_core *obs;
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
extern void *obs_video_thread(void *param);
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
|
/* displays */
|
|
|
|
|
|
|
|
|
|
struct obs_display {
|
|
|
|
|
swapchain_t swap; /* can be NULL if just sound */
|
|
|
|
|
obs_source_t channels[MAX_CHANNELS];
|
|
|
|
|
|
|
|
|
|
/* TODO: sound output target */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
|
/* sources */
|
|
|
|
|
|
|
|
|
|
struct obs_source {
|
|
|
|
|
volatile int refs;
|
|
|
|
|
struct obs_source_info info;
|
|
|
|
|
|
|
|
|
|
/* source-specific data */
|
|
|
|
|
char *name; /* user-defined name */
|
|
|
|
|
enum obs_source_type type;
|
|
|
|
|
obs_data_t settings;
|
|
|
|
|
void *data;
|
|
|
|
|
|
|
|
|
|
signal_handler_t signals;
|
|
|
|
|
proc_handler_t procs;
|
|
|
|
|
|
|
|
|
|
/* used to indicate that the source has been removed and all
|
|
|
|
|
* references to it should be released (not exactly how I would prefer
|
|
|
|
|
* to handle things but it's the best option) */
|
|
|
|
|
bool removed;
|
|
|
|
|
|
|
|
|
|
/* timing (if video is present, is based upon video) */
|
|
|
|
|
volatile bool timing_set;
|
|
|
|
|
volatile uint64_t timing_adjust;
|
|
|
|
|
volatile int audio_reset_ref;
|
|
|
|
|
uint64_t next_audio_ts_min;
|
|
|
|
|
uint64_t last_frame_ts;
|
|
|
|
|
uint64_t last_sys_timestamp;
|
|
|
|
|
|
|
|
|
|
/* audio */
|
|
|
|
|
bool audio_failed;
|
|
|
|
|
struct resample_info sample_info;
|
|
|
|
|
audio_resampler_t resampler;
|
|
|
|
|
audio_line_t audio_line;
|
|
|
|
|
pthread_mutex_t audio_mutex;
|
|
|
|
|
struct filtered_audio audio_data;
|
|
|
|
|
size_t audio_storage_size;
|
|
|
|
|
float volume;
|
|
|
|
|
|
|
|
|
|
/* async video data */
|
|
|
|
|
texture_t output_texture;
|
|
|
|
|
DARRAY(struct source_frame*) video_frames;
|
|
|
|
|
pthread_mutex_t video_mutex;
|
|
|
|
|
|
|
|
|
|
/* filters */
|
|
|
|
|
struct obs_source *filter_parent;
|
|
|
|
|
struct obs_source *filter_target;
|
|
|
|
|
DARRAY(struct obs_source*) filters;
|
|
|
|
|
pthread_mutex_t filter_mutex;
|
|
|
|
|
texrender_t filter_texrender;
|
|
|
|
|
bool rendering_filter;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
bool obs_source_init_handlers(struct obs_source *source);
|
|
|
|
|
extern bool obs_source_init(struct obs_source *source,
|
|
|
|
|
const struct obs_source_info *info);
|
|
|
|
|
|
|
|
|
|
extern void obs_source_activate(obs_source_t source);
|
|
|
|
|
extern void obs_source_deactivate(obs_source_t source);
|
|
|
|
|
extern void obs_source_video_tick(obs_source_t source, float seconds);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
|
/* outputs */
|
|
|
|
|
|
|
|
|
|
struct obs_output {
|
|
|
|
|
char *name;
|
|
|
|
|
void *data;
|
|
|
|
|
struct obs_output_info info;
|
|
|
|
|
obs_data_t settings;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
|
/* encoders */
|
|
|
|
|
|
|
|
|
|
struct obs_encoder_callback {
|
|
|
|
|
void (*new_packet)(void *param, struct encoder_packet *packet);
|
|
|
|
|
void *param;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct obs_encoder {
|
|
|
|
|
char *name;
|
|
|
|
|
void *data;
|
|
|
|
|
struct obs_encoder_info info;
|
|
|
|
|
obs_data_t settings;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_t data_callbacks_mutex;
|
|
|
|
|
DARRAY(struct obs_encoder_callback) data_callbacks;
|
|
|
|
|
};
|
