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

482 lines
12 KiB
C
Raw Normal View History

first commit
2013-09-30 19:37:13 -07:00
/******************************************************************************
Add a way to get default settings - Implement a means of obtaining default settings for an input/output/encoder. obs_source_defaults for example will return the default settings for a particular source type. - Because C++ doesn't have designated initializers, use functions in the WASAPI plugin to register the sources instead.
2014-03-07 05:55:21 -08:00
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/>.
******************************************************************************/
#include "obs.h"
Rename obs-data.h to obs-internal.h Renaming obs-data.h to avoid confusion about its usage
2014-01-26 17:48:14 -08:00
#include "obs-internal.h"
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
static inline const struct obs_output_info *find_output(const char *id)
first commit
2013-09-30 19:37:13 -07:00
{
size_t i;
for (i = 0; i < obs->output_types.num; i++)
add names to sources, use 'id' for the internal source identifier names rather than 'name'
2013-12-20 16:23:19 -08:00
if (strcmp(obs->output_types.array[i].id, id) == 0)
first commit
2013-09-30 19:37:13 -07:00
return obs->output_types.array+i;
return NULL;
}
Add preliminary FLV/RTMP output (incomplete) - obs-outputs module: Add preliminary code to send out data, and add an FLV muxer. This time we don't really need to build the packets ourselves, we can just use the FLV muxer and send it directly to RTMP_Write and it should automatically parse the entire stream for us without us having to do much manual code at all. We'll see how it goes. - libobs: Add AVC NAL packet parsing code - libobs/media-io: Add quick helper functions for audio/video to get the width/height/fps/samplerate/etc rather than having to query the info structures each time. - libobs (obs-output.c): Change 'connect' signal to 'start' and 'stop' signals. 'start' now specifies an error code rather than whether it simply failed, that way the client can actually know *why* a failure occurred. Added those error codes to obs-defs.h. - libobs: Add a few functions to duplicate/free encoder packets
2014-04-01 11:55:18 -07:00
static const char *output_signals[] = {
"void start(ptr output, int errorcode)",
"void stop(ptr output)",
NULL
};
static bool init_output_handlers(struct obs_output *output)
{
output->signals = signal_handler_create();
if (!output->signals)
return false;
output->procs = proc_handler_create();
if (!output->procs)
return false;
signal_handler_add_array(output->signals, output_signals);
return true;
}
Add preliminary output/encoder interface - First, I redid the output interface for libobs. I feel like it's going in a pretty good direction in terms of design. Right now, the design is so that outputs and encoders are separate. One or more outputs can connect to a specific encoder to receive its data, or the output can connect directly to raw data from libobs output itself, if the output doesn't want to use a designated encoder. Data is received via callbacks set when you connect to the encoder or raw output. Multiple outputs can receive the data from a single encoder context if need be (such as for streaming to multiple channels at once, and/or recording with the same data). When an encoder is first connected to, it will connect to raw output, and start encoding. Additional connections will receive that same data being encoded as well after that. When the last encoder has disconnected, it will stop encoding. If for some reason the encoder needs to stop, it will use the callback with NULL to signal that encoding has stopped. Some of these things may be subject to change in the future, though it feels pretty good with this design so far. Will have to see how well it works out in practice versus theory. - Second, Started adding preliminary RTMP/x264 output plugin code. To speed things up, I might just make a direct raw->FFmpeg output to create a quick output plugin that we can start using for testing all the subsystems.
2014-01-16 21:34:51 -08:00
obs_output_t obs_output_create(const char *id, const char *name,
Implement settings interface for plugins Add a fairly easy to use settings interface that can be passed to plugins, and replaced the old character string system that was being used before. The new data interface allows for an easier method of getting/altering settings for plugins, and is built to be serializable to/from JSON. Also, removed another wxFormBuilder file that was no longer in use.
2014-01-27 22:14:58 -08:00
obs_data_t settings)
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
const struct obs_output_info *info = find_output(id);
first commit
2013-09-30 19:37:13 -07:00
struct obs_output *output;
if (!info) {
Be more consistent about log levels LOG_ERROR should be used in places where though recoverable (or at least something that can be handled safely), was unexpected, and may affect the user/application. LOG_WARNING should be used in places where it's not entirely unexpected, is recoverable, and doesn't really affect the user/application.
2014-02-28 19:02:29 -08:00
blog(LOG_ERROR, "Output '%s' not found", id);
first commit
2013-09-30 19:37:13 -07:00
return NULL;
}
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
output = bzalloc(sizeof(struct obs_output));
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
pthread_mutex_init_value(&output->interleaved_mutex);
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
if (pthread_mutex_init(&output->interleaved_mutex, NULL) != 0)
goto fail;
Add preliminary FLV/RTMP output (incomplete) - obs-outputs module: Add preliminary code to send out data, and add an FLV muxer. This time we don't really need to build the packets ourselves, we can just use the FLV muxer and send it directly to RTMP_Write and it should automatically parse the entire stream for us without us having to do much manual code at all. We'll see how it goes. - libobs: Add AVC NAL packet parsing code - libobs/media-io: Add quick helper functions for audio/video to get the width/height/fps/samplerate/etc rather than having to query the info structures each time. - libobs (obs-output.c): Change 'connect' signal to 'start' and 'stop' signals. 'start' now specifies an error code rather than whether it simply failed, that way the client can actually know *why* a failure occurred. Added those error codes to obs-defs.h. - libobs: Add a few functions to duplicate/free encoder packets
2014-04-01 11:55:18 -07:00
if (!init_output_handlers(output))
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
goto fail;
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
output->info = *info;
output->video = obs_video();
output->audio = obs_audio();
output->settings = obs_data_newref(settings);
Set defaults automatically Automatically query defaults for sources/outputs/encoders and set them before calling create
2014-03-16 17:42:37 -07:00
if (output->info.defaults)
output->info.defaults(output->settings);
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
output->data = info->create(output->settings, output);
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
if (!output->data)
goto fail;
first commit
2013-09-30 19:37:13 -07:00
Add preliminary output/encoder interface - First, I redid the output interface for libobs. I feel like it's going in a pretty good direction in terms of design. Right now, the design is so that outputs and encoders are separate. One or more outputs can connect to a specific encoder to receive its data, or the output can connect directly to raw data from libobs output itself, if the output doesn't want to use a designated encoder. Data is received via callbacks set when you connect to the encoder or raw output. Multiple outputs can receive the data from a single encoder context if need be (such as for streaming to multiple channels at once, and/or recording with the same data). When an encoder is first connected to, it will connect to raw output, and start encoding. Additional connections will receive that same data being encoded as well after that. When the last encoder has disconnected, it will stop encoding. If for some reason the encoder needs to stop, it will use the callback with NULL to signal that encoding has stopped. Some of these things may be subject to change in the future, though it feels pretty good with this design so far. Will have to see how well it works out in practice versus theory. - Second, Started adding preliminary RTMP/x264 output plugin code. To speed things up, I might just make a direct raw->FFmpeg output to create a quick output plugin that we can start using for testing all the subsystems.
2014-01-16 21:34:51 -08:00
output->name = bstrdup(name);
Implement settings interface for plugins Add a fairly easy to use settings interface that can be passed to plugins, and replaced the old character string system that was being used before. The new data interface allows for an easier method of getting/altering settings for plugins, and is built to be serializable to/from JSON. Also, removed another wxFormBuilder file that was no longer in use.
2014-01-27 22:14:58 -08:00
Add preliminary output/encoder interface - First, I redid the output interface for libobs. I feel like it's going in a pretty good direction in terms of design. Right now, the design is so that outputs and encoders are separate. One or more outputs can connect to a specific encoder to receive its data, or the output can connect directly to raw data from libobs output itself, if the output doesn't want to use a designated encoder. Data is received via callbacks set when you connect to the encoder or raw output. Multiple outputs can receive the data from a single encoder context if need be (such as for streaming to multiple channels at once, and/or recording with the same data). When an encoder is first connected to, it will connect to raw output, and start encoding. Additional connections will receive that same data being encoded as well after that. When the last encoder has disconnected, it will stop encoding. If for some reason the encoder needs to stop, it will use the callback with NULL to signal that encoding has stopped. Some of these things may be subject to change in the future, though it feels pretty good with this design so far. Will have to see how well it works out in practice versus theory. - Second, Started adding preliminary RTMP/x264 output plugin code. To speed things up, I might just make a direct raw->FFmpeg output to create a quick output plugin that we can start using for testing all the subsystems.
2014-01-16 21:34:51 -08:00
pthread_mutex_lock(&obs->data.outputs_mutex);
da_push_back(obs->data.outputs, &output);
pthread_mutex_unlock(&obs->data.outputs_mutex);
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
output->valid = true;
first commit
2013-09-30 19:37:13 -07:00
return output;
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
fail:
obs_output_destroy(output);
return NULL;
first commit
2013-09-30 19:37:13 -07:00
}
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
static inline void free_packets(struct obs_output *output)
{
for (size_t i = 0; i < output->interleaved_packets.num; i++)
obs_free_encoder_packet(output->interleaved_packets.array+i);
da_free(output->interleaved_packets);
}
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
void obs_output_destroy(obs_output_t output)
first commit
2013-09-30 19:37:13 -07:00
{
if (output) {
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
if (output->valid) {
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
if (output->active)
output->info.stop(output->data);
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
pthread_mutex_lock(&obs->data.outputs_mutex);
da_erase_item(obs->data.outputs, &output);
pthread_mutex_unlock(&obs->data.outputs_mutex);
Add planar audio support, improve test output - Add planar audio support. FFmpeg and libav use planar audio for many encoders, so it was somewhat necessary to add support in libobs itself. - Improve/adjust FFmpeg test output plugin. The exports were somewhat messed up (making me rethink how exports should be done). Not yet functional; it handles video properly, but it still does not handle audio properly. - Improve planar video code. The planar video code was not properly accounting for row sizes for each plane. Specifying row sizes for each plane has now been added. This will also make it more compatible with FFmpeg/libav. - Fixed a bug where callbacks wouldn't create properly in audio-io and video-io code. - Implement 'blogva' function to allow for va_list usage with libobs logging.
2014-02-07 02:03:54 -08:00
}
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
free_packets(output);
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
if (output->data)
output->info.destroy(output->data);
signal_handler_destroy(output->signals);
proc_handler_destroy(output->procs);
Add preliminary output/encoder interface - First, I redid the output interface for libobs. I feel like it's going in a pretty good direction in terms of design. Right now, the design is so that outputs and encoders are separate. One or more outputs can connect to a specific encoder to receive its data, or the output can connect directly to raw data from libobs output itself, if the output doesn't want to use a designated encoder. Data is received via callbacks set when you connect to the encoder or raw output. Multiple outputs can receive the data from a single encoder context if need be (such as for streaming to multiple channels at once, and/or recording with the same data). When an encoder is first connected to, it will connect to raw output, and start encoding. Additional connections will receive that same data being encoded as well after that. When the last encoder has disconnected, it will stop encoding. If for some reason the encoder needs to stop, it will use the callback with NULL to signal that encoding has stopped. Some of these things may be subject to change in the future, though it feels pretty good with this design so far. Will have to see how well it works out in practice versus theory. - Second, Started adding preliminary RTMP/x264 output plugin code. To speed things up, I might just make a direct raw->FFmpeg output to create a quick output plugin that we can start using for testing all the subsystems.
2014-01-16 21:34:51 -08:00
Implement settings interface for plugins Add a fairly easy to use settings interface that can be passed to plugins, and replaced the old character string system that was being used before. The new data interface allows for an easier method of getting/altering settings for plugins, and is built to be serializable to/from JSON. Also, removed another wxFormBuilder file that was no longer in use.
2014-01-27 22:14:58 -08:00
obs_data_release(output->settings);
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
pthread_mutex_destroy(&output->interleaved_mutex);
Add preliminary output/encoder interface - First, I redid the output interface for libobs. I feel like it's going in a pretty good direction in terms of design. Right now, the design is so that outputs and encoders are separate. One or more outputs can connect to a specific encoder to receive its data, or the output can connect directly to raw data from libobs output itself, if the output doesn't want to use a designated encoder. Data is received via callbacks set when you connect to the encoder or raw output. Multiple outputs can receive the data from a single encoder context if need be (such as for streaming to multiple channels at once, and/or recording with the same data). When an encoder is first connected to, it will connect to raw output, and start encoding. Additional connections will receive that same data being encoded as well after that. When the last encoder has disconnected, it will stop encoding. If for some reason the encoder needs to stop, it will use the callback with NULL to signal that encoding has stopped. Some of these things may be subject to change in the future, though it feels pretty good with this design so far. Will have to see how well it works out in practice versus theory. - Second, Started adding preliminary RTMP/x264 output plugin code. To speed things up, I might just make a direct raw->FFmpeg output to create a quick output plugin that we can start using for testing all the subsystems.
2014-01-16 21:34:51 -08:00
bfree(output->name);
first commit
2013-09-30 19:37:13 -07:00
bfree(output);
}
}
Add preliminary output/encoder interface - First, I redid the output interface for libobs. I feel like it's going in a pretty good direction in terms of design. Right now, the design is so that outputs and encoders are separate. One or more outputs can connect to a specific encoder to receive its data, or the output can connect directly to raw data from libobs output itself, if the output doesn't want to use a designated encoder. Data is received via callbacks set when you connect to the encoder or raw output. Multiple outputs can receive the data from a single encoder context if need be (such as for streaming to multiple channels at once, and/or recording with the same data). When an encoder is first connected to, it will connect to raw output, and start encoding. Additional connections will receive that same data being encoded as well after that. When the last encoder has disconnected, it will stop encoding. If for some reason the encoder needs to stop, it will use the callback with NULL to signal that encoding has stopped. Some of these things may be subject to change in the future, though it feels pretty good with this design so far. Will have to see how well it works out in practice versus theory. - Second, Started adding preliminary RTMP/x264 output plugin code. To speed things up, I might just make a direct raw->FFmpeg output to create a quick output plugin that we can start using for testing all the subsystems.
2014-01-16 21:34:51 -08:00
bool obs_output_start(obs_output_t output)
first commit
2013-09-30 19:37:13 -07:00
{
Add more checks for NULL pointers
2014-02-23 21:39:33 -08:00
return (output != NULL) ? output->info.start(output->data) : false;
first commit
2013-09-30 19:37:13 -07:00
}
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
void obs_output_stop(obs_output_t output)
first commit
2013-09-30 19:37:13 -07:00
{
Add more checks for NULL pointers
2014-02-23 21:39:33 -08:00
if (output)
output->info.stop(output->data);
first commit
2013-09-30 19:37:13 -07:00
}
Add preliminary output/encoder interface - First, I redid the output interface for libobs. I feel like it's going in a pretty good direction in terms of design. Right now, the design is so that outputs and encoders are separate. One or more outputs can connect to a specific encoder to receive its data, or the output can connect directly to raw data from libobs output itself, if the output doesn't want to use a designated encoder. Data is received via callbacks set when you connect to the encoder or raw output. Multiple outputs can receive the data from a single encoder context if need be (such as for streaming to multiple channels at once, and/or recording with the same data). When an encoder is first connected to, it will connect to raw output, and start encoding. Additional connections will receive that same data being encoded as well after that. When the last encoder has disconnected, it will stop encoding. If for some reason the encoder needs to stop, it will use the callback with NULL to signal that encoding has stopped. Some of these things may be subject to change in the future, though it feels pretty good with this design so far. Will have to see how well it works out in practice versus theory. - Second, Started adding preliminary RTMP/x264 output plugin code. To speed things up, I might just make a direct raw->FFmpeg output to create a quick output plugin that we can start using for testing all the subsystems.
2014-01-16 21:34:51 -08:00
bool obs_output_active(obs_output_t output)
first commit
2013-09-30 19:37:13 -07:00
{
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
return (output != NULL) ? output->active : false;
first commit
2013-09-30 19:37:13 -07:00
}
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
static inline obs_data_t get_defaults(const struct obs_output_info *info)
{
obs_data_t settings = obs_data_create();
if (info->defaults)
info->defaults(settings);
return settings;
}
Add a way to get default settings - Implement a means of obtaining default settings for an input/output/encoder. obs_source_defaults for example will return the default settings for a particular source type. - Because C++ doesn't have designated initializers, use functions in the WASAPI plugin to register the sources instead.
2014-03-07 05:55:21 -08:00
obs_data_t obs_output_defaults(const char *id)
{
const struct obs_output_info *info = find_output(id);
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
return (info) ? get_defaults(info) : NULL;
Add a way to get default settings - Implement a means of obtaining default settings for an input/output/encoder. obs_source_defaults for example will return the default settings for a particular source type. - Because C++ doesn't have designated initializers, use functions in the WASAPI plugin to register the sources instead.
2014-03-07 05:55:21 -08:00
}
Add source properties window (very preliminary) - Add a properties window for sources so that you can now actually edit the settings for sources. Also, display the source by itself in the window (Note: not working on mac, and possibly not working on linux). When changing the settings for a source, it will call obs_source_update on that source when you have modified any values automatically. - Add a properties 'widget', eventually I want to turn this in to a regular nice properties view like you'd see in the designer, but right now it just uses a form layout in a QScrollArea with regular controls to display the properties. It's clunky but works for the time being. - Make it so that swap chains and the main graphics subsystem will automatically use at least one backbuffer if none was specified - Fix bug where displays weren't added to the main display array - Make it so that you can get the properties of a source via the actual pointer of a source/encoder/output in addition to being able to look up properties via identifier. - When registering source types, check for required functions (wasn't doing it before). getheight/getwidth should not be optional if it's a video source as well. - Add an RAII OBSObj wrapper to obs.hpp for non-reference-counted libobs pointers - Add an RAII OBSSignal wrapper to obs.hpp for libobs signals to automatically disconnect them on destruction - Move the "scale and center" calculation in window-basic-main.cpp to its own function and in its own source file - Add an 'update' callback to WASAPI audio sources
2014-03-23 01:07:54 -07:00
obs_properties_t obs_get_output_properties(const char *id, const char *locale)
Add property list callbacks - Add property list callbacks to sources/outputs/encoders so that if necessary user interface can be automatically generated or perhaps a property list widget can be used for them. - Change some of the property API names. obs_property_list_t felt a bit awkward when actually using it, so I just renamed it to obs_properties_t. - Removed the getdata/setdata nad getparam/setparam functions from sources/services, they will be superseded by the dynamic procedure call API.
2014-02-01 21:46:13 -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
const struct obs_output_info *info = find_output(id);
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
if (info && info->properties) {
obs_data_t defaults = get_defaults(info);
obs_properties_t properties;
properties = info->properties(locale);
obs_properties_apply_settings(properties, defaults);
obs_data_release(defaults);
return properties;
}
Add property list callbacks - Add property list callbacks to sources/outputs/encoders so that if necessary user interface can be automatically generated or perhaps a property list widget can be used for them. - Change some of the property API names. obs_property_list_t felt a bit awkward when actually using it, so I just renamed it to obs_properties_t. - Removed the getdata/setdata nad getparam/setparam functions from sources/services, they will be superseded by the dynamic procedure call API.
2014-02-01 21:46:13 -08:00
return NULL;
}
Add source properties window (very preliminary) - Add a properties window for sources so that you can now actually edit the settings for sources. Also, display the source by itself in the window (Note: not working on mac, and possibly not working on linux). When changing the settings for a source, it will call obs_source_update on that source when you have modified any values automatically. - Add a properties 'widget', eventually I want to turn this in to a regular nice properties view like you'd see in the designer, but right now it just uses a form layout in a QScrollArea with regular controls to display the properties. It's clunky but works for the time being. - Make it so that swap chains and the main graphics subsystem will automatically use at least one backbuffer if none was specified - Fix bug where displays weren't added to the main display array - Make it so that you can get the properties of a source via the actual pointer of a source/encoder/output in addition to being able to look up properties via identifier. - When registering source types, check for required functions (wasn't doing it before). getheight/getwidth should not be optional if it's a video source as well. - Add an RAII OBSObj wrapper to obs.hpp for non-reference-counted libobs pointers - Add an RAII OBSSignal wrapper to obs.hpp for libobs signals to automatically disconnect them on destruction - Move the "scale and center" calculation in window-basic-main.cpp to its own function and in its own source file - Add an 'update' callback to WASAPI audio sources
2014-03-23 01:07:54 -07:00
obs_properties_t obs_output_properties(obs_output_t output, const char *locale)
{
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
if (output && output->info.properties) {
obs_properties_t props;
props = output->info.properties(locale);
obs_properties_apply_settings(props, output->settings);
return props;
}
Add source properties window (very preliminary) - Add a properties window for sources so that you can now actually edit the settings for sources. Also, display the source by itself in the window (Note: not working on mac, and possibly not working on linux). When changing the settings for a source, it will call obs_source_update on that source when you have modified any values automatically. - Add a properties 'widget', eventually I want to turn this in to a regular nice properties view like you'd see in the designer, but right now it just uses a form layout in a QScrollArea with regular controls to display the properties. It's clunky but works for the time being. - Make it so that swap chains and the main graphics subsystem will automatically use at least one backbuffer if none was specified - Fix bug where displays weren't added to the main display array - Make it so that you can get the properties of a source via the actual pointer of a source/encoder/output in addition to being able to look up properties via identifier. - When registering source types, check for required functions (wasn't doing it before). getheight/getwidth should not be optional if it's a video source as well. - Add an RAII OBSObj wrapper to obs.hpp for non-reference-counted libobs pointers - Add an RAII OBSSignal wrapper to obs.hpp for libobs signals to automatically disconnect them on destruction - Move the "scale and center" calculation in window-basic-main.cpp to its own function and in its own source file - Add an 'update' callback to WASAPI audio sources
2014-03-23 01:07:54 -07:00
return NULL;
}
Implement settings interface for plugins Add a fairly easy to use settings interface that can be passed to plugins, and replaced the old character string system that was being used before. The new data interface allows for an easier method of getting/altering settings for plugins, and is built to be serializable to/from JSON. Also, removed another wxFormBuilder file that was no longer in use.
2014-01-27 22:14:58 -08:00
void obs_output_update(obs_output_t output, obs_data_t settings)
first commit
2013-09-30 19:37:13 -07:00
{
Add more checks for NULL pointers
2014-02-23 21:39:33 -08:00
if (!output) return;
For *_update, apply settings instead of replacing Make it so obs_data settings input in to *_update are applied to the existing settings rather than fully replace the existing settings. That way you can update with only certain specific settings, leaving other settings untouched. Of course if you're already using the original settings pointer in the first place then you've already done that, so it'll just ignore it because you've already applied them.
2014-02-21 20:05:21 -08:00
obs_data_apply(output->settings, settings);
Add a couple more setting data safety measures Prevent null dereferencing if data is null, instead just make the functions return and ignore the get/set requests.
2014-01-28 14:45:30 -08:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
if (output->info.update)
output->info.update(output->data, output->settings);
first commit
2013-09-30 19:37:13 -07:00
}
Do test recording to a specified file It will now output to a a filename that you specify when you click the record button. This is just for testing.
2014-02-10 09:22:35 -08:00
obs_data_t obs_output_get_settings(obs_output_t output)
{
if (!output)
return NULL;
obs_data_addref(output->settings);
return output->settings;
}
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
bool obs_output_canpause(obs_output_t output)
first commit
2013-09-30 19:37:13 -07:00
{
Implement encoder interface (still preliminary) - Implement OBS encoder interface. It was previously incomplete, but now is reaching some level of completion, though probably should still be considered preliminary. I had originally implemented it so that encoders only have a 'reset' function to reset their parameters, but I felt that having both a 'start' and 'stop' function would be useful. Encoders are now assigned to a specific video/audio media output each rather than implicitely assigned to the main obs video/audio contexts. This allows separate encoder contexts that aren't necessarily assigned to the main video/audio context (which is useful for things such as recording specific sources). Will probably have to do this for regular obs outputs as well. When creating an encoder, you must now explicitely state whether that encoder is an audio or video encoder. Audio and video can optionally be automatically converted depending on what the encoder specifies. When something 'attaches' to an encoder, the first attachment starts the encoder, and the encoder automatically attaches to the media output context associated with it. Subsequent attachments won't have the same effect, they will just start receiving the same encoder data when the next keyframe plays (along with SEI if any). When detaching from the encoder, the last detachment will fully stop the encoder and detach the encoder from the media output context associated with the encoder. SEI must actually be exported separately; because new encoder attachments may not always be at the beginning of the stream, the first keyframe they get must have that SEI data in it. If the encoder has SEI data, it needs only add one small function to simply query that SEI data, and then that data will be handled automatically by libobs for all subsequent encoder attachments. - Implement x264 encoder plugin, move x264 files to separate plugin to separate necessary dependencies. - Change video/audio frame output structures to not use const qualifiers to prevent issues with non-const function usage elsewhere. This was an issue when writing the x264 encoder, as the x264 encoder expects non-const frame data. Change stagesurf_map to return a non-const data type to prevent this as well. - Change full range parameter of video scaler to be an enum rather than boolean
2014-03-16 16:21:34 -07:00
return output ? (output->info.pause != NULL) : false;
first commit
2013-09-30 19:37:13 -07:00
}
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
void obs_output_pause(obs_output_t output)
first commit
2013-09-30 19:37:13 -07:00
{
Add more checks for NULL pointers
2014-02-23 21:39:33 -08:00
if (output && output->info.pause)
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
output->info.pause(output->data);
first commit
2013-09-30 19:37:13 -07:00
}
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
signal_handler_t obs_output_signalhandler(obs_output_t output)
{
Implement encoder interface (still preliminary) - Implement OBS encoder interface. It was previously incomplete, but now is reaching some level of completion, though probably should still be considered preliminary. I had originally implemented it so that encoders only have a 'reset' function to reset their parameters, but I felt that having both a 'start' and 'stop' function would be useful. Encoders are now assigned to a specific video/audio media output each rather than implicitely assigned to the main obs video/audio contexts. This allows separate encoder contexts that aren't necessarily assigned to the main video/audio context (which is useful for things such as recording specific sources). Will probably have to do this for regular obs outputs as well. When creating an encoder, you must now explicitely state whether that encoder is an audio or video encoder. Audio and video can optionally be automatically converted depending on what the encoder specifies. When something 'attaches' to an encoder, the first attachment starts the encoder, and the encoder automatically attaches to the media output context associated with it. Subsequent attachments won't have the same effect, they will just start receiving the same encoder data when the next keyframe plays (along with SEI if any). When detaching from the encoder, the last detachment will fully stop the encoder and detach the encoder from the media output context associated with the encoder. SEI must actually be exported separately; because new encoder attachments may not always be at the beginning of the stream, the first keyframe they get must have that SEI data in it. If the encoder has SEI data, it needs only add one small function to simply query that SEI data, and then that data will be handled automatically by libobs for all subsequent encoder attachments. - Implement x264 encoder plugin, move x264 files to separate plugin to separate necessary dependencies. - Change video/audio frame output structures to not use const qualifiers to prevent issues with non-const function usage elsewhere. This was an issue when writing the x264 encoder, as the x264 encoder expects non-const frame data. Change stagesurf_map to return a non-const data type to prevent this as well. - Change full range parameter of video scaler to be an enum rather than boolean
2014-03-16 16:21:34 -07:00
return output ? output->signals : NULL;
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
}
proc_handler_t obs_output_prochandler(obs_output_t output)
{
Implement encoder interface (still preliminary) - Implement OBS encoder interface. It was previously incomplete, but now is reaching some level of completion, though probably should still be considered preliminary. I had originally implemented it so that encoders only have a 'reset' function to reset their parameters, but I felt that having both a 'start' and 'stop' function would be useful. Encoders are now assigned to a specific video/audio media output each rather than implicitely assigned to the main obs video/audio contexts. This allows separate encoder contexts that aren't necessarily assigned to the main video/audio context (which is useful for things such as recording specific sources). Will probably have to do this for regular obs outputs as well. When creating an encoder, you must now explicitely state whether that encoder is an audio or video encoder. Audio and video can optionally be automatically converted depending on what the encoder specifies. When something 'attaches' to an encoder, the first attachment starts the encoder, and the encoder automatically attaches to the media output context associated with it. Subsequent attachments won't have the same effect, they will just start receiving the same encoder data when the next keyframe plays (along with SEI if any). When detaching from the encoder, the last detachment will fully stop the encoder and detach the encoder from the media output context associated with the encoder. SEI must actually be exported separately; because new encoder attachments may not always be at the beginning of the stream, the first keyframe they get must have that SEI data in it. If the encoder has SEI data, it needs only add one small function to simply query that SEI data, and then that data will be handled automatically by libobs for all subsequent encoder attachments. - Implement x264 encoder plugin, move x264 files to separate plugin to separate necessary dependencies. - Change video/audio frame output structures to not use const qualifiers to prevent issues with non-const function usage elsewhere. This was an issue when writing the x264 encoder, as the x264 encoder expects non-const frame data. Change stagesurf_map to return a non-const data type to prevent this as well. - Change full range parameter of video scaler to be an enum rather than boolean
2014-03-16 16:21:34 -07:00
return output ? output->procs : NULL;
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
}
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
void obs_output_set_media(obs_output_t output, video_t video, audio_t audio)
{
if (!output)
return;
output->video = video;
output->audio = audio;
}
video_t obs_output_video(obs_output_t output)
{
return output ? output->video : NULL;
}
audio_t obs_output_audio(obs_output_t output)
{
return output ? output->audio : NULL;
}
void obs_output_remove_encoder(struct obs_output *output,
struct obs_encoder *encoder)
{
if (!output) return;
if (output->video_encoder == encoder)
output->video_encoder = NULL;
else if (output->audio_encoder == encoder)
output->audio_encoder = NULL;
}
void obs_output_set_video_encoder(obs_output_t output, obs_encoder_t encoder)
{
if (!output) return;
if (output->video_encoder == encoder) return;
if (encoder && encoder->info.type != OBS_ENCODER_VIDEO) return;
obs_encoder_remove_output(encoder, output);
obs_encoder_add_output(encoder, output);
output->video_encoder = encoder;
}
void obs_output_set_audio_encoder(obs_output_t output, obs_encoder_t encoder)
{
if (!output) return;
if (output->audio_encoder == encoder) return;
if (encoder && encoder->info.type != OBS_ENCODER_AUDIO) return;
obs_encoder_remove_output(encoder, output);
obs_encoder_add_output(encoder, output);
output->audio_encoder = encoder;
}
obs_encoder_t obs_output_get_video_encoder(obs_output_t output)
{
return output ? output->video_encoder : NULL;
}
obs_encoder_t obs_output_get_audio_encoder(obs_output_t output)
{
return output ? output->audio_encoder : NULL;
}
void obs_output_set_video_conversion(obs_output_t output,
const struct video_scale_info *conversion)
{
if (!output || !conversion) return;
output->video_conversion = *conversion;
output->video_conversion_set = true;
}
void obs_output_set_audio_conversion(obs_output_t output,
const struct audio_convert_info *conversion)
{
if (!output || !conversion) return;
output->audio_conversion = *conversion;
output->audio_conversion_set = true;
}
static bool can_begin_data_capture(struct obs_output *output, bool encoded,
bool has_video, bool has_audio)
{
if (has_video) {
if (encoded) {
if (!output->video_encoder)
return false;
} else {
if (!output->video)
return false;
}
}
if (has_audio) {
if (encoded) {
if (!output->audio_encoder)
return false;
} else {
if (!output->audio)
return false;
}
}
return true;
}
static inline struct video_scale_info *get_video_conversion(
struct obs_output *output)
{
return output->video_conversion_set ? &output->video_conversion : NULL;
}
static inline struct audio_convert_info *get_audio_conversion(
struct obs_output *output)
{
return output->audio_conversion_set ? &output->audio_conversion : NULL;
}
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
static void interleave_packets(void *data, struct encoder_packet *packet)
{
}
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
static void hook_data_capture(struct obs_output *output, bool encoded,
bool has_video, bool has_audio)
{
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
void (*encoded_callback)(void *data, struct encoder_packet *packet);
void *param;
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
if (encoded) {
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
encoded_callback = (has_video && has_audio) ?
interleave_packets : output->info.encoded_packet;
param = (has_video && has_audio) ? output : output->data;
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
if (has_video)
obs_encoder_start(output->video_encoder,
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
encoded_callback, param);
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
if (has_audio)
obs_encoder_start(output->audio_encoder,
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
encoded_callback, param);
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
} else {
if (has_video)
video_output_connect(output->video,
get_video_conversion(output),
output->info.raw_video,
output->data);
if (has_audio)
audio_output_connect(output->audio,
get_audio_conversion(output),
output->info.raw_audio,
output->data);
}
}
Add preliminary FLV/RTMP output (incomplete) - obs-outputs module: Add preliminary code to send out data, and add an FLV muxer. This time we don't really need to build the packets ourselves, we can just use the FLV muxer and send it directly to RTMP_Write and it should automatically parse the entire stream for us without us having to do much manual code at all. We'll see how it goes. - libobs: Add AVC NAL packet parsing code - libobs/media-io: Add quick helper functions for audio/video to get the width/height/fps/samplerate/etc rather than having to query the info structures each time. - libobs (obs-output.c): Change 'connect' signal to 'start' and 'stop' signals. 'start' now specifies an error code rather than whether it simply failed, that way the client can actually know *why* a failure occurred. Added those error codes to obs-defs.h. - libobs: Add a few functions to duplicate/free encoder packets
2014-04-01 11:55:18 -07:00
static inline void signal_start(struct obs_output *output, int code)
{
struct calldata params = {0};
calldata_setint(&params, "code", code);
calldata_setptr(&params, "output", output);
signal_handler_signal(output->signals, "start", &params);
calldata_free(&params);
}
static inline void signal_stop(struct obs_output *output)
{
struct calldata params = {0};
calldata_setptr(&params, "output", output);
signal_handler_signal(output->signals, "stop", &params);
calldata_free(&params);
}
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
static inline void convert_flags(struct obs_output *output, uint32_t flags,
bool *encoded, bool *has_video, bool *has_audio)
{
*encoded = (output->info.flags & OBS_OUTPUT_ENCODED) != 0;
if (!flags)
flags = output->info.flags;
else
flags &= output->info.flags;
*has_video = (flags & OBS_OUTPUT_VIDEO) != 0;
*has_audio = (flags & OBS_OUTPUT_AUDIO) != 0;
}
Add preliminary FLV/RTMP output (incomplete) - obs-outputs module: Add preliminary code to send out data, and add an FLV muxer. This time we don't really need to build the packets ourselves, we can just use the FLV muxer and send it directly to RTMP_Write and it should automatically parse the entire stream for us without us having to do much manual code at all. We'll see how it goes. - libobs: Add AVC NAL packet parsing code - libobs/media-io: Add quick helper functions for audio/video to get the width/height/fps/samplerate/etc rather than having to query the info structures each time. - libobs (obs-output.c): Change 'connect' signal to 'start' and 'stop' signals. 'start' now specifies an error code rather than whether it simply failed, that way the client can actually know *why* a failure occurred. Added those error codes to obs-defs.h. - libobs: Add a few functions to duplicate/free encoder packets
2014-04-01 11:55:18 -07:00
bool obs_output_can_begin_data_capture(obs_output_t output, uint32_t flags)
{
bool encoded, has_video, has_audio;
if (!output) return false;
if (output->active) return false;
convert_flags(output, flags, &encoded, &has_video, &has_audio);
return can_begin_data_capture(output, encoded, has_video, has_audio);
}
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
bool obs_output_begin_data_capture(obs_output_t output, uint32_t flags)
{
bool encoded, has_video, has_audio;
if (!output) return false;
if (output->active) return false;
convert_flags(output, flags, &encoded, &has_video, &has_audio);
if (!can_begin_data_capture(output, encoded, has_video, has_audio))
return false;
hook_data_capture(output, encoded, has_video, has_audio);
output->active = true;
Add preliminary FLV/RTMP output (incomplete) - obs-outputs module: Add preliminary code to send out data, and add an FLV muxer. This time we don't really need to build the packets ourselves, we can just use the FLV muxer and send it directly to RTMP_Write and it should automatically parse the entire stream for us without us having to do much manual code at all. We'll see how it goes. - libobs: Add AVC NAL packet parsing code - libobs/media-io: Add quick helper functions for audio/video to get the width/height/fps/samplerate/etc rather than having to query the info structures each time. - libobs (obs-output.c): Change 'connect' signal to 'start' and 'stop' signals. 'start' now specifies an error code rather than whether it simply failed, that way the client can actually know *why* a failure occurred. Added those error codes to obs-defs.h. - libobs: Add a few functions to duplicate/free encoder packets
2014-04-01 11:55:18 -07:00
signal_start(output, OBS_OUTPUT_SUCCESS);
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
return true;
}
void obs_output_end_data_capture(obs_output_t output)
{
bool encoded, has_video, has_audio;
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
void (*encoded_callback)(void *data, struct encoder_packet *packet);
void *param;
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
if (!output) return;
if (!output->active) return;
convert_flags(output, 0, &encoded, &has_video, &has_audio);
if (encoded) {
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
encoded_callback = (has_video && has_audio) ?
interleave_packets : output->info.encoded_packet;
param = (has_video && has_audio) ? output : output->data;
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
if (has_video)
obs_encoder_stop(output->video_encoder,
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
encoded_callback, param);
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
if (has_audio)
obs_encoder_stop(output->audio_encoder,
Improve properties API Improve the properties API so that it can actually respond somewhat to user input. Maybe later this might be further improved or replaced with something script-based. When creating a property, you can now add a callback to that property that notifies when the property has been changed in the user interface. Return true if you want the properties to be refreshed, or false if not. Though now that I think about it I doubt there would ever be a case where you would have this callback and *not* refresh the properties. Regardless, this allows functions to change the values of properties or settings, or enable/disable/hide other property controls from view dynamically.
2014-04-04 00:30:37 -07:00
encoded_callback, param);
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
} else {
if (has_video)
video_output_disconnect(output->video,
output->info.raw_video,
output->data);
if (has_audio)
audio_output_disconnect(output->audio,
output->info.raw_audio,
output->data);
}
output->active = false;
Add preliminary FLV/RTMP output (incomplete) - obs-outputs module: Add preliminary code to send out data, and add an FLV muxer. This time we don't really need to build the packets ourselves, we can just use the FLV muxer and send it directly to RTMP_Write and it should automatically parse the entire stream for us without us having to do much manual code at all. We'll see how it goes. - libobs: Add AVC NAL packet parsing code - libobs/media-io: Add quick helper functions for audio/video to get the width/height/fps/samplerate/etc rather than having to query the info structures each time. - libobs (obs-output.c): Change 'connect' signal to 'start' and 'stop' signals. 'start' now specifies an error code rather than whether it simply failed, that way the client can actually know *why* a failure occurred. Added those error codes to obs-defs.h. - libobs: Add a few functions to duplicate/free encoder packets
2014-04-01 11:55:18 -07:00
signal_stop(output);
}
void obs_output_signal_start_fail(obs_output_t output, int code)
{
signal_start(output, code);
Implement encoder usage with outputs - Make it so that encoders can be assigned to outputs. If an encoder is destroyed, it will automatically remove itself from that output. I specifically didn't want to do reference counting because it leaves too much potential for unchecked references and it just felt like it would be more trouble than it's worth. - Add a 'flags' value to the output definition structure. This lets the output specify if it uses video/audio, and whether the output is meant to be used with OBS encoders or not. - Remove boilerplate code for outputs. This makes it easier to program outputs. The boilerplate code involved before was mostly just involving connecting to the audio/video data streams directly in each output plugin. Instead of doing that, simply add plugin callback functions for receiving video/audio (either encoded or non-encoded, whichever it's set to use), and then call obs_output_begin_data_capture and obs_output_end_data_capture to automatically handle setting up connections to raw or encoded video/audio streams for the plugin. - Remove 'active' function from output callbacks, as it's no longer really needed now that the libobs output context automatically knows when the output is active or not. - Make it so that an encoder cannot be destroyed until all data connections to the encoder have been removed. - Change the 'start' and 'stop' functions in the encoder interface to just an 'initialize' callback, which initializes the encoder. - Make it so that the encoder must be initialized first before the data stream can be started. The reason why initialization was separated from starting the encoder stream was because we need to be able to check that the settings used with the encoder *can* be used first. This problem was especially annoying if you had both video/audio encoding. Before, you'd have to check the return value from obs_encoder_start, and if that second encoder fails, then you basically had to stop the first encoder again, making for unnecessary boilerplate code whenever starting up two encoders.
2014-03-27 21:50:15 -07:00
}