obs-studio/libobs/obs-encoder.c

176 lines
4.4 KiB
C
Raw Normal View History

/******************************************************************************
Copyright (C) 2013 by Hugh Bailey <obs.jim@gmail.com>
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
the Free Software Foundation, either version 2 of the License, or
(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"
#include "obs-internal.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 08:04:50 -07:00
static inline struct obs_encoder_info *get_encoder_info(const char *id)
{
for (size_t i = 0; i < obs->encoder_types.num; i++) {
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 08:04:50 -07:00
struct obs_encoder_info *info = obs->encoder_types.array+i;
if (strcmp(info->id, id) == 0)
return info;
}
return NULL;
}
const char *obs_encoder_getdisplayname(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 08:04:50 -07:00
struct obs_encoder_info *ei = get_encoder_info(id);
if (!ei)
return NULL;
return ei->getname(locale);
}
obs_encoder_t obs_encoder_create(const char *id, const char *name,
obs_data_t settings)
{
struct obs_encoder *encoder;
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 08:04:50 -07:00
struct obs_encoder_info *ei = get_encoder_info(id);
if (!ei)
return NULL;
encoder = bzalloc(sizeof(struct obs_encoder));
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 08:04:50 -07:00
encoder->info = *ei;
if (pthread_mutex_init(&encoder->data_callbacks_mutex, NULL) != 0) {
bfree(encoder);
return NULL;
}
encoder->settings = obs_data_newref(settings);
encoder->data = ei->create(encoder->settings, encoder);
if (!encoder->data) {
pthread_mutex_destroy(&encoder->data_callbacks_mutex);
obs_data_release(encoder->settings);
bfree(encoder);
return NULL;
}
pthread_mutex_lock(&obs->data.encoders_mutex);
da_push_back(obs->data.encoders, &encoder);
pthread_mutex_unlock(&obs->data.encoders_mutex);
encoder->name = bstrdup(name);
return encoder;
}
void obs_encoder_destroy(obs_encoder_t encoder)
{
if (encoder) {
pthread_mutex_lock(&obs->data.encoders_mutex);
da_erase_item(obs->data.encoders, &encoder);
pthread_mutex_unlock(&obs->data.encoders_mutex);
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 08:04:50 -07:00
encoder->info.destroy(encoder->data);
obs_data_release(encoder->settings);
bfree(encoder->name);
bfree(encoder);
}
}
obs_data_t obs_encoder_defaults(const char *id)
{
const struct obs_encoder_info *info = get_encoder_info(id);
if (info) {
obs_data_t settings = obs_data_create();
if (info->defaults)
info->defaults(settings);
return settings;
}
return NULL;
}
obs_properties_t obs_encoder_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 08:04:50 -07:00
const struct obs_encoder_info *ei = get_encoder_info(id);
Split output/input audio capture sources - Split input and output audio captures so that they're different sources. This allows easier handling and enumeration of audio devices without having to do some sort of string processing. This way the user interface code can handle this a bit more easily, and so that it doesn't confuse users either. This should be done for all audio capture sources for all operating systems. You don't have to duplicate any code, you just need to create input/output wrapper functions to designate the audio as input or output before creation. - Make it detect soundflower and wavtap devices as mac "output" devices (even though they're actually input) for the mac output capture, and make it so that users can select a default output capture and automatically use soundflower or wavtap. I'm not entirely happy about having to do this, but because mac is designed this way, this is really the only way to handle it that makes it easier for users and UI code to deal with. Note that soundflower and wavtap are still also designated as input devices, so will still show up in input device enumeration. - Remove pragma messages because they were kind polluting the other compiler messages and just getting in the way. In the future we can just do a grep for TODO to find them. - Redo list property again, this time using a safer internal array, rather than requiring sketchy array inputs. Having functions handle everything behind the scenes is much safer. - Remove the reference counter debug log code, as it was included unintentionally in a commit.
2014-03-03 02:56:54 -07:00
if (ei && ei->properties)
return ei->properties(locale);
return NULL;
}
void obs_encoder_update(obs_encoder_t encoder, obs_data_t settings)
{
if (!encoder) return;
obs_data_apply(encoder->settings, settings);
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 08:04:50 -07:00
encoder->info.update(encoder->data, encoder->settings);
}
bool obs_encoder_reset(obs_encoder_t encoder, obs_data_t settings)
{
if (!encoder) return false;
return encoder->info.reset(encoder->data, settings);
}
bool obs_encoder_encode(obs_encoder_t encoder,
const struct encoder_frame *frame,
struct encoder_packet *packet, bool *received_packet)
{
if (!encoder) return false;
return encoder->info.encode(encoder->data, frame, packet,
received_packet);
}
bool obs_encoder_get_extra_data(obs_encoder_t encoder, uint8_t **extra_data,
size_t *size)
{
if (!encoder) return false;
if (encoder->info.get_extra_data)
return encoder->info.get_extra_data(encoder, extra_data, size);
return false;
}
obs_data_t obs_encoder_get_settings(obs_encoder_t encoder)
{
if (!encoder) return NULL;
obs_data_addref(encoder->settings);
return encoder->settings;
}
bool obs_encoder_start(obs_encoder_t encoder,
void (*new_packet)(void *param, struct encoder_packet *packet),
void *param)
{
Split output/input audio capture sources - Split input and output audio captures so that they're different sources. This allows easier handling and enumeration of audio devices without having to do some sort of string processing. This way the user interface code can handle this a bit more easily, and so that it doesn't confuse users either. This should be done for all audio capture sources for all operating systems. You don't have to duplicate any code, you just need to create input/output wrapper functions to designate the audio as input or output before creation. - Make it detect soundflower and wavtap devices as mac "output" devices (even though they're actually input) for the mac output capture, and make it so that users can select a default output capture and automatically use soundflower or wavtap. I'm not entirely happy about having to do this, but because mac is designed this way, this is really the only way to handle it that makes it easier for users and UI code to deal with. Note that soundflower and wavtap are still also designated as input devices, so will still show up in input device enumeration. - Remove pragma messages because they were kind polluting the other compiler messages and just getting in the way. In the future we can just do a grep for TODO to find them. - Redo list property again, this time using a safer internal array, rather than requiring sketchy array inputs. Having functions handle everything behind the scenes is much safer. - Remove the reference counter debug log code, as it was included unintentionally in a commit.
2014-03-03 02:56:54 -07:00
/* TODO: implement */
UNUSED_PARAMETER(encoder);
UNUSED_PARAMETER(new_packet);
UNUSED_PARAMETER(param);
return false;
}
void obs_encoder_stop(obs_encoder_t encoder,
void (*new_packet)(void *param, struct encoder_packet *packet),
void *param)
{
Split output/input audio capture sources - Split input and output audio captures so that they're different sources. This allows easier handling and enumeration of audio devices without having to do some sort of string processing. This way the user interface code can handle this a bit more easily, and so that it doesn't confuse users either. This should be done for all audio capture sources for all operating systems. You don't have to duplicate any code, you just need to create input/output wrapper functions to designate the audio as input or output before creation. - Make it detect soundflower and wavtap devices as mac "output" devices (even though they're actually input) for the mac output capture, and make it so that users can select a default output capture and automatically use soundflower or wavtap. I'm not entirely happy about having to do this, but because mac is designed this way, this is really the only way to handle it that makes it easier for users and UI code to deal with. Note that soundflower and wavtap are still also designated as input devices, so will still show up in input device enumeration. - Remove pragma messages because they were kind polluting the other compiler messages and just getting in the way. In the future we can just do a grep for TODO to find them. - Redo list property again, this time using a safer internal array, rather than requiring sketchy array inputs. Having functions handle everything behind the scenes is much safer. - Remove the reference counter debug log code, as it was included unintentionally in a commit.
2014-03-03 02:56:54 -07:00
/* TODO: implement */
UNUSED_PARAMETER(encoder);
UNUSED_PARAMETER(new_packet);
UNUSED_PARAMETER(param);
return;
}