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

285 lines
9.3 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 "util/c99defs.h"
first commit
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"
first commit
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"
first commit
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"
first commit
2013-09-30 19:37:13 -07:00
#include "media-io/video-io.h"
#include "media-io/audio-io.h"
#include "obs.h"
Use macros to improve safety loading callbacks Just a minor fix mostly because I noticed that I kept accidentally forgetting to add checks to the code properly. This is one of those cases where macros come in useful, as macros can automate the process and help prevent these mistakes from happening by accident.
2014-01-17 05:24:34 -08:00
first commit
2013-09-30 19:37:13 -07:00
#define NUM_TEXTURES 2
cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing
2013-11-20 14:00:16 -08:00
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
struct draw_callback {
void (*draw)(void *param, uint32_t cx, uint32_t cy);
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
/* ------------------------------------------------------------------------- */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
/* modules */
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_module {
char *name;
void *module;
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
extern void free_module(struct obs_module *mod);
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
/* ------------------------------------------------------------------------- */
Rename obs_viewport to obs_view I felt like the name could cause a bit of confusion with typical graphics viewports, so I just changed it to view instead.
2014-02-13 09:21:16 -08:00
/* views */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
Rename obs_viewport to obs_view I felt like the name could cause a bit of confusion with typical graphics viewports, so I just changed it to view instead.
2014-02-13 09:21:16 -08:00
struct obs_view {
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
pthread_mutex_t channels_mutex;
obs_source_t channels[MAX_CHANNELS];
};
Rename obs_viewport to obs_view I felt like the name could cause a bit of confusion with typical graphics viewports, so I just changed it to view instead.
2014-02-13 09:21:16 -08:00
extern bool obs_view_init(struct obs_view *view);
extern void obs_view_free(struct obs_view *view);
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
/* ------------------------------------------------------------------------- */
/* displays */
struct obs_display {
bool size_changed;
uint32_t cx, cy;
swapchain_t swap;
pthread_mutex_t draw_callbacks_mutex;
DARRAY(struct draw_callback) draw_callbacks;
};
extern bool obs_display_init(struct obs_display *display,
struct gs_init_data *graphics_data);
extern void obs_display_free(struct obs_display *display);
cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing
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 */
cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing
2013-11-20 14:00:16 -08:00
Improve naming scheme of libobs core structures
2014-02-05 20:03:06 -08:00
struct obs_core_video {
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
graphics_t graphics;
stagesurf_t copy_surfaces[NUM_TEXTURES];
texture_t render_textures[NUM_TEXTURES];
texture_t output_textures[NUM_TEXTURES];
Make a number of key optimizations - Changed glMapBuffer to glMapBufferRange to allow invalidation. Using just glMapBuffer alone was causing some unacceptable stalls. - Changed dynamic buffers from GL_DYNAMIC_WRITE to GL_STREAM_WRITE because I had misunderstood the OpenGL specification - Added _OPENGL and _D3D11 builtin preprocessor macros to effects to allow special processing if needed - Added fmod support to shaders (NOTE: D3D and GL do not function identically with negative numbers when using this. Positive numbers however function identically) - Created a planar conversion shader that converts from packed YUV to planar 420 right on the GPU without any CPU processing. Reduces required GPU download size to approximately 37.5% of its normal rate as well. GPU usage down by 10 entire percentage points despite the extra required pass.
2014-02-16 18:28:21 -08:00
texture_t convert_textures[NUM_TEXTURES];
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
bool textures_rendered[NUM_TEXTURES];
bool textures_output[NUM_TEXTURES];
bool textures_copied[NUM_TEXTURES];
Make a number of key optimizations - Changed glMapBuffer to glMapBufferRange to allow invalidation. Using just glMapBuffer alone was causing some unacceptable stalls. - Changed dynamic buffers from GL_DYNAMIC_WRITE to GL_STREAM_WRITE because I had misunderstood the OpenGL specification - Added _OPENGL and _D3D11 builtin preprocessor macros to effects to allow special processing if needed - Added fmod support to shaders (NOTE: D3D and GL do not function identically with negative numbers when using this. Positive numbers however function identically) - Created a planar conversion shader that converts from packed YUV to planar 420 right on the GPU without any CPU processing. Reduces required GPU download size to approximately 37.5% of its normal rate as well. GPU usage down by 10 entire percentage points despite the extra required pass.
2014-02-16 18:28:21 -08:00
bool textures_converted[NUM_TEXTURES];
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
struct source_frame convert_frames[NUM_TEXTURES];
effect_t default_effect;
Make a number of key optimizations - Changed glMapBuffer to glMapBufferRange to allow invalidation. Using just glMapBuffer alone was causing some unacceptable stalls. - Changed dynamic buffers from GL_DYNAMIC_WRITE to GL_STREAM_WRITE because I had misunderstood the OpenGL specification - Added _OPENGL and _D3D11 builtin preprocessor macros to effects to allow special processing if needed - Added fmod support to shaders (NOTE: D3D and GL do not function identically with negative numbers when using this. Positive numbers however function identically) - Created a planar conversion shader that converts from packed YUV to planar 420 right on the GPU without any CPU processing. Reduces required GPU download size to approximately 37.5% of its normal rate as well. GPU usage down by 10 entire percentage points despite the extra required pass.
2014-02-16 18:28:21 -08:00
effect_t conversion_effect;
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
stagesurf_t mapped_surface;
int cur_texture;
video_t video;
pthread_t video_thread;
bool thread_initialized;
Make a number of key optimizations - Changed glMapBuffer to glMapBufferRange to allow invalidation. Using just glMapBuffer alone was causing some unacceptable stalls. - Changed dynamic buffers from GL_DYNAMIC_WRITE to GL_STREAM_WRITE because I had misunderstood the OpenGL specification - Added _OPENGL and _D3D11 builtin preprocessor macros to effects to allow special processing if needed - Added fmod support to shaders (NOTE: D3D and GL do not function identically with negative numbers when using this. Positive numbers however function identically) - Created a planar conversion shader that converts from packed YUV to planar 420 right on the GPU without any CPU processing. Reduces required GPU download size to approximately 37.5% of its normal rate as well. GPU usage down by 10 entire percentage points despite the extra required pass.
2014-02-16 18:28:21 -08:00
bool gpu_conversion;
const char *conversion_tech;
uint32_t conversion_height;
uint32_t plane_offsets[3];
uint32_t plane_sizes[3];
uint32_t plane_linewidth[3];
uint32_t output_width;
uint32_t output_height;
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
uint32_t base_width;
uint32_t base_height;
struct obs_display main_display;
cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing
2013-11-20 14:00:16 -08:00
};
Improve naming scheme of libobs core structures
2014-02-05 20:03:06 -08:00
struct obs_core_audio {
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08:00
/* TODO: sound output subsystem */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
audio_t audio;
Add more volume options Added a "master" volume for the entire audio subsystem. Also, added a "presentation" volume for both the master volume and for each invidiaul source. The presentation volume is used to control things like transitioning volumes, preventing sources from outputting any audio when they're inactive, as well as some other uses in the future.
2014-02-20 14:53:16 -08:00
float user_volume;
float present_volume;
cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing
2013-11-20 14:00:16 -08:00
};
adjusted the way source removal is handled to make it a bit more safe
2013-11-20 17:36:46 -08:00
/* user sources, output channels, and displays */
Improve naming scheme of libobs core structures
2014-02-05 20:03:06 -08:00
struct obs_core_data {
add obs_source functions to allow name manipulation and lookup based upon name, and a few other functions related to getting/setting source information
2013-12-20 18:35:12 -08:00
/* arrays of pointers jim? you should really stop being lazy and use
* linked lists. */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
DARRAY(struct obs_display*) displays;
DARRAY(struct obs_source*) sources;
DARRAY(struct obs_output*) outputs;
DARRAY(struct obs_encoder*) encoders;
pthread_mutex_t sources_mutex;
pthread_mutex_t displays_mutex;
pthread_mutex_t outputs_mutex;
pthread_mutex_t encoders_mutex;
Rename obs_viewport to obs_view I felt like the name could cause a bit of confusion with typical graphics viewports, so I just changed it to view instead.
2014-02-13 09:21:16 -08:00
struct obs_view main_view;
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
volatile bool valid;
cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing
2013-11-20 14:00:16 -08:00
};
Improve naming scheme of libobs core structures
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;
implement signal/procedure handling into libobs and individual sources
2013-12-26 22:10:15 -08:00
cleaned up main internal data structure design, changed to reference counting for sources to ensure safe destruction of source objects from all parts of the system, added some service-related stuff for testing
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;
first commit
2013-09-30 19:37:13 -07:00
};
Improve naming scheme of libobs core structures
2014-02-05 20:03:06 -08:00
extern struct obs_core *obs;
change names, fix some bugs, minor GL/D3D fixes, update tests, fix effect files, output a little more debug information
2013-10-14 12:37:52 -07:00
first commit
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
/* ------------------------------------------------------------------------- */
/* sources */
struct obs_source {
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
volatile int refs;
struct obs_source_info info;
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-specific data */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
char *name; /* user-defined name */
obs_data_t settings;
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
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
signal_handler_t signals;
proc_handler_t procs;
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
/* ensures show/hide are only called once */
int show_refs;
Implement source activation/deactivation Now sources will be properly activated and deactivated when they are in use or not in use. Had to figure out a way to handle child sources, and children of children, just ended up implementing simple functions that parents use to signal adding/removal to help with hierarchial activation and deactivation of child sources. To prevent the source activate/deactivate callbacks from being called more than once, added an activation reference counter. The first increment will call the activate callback, and the last decrement will call the deactivate callback. Added "source-activate" and "source-deactivate" signals to the main obs signal handler, and "activate" and "deactivate" to individual source signal handlers. Also, fixed the main window so it properly selects a source when the current active scene has been changed.
2014-02-20 21:04:14 -08:00
/* ensures activate/deactivate are only called once */
int activate_refs;
Add functions to enumerate source children/tree
2014-02-20 16:44:42 -08:00
/* prevents infinite recursion when enumerating sources */
int enum_refs;
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 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) */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
bool removed;
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
/* timing (if video is present, is based upon video) */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
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;
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
/* audio */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
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;
Add more volume options Added a "master" volume for the entire audio subsystem. Also, added a "presentation" volume for both the master volume and for each invidiaul source. The presentation volume is used to control things like transitioning volumes, preventing sources from outputting any audio when they're inactive, as well as some other uses in the future.
2014-02-20 14:53:16 -08:00
float user_volume;
float present_volume;
Add source audio sync offset setting
2014-02-20 15:16:25 -08:00
int64_t sync_offset;
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
Implement volume handling - Remove obs_source::type because it became redundant now that the type is always stored in the obs_source::info variable. - Apply presentation volumes of 1.0 and 0.0 to sources when they activate/deactivate, respectively. It also applies that presentation volume to all sub-sources, with exception of transition sources. Transition sources must apply presentation volume manually to their sub-sources with the new transition functions below. - Add a "transition_volume" variable to obs_source structure, and add three functions for handling volume for transitions: * obs_transition_begin_frame * obs_source_set_transition_vol * obs_transition_end_frame Because the to/from targets of a transition source might both contain some of the same sources, handling the transitioning of volumes for that specific situation becomes an issue. So for transitions, instead of modifying the presentation volumes directly for both sets of sources, we do this: - First, call obs_transition_begin_frame at the beginning of each transition frame, which will reset transition volumes for all sub-sources to 0. Presentation volumes remain unchanged. - Call obs_source_set_transition_vol on each sub-source, which will then add the volume to the transition volume for each source in that source's tree. Presentation volumes still remain unchanged. - Then you call obs_trandition_end_frame when complete, which will then finally set the presentation volumes to the transition volumes. For example, let's say that there's one source that's within both the "transitioning from" sources and "transition to" sources. It would add both the fade in and fade out volumes to that source, and then when the frame is complete, it would set the presentation volume to the sum of those two values, rather than set the presentation volume for that same source twice which would cause weird volume jittering and also set the wrong values.
2014-02-21 18:41:38 -08:00
/* transition volume is meant to store the sum of transitioning volumes
* of a source, i.e. if a source is within both the "to" and "from"
* targets of a transition, it would add both volumes to this variable,
* and then when the transition frame is complete, is applies the value
* to the presentation volume. */
float transition_volume;
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
/* async video data */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
texture_t output_texture;
DARRAY(struct source_frame*) video_frames;
pthread_mutex_t video_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 07:04:50 -08:00
/* filters */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
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;
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
};
bool obs_source_init_handlers(struct obs_source *source);
extern bool obs_source_init(struct obs_source *source,
const struct obs_source_info *info);
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
enum view_type {
MAIN_VIEW,
AUX_VIEW
};
extern void obs_source_activate(obs_source_t source, enum view_type type);
extern void obs_source_deactivate(obs_source_t source, enum view_type 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
extern void obs_source_video_tick(obs_source_t source, float seconds);
/* ------------------------------------------------------------------------- */
/* outputs */
struct obs_output {
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
char *name;
void *data;
struct obs_output_info info;
obs_data_t 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 07:04:50 -08:00
};
/* ------------------------------------------------------------------------- */
/* encoders */
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
struct encoder_callback {
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 (*new_packet)(void *param, struct encoder_packet *packet);
void *param;
};
struct obs_encoder {
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
char *name;
void *data;
struct obs_encoder_info info;
obs_data_t 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 07:04:50 -08:00
Revamp rendering system to allow custom rendering Originally, the rendering system was designed to only display sources and such, but I realized there would be a flaw; if you wanted to render the main viewport in a custom way, or maybe even the entire application as a graphics-based front end, you wouldn't have been able to do that. Displays have now been separated in to viewports and displays. A viewport is used to store and draw sources, a display is used to handle draw callbacks. You can even use displays without using viewports to draw custom render displays containing graphics calls if you wish, but usually they would be used in combination with source viewports at least. This requires a tiny bit more work to create simple source displays, but in the end its worth it for the added flexibility and options it brings.
2014-02-13 07:58:31 -08:00
pthread_mutex_t data_callbacks_mutex;
DARRAY(struct encoder_callback) data_callbacks;
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
};