2013-09-30 19:37:13 -07:00
|
|
|
/******************************************************************************
|
2014-03-07 05:55:21 -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/>.
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
|
|
#include "obs.h"
|
2014-01-26 17:48:14 -08:00
|
|
|
#include "obs-internal.h"
|
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
|
|
|
static inline const struct obs_output_info *find_output(const char *id)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
for (i = 0; i < obs->output_types.num; i++)
|
2013-12-20 16:23:19 -08:00
|
|
|
if (strcmp(obs->output_types.array[i].id, id) == 0)
|
2013-09-30 19:37:13 -07:00
|
|
|
return obs->output_types.array+i;
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
obs_output_t obs_output_create(const char *id, const char *name,
|
2014-01-27 22:14:58 -08:00
|
|
|
obs_data_t settings)
|
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
|
|
|
const struct obs_output_info *info = find_output(id);
|
2013-09-30 19:37:13 -07:00
|
|
|
struct obs_output *output;
|
|
|
|
|
|
|
|
|
|
if (!info) {
|
2014-02-28 19:02:29 -08:00
|
|
|
blog(LOG_ERROR, "Output '%s' not found", id);
|
2013-09-30 19:37:13 -07:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2014-03-10 13:10:35 -07:00
|
|
|
output = bzalloc(sizeof(struct obs_output));
|
|
|
|
|
|
|
|
|
|
output->signals = signal_handler_create();
|
|
|
|
|
if (!output->signals)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
|
|
output->procs = proc_handler_create();
|
|
|
|
|
if (!output->procs)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
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
|
|
|
output->info = *info;
|
2014-01-28 17:41:24 -08:00
|
|
|
output->settings = obs_data_newref(settings);
|
|
|
|
|
output->data = info->create(output->settings, output);
|
2014-03-10 13:10:35 -07:00
|
|
|
if (!output->data)
|
|
|
|
|
goto fail;
|
2013-09-30 19:37:13 -07:00
|
|
|
|
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
|
|
|
output->name = bstrdup(name);
|
2014-01-27 22:14:58 -08:00
|
|
|
|
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_lock(&obs->data.outputs_mutex);
|
|
|
|
|
da_push_back(obs->data.outputs, &output);
|
|
|
|
|
pthread_mutex_unlock(&obs->data.outputs_mutex);
|
2014-03-10 13:10:35 -07:00
|
|
|
|
|
|
|
|
output->valid = true;
|
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
return output;
|
2014-03-10 13:10:35 -07:00
|
|
|
|
|
|
|
|
fail:
|
|
|
|
|
obs_output_destroy(output);
|
|
|
|
|
return NULL;
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
|
2013-10-14 12:37:52 -07:00
|
|
|
void obs_output_destroy(obs_output_t output)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
|
|
|
|
if (output) {
|
2014-03-10 13:10:35 -07:00
|
|
|
if (output->valid) {
|
|
|
|
|
if (output->info.active) {
|
|
|
|
|
if (output->info.active(output->data))
|
|
|
|
|
output->info.stop(output->data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&obs->data.outputs_mutex);
|
|
|
|
|
da_erase_item(obs->data.outputs, &output);
|
|
|
|
|
pthread_mutex_unlock(&obs->data.outputs_mutex);
|
2014-02-07 02:03:54 -08:00
|
|
|
}
|
|
|
|
|
|
2014-03-10 13:10:35 -07:00
|
|
|
if (output->data)
|
|
|
|
|
output->info.destroy(output->data);
|
|
|
|
|
|
|
|
|
|
signal_handler_destroy(output->signals);
|
|
|
|
|
proc_handler_destroy(output->procs);
|
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
|
|
|
|
2014-01-27 22:14:58 -08:00
|
|
|
obs_data_release(output->settings);
|
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
|
|
|
bfree(output->name);
|
2013-09-30 19:37:13 -07:00
|
|
|
bfree(output);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
bool obs_output_start(obs_output_t output)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
2014-02-23 21:39:33 -08:00
|
|
|
return (output != NULL) ? output->info.start(output->data) : false;
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
|
2013-10-14 12:37:52 -07:00
|
|
|
void obs_output_stop(obs_output_t output)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
2014-02-23 21:39:33 -08:00
|
|
|
if (output)
|
|
|
|
|
output->info.stop(output->data);
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
bool obs_output_active(obs_output_t output)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
2014-02-23 21:39:33 -08:00
|
|
|
return (output != NULL) ? output->info.active(output) : false;
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
|
2014-03-07 05:55:21 -08:00
|
|
|
obs_data_t obs_output_defaults(const char *id)
|
|
|
|
|
{
|
|
|
|
|
const struct obs_output_info *info = find_output(id);
|
|
|
|
|
if (info) {
|
|
|
|
|
obs_data_t settings = obs_data_create();
|
|
|
|
|
if (info->defaults)
|
|
|
|
|
info->defaults(settings);
|
|
|
|
|
return settings;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2014-02-01 21:46:13 -08:00
|
|
|
obs_properties_t obs_output_properties(const char *id, const char *locale)
|
|
|
|
|
{
|
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
|
|
|
const struct obs_output_info *info = find_output(id);
|
2014-02-01 21:46:13 -08:00
|
|
|
if (info && info->properties)
|
|
|
|
|
return info->properties(locale);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-27 22:14:58 -08:00
|
|
|
void obs_output_update(obs_output_t output, obs_data_t settings)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
2014-02-23 21:39:33 -08:00
|
|
|
if (!output) return;
|
|
|
|
|
|
2014-02-21 20:05:21 -08:00
|
|
|
obs_data_apply(output->settings, settings);
|
2014-01-28 14:45:30 -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
|
|
|
if (output->info.update)
|
|
|
|
|
output->info.update(output->data, output->settings);
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
|
2014-02-10 09:22:35 -08:00
|
|
|
obs_data_t obs_output_get_settings(obs_output_t output)
|
|
|
|
|
{
|
|
|
|
|
if (!output)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
obs_data_addref(output->settings);
|
|
|
|
|
return output->settings;
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-14 12:37:52 -07:00
|
|
|
bool obs_output_canpause(obs_output_t output)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
2014-02-23 21:39:33 -08:00
|
|
|
return (output != NULL) ? output->info.pause != NULL : false;
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
|
2013-10-14 12:37:52 -07:00
|
|
|
void obs_output_pause(obs_output_t output)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
2014-02-23 21:39:33 -08:00
|
|
|
if (output && output->info.pause)
|
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
|
|
|
output->info.pause(output->data);
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
2014-03-10 13:10:35 -07:00
|
|
|
|
|
|
|
|
signal_handler_t obs_output_signalhandler(obs_output_t output)
|
|
|
|
|
{
|
|
|
|
|
return output->signals;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
proc_handler_t obs_output_prochandler(obs_output_t output)
|
|
|
|
|
{
|
|
|
|
|
return output->procs;
|
|
|
|
|
}
|