2013-09-30 19:37:13 -07:00
|
|
|
/******************************************************************************
|
2014-03-23 01:07:54 -07:00
|
|
|
Copyright (C) 2013-2014 by Hugh Bailey <obs.jim@gmail.com>
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
This program is free software: you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2013-12-02 21:24:38 -08:00
|
|
|
the Free Software Foundation, either version 2 of the License, or
|
2013-09-30 19:37:13 -07:00
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
******************************************************************************/
|
|
|
|
|
2013-10-14 04:21:15 -07:00
|
|
|
#pragma once
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
#include "util/c99defs.h"
|
2013-12-30 09:14:28 -08:00
|
|
|
#include "util/bmem.h"
|
2013-09-30 19:37:13 -07:00
|
|
|
#include "graphics/graphics.h"
|
|
|
|
#include "graphics/vec2.h"
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
#include "media-io/audio-io.h"
|
|
|
|
#include "media-io/video-io.h"
|
2013-12-26 22:10:15 -08:00
|
|
|
#include "callback/signal.h"
|
|
|
|
#include "callback/proc.h"
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2014-02-12 11:57:51 -08:00
|
|
|
#include "obs-defs.h"
|
|
|
|
#include "obs-data.h"
|
|
|
|
#include "obs-ui.h"
|
|
|
|
#include "obs-properties.h"
|
|
|
|
|
Revamp API and start using doxygen
The API used to be designed in such a way to where it would expect
exports for each individual source/output/encoder/etc. You would export
functions for each and it would automatically load those functions based
on a specific naming scheme from the module.
The idea behind this was that I wanted to limit the usage of structures
in the API so only functions could be used. It was an interesting idea
in theory, but this idea turned out to be flawed in a number of ways:
1.) Requiring exports to create sources/outputs/encoders/etc meant that
you could not create them by any other means, which meant that
things like faruton's .net plugin would become difficult.
2.) Export function declarations could not be checked, therefore if you
created a function with the wrong parameters and parameter types,
the compiler wouldn't know how to check for that.
3.) Required overly complex load functions in libobs just to handle it.
It makes much more sense to just have a load function that you call
manually. Complexity is the bane of all good programs.
4.) It required that you have functions of specific names, which looked
and felt somewhat unsightly.
So, to fix these issues, I replaced it with a more commonly used API
scheme, seen commonly in places like kernels and typical C libraries
with abstraction. You simply create a structure that contains the
callback definitions, and you pass it to a function to register that
definition (such as obs_register_source), which you call in the
obs_module_load of the module.
It will also automatically check the structure size and ensure that it
only loads the required values if the structure happened to add new
values in an API change.
The "main" source file for each module must include obs-module.h, and
must use OBS_DECLARE_MODULE() within that source file.
Also, started writing some doxygen documentation in to the main library
headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
|
|
|
/* opaque types */
|
|
|
|
struct obs_display;
|
2014-02-13 09:21:16 -08:00
|
|
|
struct obs_view;
|
Revamp API and start using doxygen
The API used to be designed in such a way to where it would expect
exports for each individual source/output/encoder/etc. You would export
functions for each and it would automatically load those functions based
on a specific naming scheme from the module.
The idea behind this was that I wanted to limit the usage of structures
in the API so only functions could be used. It was an interesting idea
in theory, but this idea turned out to be flawed in a number of ways:
1.) Requiring exports to create sources/outputs/encoders/etc meant that
you could not create them by any other means, which meant that
things like faruton's .net plugin would become difficult.
2.) Export function declarations could not be checked, therefore if you
created a function with the wrong parameters and parameter types,
the compiler wouldn't know how to check for that.
3.) Required overly complex load functions in libobs just to handle it.
It makes much more sense to just have a load function that you call
manually. Complexity is the bane of all good programs.
4.) It required that you have functions of specific names, which looked
and felt somewhat unsightly.
So, to fix these issues, I replaced it with a more commonly used API
scheme, seen commonly in places like kernels and typical C libraries
with abstraction. You simply create a structure that contains the
callback definitions, and you pass it to a function to register that
definition (such as obs_register_source), which you call in the
obs_module_load of the module.
It will also automatically check the structure size and ensure that it
only loads the required values if the structure happened to add new
values in an API change.
The "main" source file for each module must include obs-module.h, and
must use OBS_DECLARE_MODULE() within that source file.
Also, started writing some doxygen documentation in to the main library
headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
|
|
|
struct obs_source;
|
|
|
|
struct obs_scene;
|
|
|
|
struct obs_scene_item;
|
|
|
|
struct obs_output;
|
|
|
|
struct obs_encoder;
|
|
|
|
struct obs_service;
|
|
|
|
|
|
|
|
typedef struct obs_display *obs_display_t;
|
2014-03-23 01:07:54 -07:00
|
|
|
typedef struct obs_view *obs_view_t;
|
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
|
|
|
typedef struct obs_source *obs_source_t;
|
|
|
|
typedef struct obs_scene *obs_scene_t;
|
|
|
|
typedef struct obs_scene_item *obs_sceneitem_t;
|
|
|
|
typedef struct obs_output *obs_output_t;
|
|
|
|
typedef struct obs_encoder *obs_encoder_t;
|
|
|
|
typedef struct obs_service *obs_service_t;
|
|
|
|
|
|
|
|
#include "obs-source.h"
|
|
|
|
#include "obs-encoder.h"
|
|
|
|
#include "obs-output.h"
|
|
|
|
#include "obs-service.h"
|
2014-01-31 23:49:50 -08:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/*
|
2014-02-13 04:27:35 -08:00
|
|
|
* @file
|
|
|
|
*
|
2013-09-30 19:37:13 -07:00
|
|
|
* Main libobs header used by applications.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2014-05-04 23:04:35 -07:00
|
|
|
/*
|
|
|
|
* LIBOBS_API_VER is returned by module_version in each module.
|
|
|
|
*
|
|
|
|
* Libobs uses semantic versioning. See http://semver.org/ for more
|
|
|
|
* information.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Increment if major breaking API changes
|
|
|
|
*/
|
|
|
|
#define LIBOBS_API_MAJOR_VER 0 /* 0 means development, anything can break */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Increment if backward-compatible additions
|
|
|
|
*
|
|
|
|
* Reset to zero each major version
|
|
|
|
*/
|
|
|
|
#define LIBOBS_API_MINOR_VER 2
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Increment if backward-compatible bug fix
|
|
|
|
*
|
|
|
|
* Reset to zero each major or minor version
|
|
|
|
*/
|
2014-05-18 17:44:10 -07:00
|
|
|
#define LIBOBS_API_PATCH_VER 3
|
2013-11-13 05:24:20 -08:00
|
|
|
|
2014-05-04 23:04:35 -07:00
|
|
|
#define LIBOBS_API_VER ((LIBOBS_API_MAJOR_VER << 24) | \
|
|
|
|
(LIBOBS_API_MINOR_VER << 16) | \
|
|
|
|
LIBOBS_API_PATCH_VER )
|
2013-11-13 05:24:20 -08:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/** Used for changing the order of items (for example, filters in a source,
|
2013-10-24 01:03:45 -07:00
|
|
|
* or items in a scene) */
|
2013-09-30 19:37:13 -07:00
|
|
|
enum order_movement {
|
|
|
|
ORDER_MOVE_UP,
|
|
|
|
ORDER_MOVE_DOWN,
|
|
|
|
ORDER_MOVE_TOP,
|
|
|
|
ORDER_MOVE_BOTTOM
|
|
|
|
};
|
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/**
|
|
|
|
* Used with obs_source_process_filter to specify whether the filter should
|
|
|
|
* render the source directly with the specified effect, or whether it should
|
|
|
|
* render it to a texture
|
|
|
|
*/
|
2013-12-22 01:03:40 -08:00
|
|
|
enum allow_direct_render {
|
|
|
|
NO_DIRECT_RENDERING,
|
|
|
|
ALLOW_DIRECT_RENDERING,
|
|
|
|
};
|
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/**
|
|
|
|
* Video initialization structure
|
|
|
|
*/
|
2013-11-20 14:00:16 -08:00
|
|
|
struct obs_video_info {
|
2014-02-13 04:27:35 -08:00
|
|
|
/**
|
|
|
|
* Graphics module to use (usually "libobs-opengl" or
|
|
|
|
* "libobs-d3d11")
|
|
|
|
*/
|
2013-11-20 14:00:16 -08:00
|
|
|
const char *graphics_module;
|
2013-11-26 21:20:11 -08:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
uint32_t fps_num; /**< Output FPS numerator */
|
|
|
|
uint32_t fps_den; /**< Output FPS denominator */
|
2013-11-26 21:20:11 -08:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
uint32_t window_width; /**< Window width */
|
|
|
|
uint32_t window_height; /**< Window height */
|
2013-11-26 21:20:11 -08:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
uint32_t base_width; /**< Base compositing width */
|
|
|
|
uint32_t base_height; /**< Base compositing height */
|
2013-11-26 21:20:11 -08:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
uint32_t output_width; /**< Output width */
|
|
|
|
uint32_t output_height; /**< Output height */
|
|
|
|
enum video_format output_format; /**< Output format */
|
2013-11-26 21:20:11 -08:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/** Video adapter index to use (NOTE: avoid for optimus laptops) */
|
2013-11-20 14:00:16 -08:00
|
|
|
uint32_t adapter;
|
2013-11-26 21:20:11 -08:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
struct gs_window window; /**< Window to render to */
|
2014-02-16 18:28:21 -08:00
|
|
|
|
|
|
|
/** Use shaders to convert to different color formats */
|
|
|
|
bool gpu_conversion;
|
2013-11-20 14:00:16 -08:00
|
|
|
};
|
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/**
|
|
|
|
* Sent to source filters via the filter_audio callback to allow filtering of
|
|
|
|
* audio data
|
|
|
|
*/
|
2013-10-31 10:28:47 -07:00
|
|
|
struct filtered_audio {
|
2014-02-14 14:13:36 -08:00
|
|
|
uint8_t *data[MAX_AV_PLANES];
|
2013-10-31 10:28:47 -07:00
|
|
|
uint32_t frames;
|
|
|
|
uint64_t timestamp;
|
|
|
|
};
|
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/**
|
|
|
|
* Source audio output structure. Used with obs_source_output_audio to output
|
|
|
|
* source audio. Audio is automatically resampled and remixed as necessary.
|
|
|
|
*/
|
2013-10-24 00:57:55 -07:00
|
|
|
struct source_audio {
|
2014-02-14 14:13:36 -08:00
|
|
|
const uint8_t *data[MAX_AV_PLANES];
|
2013-10-30 17:07:01 -07:00
|
|
|
uint32_t frames;
|
2013-10-24 00:57:55 -07:00
|
|
|
|
2013-10-30 17:07:01 -07:00
|
|
|
enum speaker_layout speakers;
|
2013-10-31 10:28:47 -07:00
|
|
|
enum audio_format format;
|
2013-10-30 17:07:01 -07:00
|
|
|
uint32_t samples_per_sec;
|
2013-10-24 00:57:55 -07:00
|
|
|
|
2013-10-30 17:07:01 -07:00
|
|
|
uint64_t timestamp;
|
2013-10-24 00:57:55 -07:00
|
|
|
};
|
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/**
|
|
|
|
* Source asynchronous video output structure. Used with
|
|
|
|
* obs_source_output_video to output asynchronous video. Video is buffered as
|
|
|
|
* necessary to play according to timestamps. When used with audio output,
|
|
|
|
* audio is synced to video as it is played.
|
|
|
|
*
|
|
|
|
* If a YUV format is specified, it will be automatically upsampled and
|
|
|
|
* converted to RGB via shader on the graphics processor.
|
|
|
|
*/
|
2013-10-24 00:57:55 -07:00
|
|
|
struct source_frame {
|
2014-02-14 14:13:36 -08:00
|
|
|
uint8_t *data[MAX_AV_PLANES];
|
|
|
|
uint32_t linesize[MAX_AV_PLANES];
|
2013-10-30 17:07:01 -07:00
|
|
|
uint32_t width;
|
|
|
|
uint32_t height;
|
|
|
|
uint64_t timestamp;
|
|
|
|
|
2013-10-31 10:28:47 -07:00
|
|
|
enum video_format format;
|
2014-02-05 19:36:21 -08:00
|
|
|
float color_matrix[16];
|
2014-04-23 15:24:51 -07:00
|
|
|
bool full_range;
|
|
|
|
float color_range_min[3];
|
|
|
|
float color_range_max[3];
|
2013-10-30 17:07:01 -07:00
|
|
|
bool flip;
|
2013-10-24 00:57:55 -07:00
|
|
|
};
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* OBS context */
|
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/** Initializes OBS */
|
2013-11-20 14:00:16 -08:00
|
|
|
EXPORT bool obs_startup(void);
|
2014-02-13 04:27:35 -08:00
|
|
|
|
|
|
|
/** Releases all data associated with OBS and terminates the OBS context */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_shutdown(void);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2014-02-13 07:58:31 -08:00
|
|
|
/** @return true if the main OBS context has been initialized */
|
|
|
|
EXPORT bool obs_initialized(void);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
|
|
|
* Sets base video ouput base resolution/fps/format
|
|
|
|
*
|
2014-02-13 04:27:35 -08:00
|
|
|
* @note Cannot set base video if an output is currently active.
|
2013-09-30 19:37:13 -07:00
|
|
|
*/
|
2013-11-20 14:00:16 -08:00
|
|
|
EXPORT bool obs_reset_video(struct obs_video_info *ovi);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
|
|
|
* Sets base audio output format/channels/samples/etc
|
|
|
|
*
|
2014-02-13 04:27:35 -08:00
|
|
|
* @note Cannot reset base audio if an output is currently active.
|
2013-09-30 19:37:13 -07:00
|
|
|
*/
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
EXPORT bool obs_reset_audio(struct audio_output_info *ai);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/** Gets the current video settings, returns false if no video */
|
2013-12-06 05:38:19 -08:00
|
|
|
EXPORT bool obs_get_video_info(struct obs_video_info *ovi);
|
|
|
|
|
2014-02-13 04:27:35 -08:00
|
|
|
/** Gets the current audio settings, returns false if no audio */
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
EXPORT bool obs_get_audio_info(struct audio_output_info *ai);
|
2013-12-06 05:38:19 -08:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
|
|
|
* Loads a plugin module
|
|
|
|
*
|
|
|
|
* A plugin module contains exports for inputs/fitlers/transitions/outputs.
|
|
|
|
* See obs-source.h and obs-output.h for more information on the exports to
|
|
|
|
* use.
|
|
|
|
*/
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT int obs_load_module(const char *path);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
/**
|
2013-11-22 15:18:31 -08:00
|
|
|
* Enumerates all available inputs source types.
|
2013-09-30 19:37:13 -07:00
|
|
|
*
|
|
|
|
* Inputs are general source inputs (such as capture sources, device sources,
|
|
|
|
* etc).
|
|
|
|
*/
|
2013-12-20 16:23:19 -08:00
|
|
|
EXPORT bool obs_enum_input_types(size_t idx, const char **id);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
2013-11-22 15:18:31 -08:00
|
|
|
* Enumerates all available filter source types.
|
2013-09-30 19:37:13 -07:00
|
|
|
*
|
|
|
|
* Filters are sources that are used to modify the video/audio output of
|
|
|
|
* other sources.
|
|
|
|
*/
|
2013-12-20 16:23:19 -08:00
|
|
|
EXPORT bool obs_enum_filter_types(size_t idx, const char **id);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
2013-11-22 15:18:31 -08:00
|
|
|
* Enumerates all available transition source types.
|
2013-09-30 19:37:13 -07:00
|
|
|
*
|
|
|
|
* Transitions are sources used to transition between two or more other
|
|
|
|
* sources.
|
|
|
|
*/
|
2013-12-20 16:23:19 -08:00
|
|
|
EXPORT bool obs_enum_transition_types(size_t idx, const char **id);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -07:00
|
|
|
/** Enumerates all available output types. */
|
2013-12-20 16:23:19 -08:00
|
|
|
EXPORT bool obs_enum_output_types(size_t idx, const char **id);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -07:00
|
|
|
/** Enumerates all available encoder types. */
|
|
|
|
EXPORT bool obs_enum_encoder_types(size_t idx, const char **id);
|
|
|
|
|
|
|
|
/** Enumerates all available service types. */
|
|
|
|
EXPORT bool obs_enum_service_types(size_t idx, const char **id);
|
|
|
|
|
2014-02-13 07:58:31 -08:00
|
|
|
/** Gets the main graphics context for this OBS context */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT graphics_t obs_graphics(void);
|
|
|
|
|
2014-02-13 07:58:31 -08:00
|
|
|
/** Gets the main audio output handler for this OBS context */
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
EXPORT audio_t obs_audio(void);
|
2014-02-13 07:58:31 -08:00
|
|
|
|
|
|
|
/** Gets the main video output handler for this OBS context */
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
EXPORT video_t obs_video(void);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
/**
|
2013-11-22 15:18:31 -08:00
|
|
|
* Adds a source to the user source list and increments the reference counter
|
|
|
|
* for that source.
|
2013-09-30 19:37:13 -07:00
|
|
|
*
|
2013-11-20 14:00:16 -08:00
|
|
|
* The user source list is the list of sources that are accessible by a user.
|
|
|
|
* Typically when a transition is active, it is not meant to be accessible by
|
|
|
|
* users, so there's no reason for a user to see such a source.
|
2013-09-30 19:37:13 -07:00
|
|
|
*/
|
2013-11-20 14:00:16 -08:00
|
|
|
EXPORT bool obs_add_source(obs_source_t source);
|
|
|
|
|
2013-11-22 15:18:31 -08:00
|
|
|
/** Sets the primary output source for a channel. */
|
2013-11-20 14:00:16 -08:00
|
|
|
EXPORT void obs_set_output_source(uint32_t channel, obs_source_t source);
|
2013-11-22 15:18:31 -08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Gets the primary output source for a channel and increments the reference
|
|
|
|
* counter for that source. Use obs_source_release to release.
|
|
|
|
*/
|
2013-11-20 14:00:16 -08:00
|
|
|
EXPORT obs_source_t obs_get_output_source(uint32_t channel);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-12-20 18:35:12 -08:00
|
|
|
/**
|
|
|
|
* Enumerates user sources
|
|
|
|
*
|
|
|
|
* Callback function returns true to continue enumeration, or false to end
|
|
|
|
* enumeration.
|
|
|
|
*/
|
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
|
|
|
EXPORT void obs_enum_sources(bool (*enum_proc)(void*, obs_source_t),
|
|
|
|
void *param);
|
|
|
|
|
|
|
|
/** Enumerates outputs */
|
|
|
|
EXPORT void obs_enum_outputs(bool (*enum_proc)(void*, obs_output_t),
|
|
|
|
void *param);
|
|
|
|
|
|
|
|
/** Enumerates encoders */
|
|
|
|
EXPORT void obs_enum_encoders(bool (*enum_proc)(void*, obs_encoder_t),
|
2013-12-20 18:35:12 -08:00
|
|
|
void *param);
|
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
/** Enumerates encoders */
|
|
|
|
EXPORT void obs_enum_services(bool (*enum_proc)(void*, obs_service_t),
|
|
|
|
void *param);
|
|
|
|
|
2013-12-20 18:35:12 -08:00
|
|
|
/**
|
|
|
|
* Gets a source by its name.
|
|
|
|
*
|
|
|
|
* Increments the source reference counter, use obs_source_release to
|
|
|
|
* release it when complete.
|
|
|
|
*/
|
|
|
|
EXPORT obs_source_t obs_get_source_by_name(const char *name);
|
2013-11-22 15:18:31 -08:00
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
/** Gets an output by its name. */
|
|
|
|
EXPORT obs_output_t obs_get_output_by_name(const char *name);
|
|
|
|
|
|
|
|
/** Gets an encoder by its name. */
|
|
|
|
EXPORT obs_encoder_t obs_get_encoder_by_name(const char *name);
|
|
|
|
|
|
|
|
/** Gets an service by its name. */
|
|
|
|
EXPORT obs_service_t obs_get_service_by_name(const char *name);
|
|
|
|
|
2013-11-01 14:33:00 -07:00
|
|
|
/**
|
|
|
|
* Returns the location of a plugin data file.
|
|
|
|
*
|
|
|
|
* file: Name of file to locate. For example, "myplugin/mydata.data"
|
2013-11-20 14:00:16 -08:00
|
|
|
* returns: Path string, or NULL if not found. Use bfree to free string.
|
2013-11-01 14:33:00 -07:00
|
|
|
*/
|
|
|
|
EXPORT char *obs_find_plugin_file(const char *file);
|
|
|
|
|
2013-12-22 00:30:18 -08:00
|
|
|
/** Returns the default effect for generic RGB/YUV drawing */
|
2013-12-24 08:06:19 -08:00
|
|
|
EXPORT effect_t obs_get_default_effect(void);
|
2013-12-22 00:30:18 -08:00
|
|
|
|
2013-12-26 22:10:15 -08:00
|
|
|
/** Returns the primary obs signal handler */
|
|
|
|
EXPORT signal_handler_t obs_signalhandler(void);
|
|
|
|
|
|
|
|
/** Returns the primary obs procedure handler */
|
|
|
|
EXPORT proc_handler_t obs_prochandler(void);
|
|
|
|
|
2014-02-13 07:58:31 -08:00
|
|
|
/** Adds a draw callback to the main render context */
|
|
|
|
EXPORT void obs_add_draw_callback(
|
|
|
|
void (*draw)(void *param, uint32_t cx, uint32_t cy),
|
|
|
|
void *param);
|
|
|
|
|
|
|
|
/** Removes a draw callback to the main render context */
|
|
|
|
EXPORT void obs_remove_draw_callback(
|
|
|
|
void (*draw)(void *param, uint32_t cx, uint32_t cy),
|
|
|
|
void *param);
|
|
|
|
|
2014-02-13 09:21:16 -08:00
|
|
|
/** Changes the size of the main view */
|
2014-02-13 07:58:31 -08:00
|
|
|
EXPORT void obs_resize(uint32_t cx, uint32_t cy);
|
|
|
|
|
2014-02-13 09:21:16 -08:00
|
|
|
/** Renders the main view */
|
|
|
|
EXPORT void obs_render_main_view(void);
|
2014-02-13 07:58:31 -08:00
|
|
|
|
2014-02-20 14:53:16 -08:00
|
|
|
/** Sets the master user volume */
|
|
|
|
EXPORT void obs_set_master_volume(float volume);
|
|
|
|
|
|
|
|
/** Sets the master presentation volume */
|
|
|
|
EXPORT void obs_set_present_volume(float volume);
|
|
|
|
|
|
|
|
/** Gets the master user volume */
|
|
|
|
EXPORT float obs_get_master_volume(void);
|
|
|
|
|
|
|
|
/** Gets the master presentation volume */
|
|
|
|
EXPORT float obs_get_present_volume(void);
|
2014-05-03 22:54:38 -07:00
|
|
|
|
|
|
|
/** Saves a source to settings data */
|
|
|
|
EXPORT obs_data_t obs_save_source(obs_source_t source);
|
|
|
|
|
|
|
|
/** Loads a source from settings data */
|
|
|
|
EXPORT obs_source_t obs_load_source(obs_data_t data);
|
2014-02-20 14:53:16 -08:00
|
|
|
|
2014-04-26 23:47:50 -07:00
|
|
|
/** Loads sources from a data array */
|
|
|
|
EXPORT void obs_load_sources(obs_data_array_t array);
|
|
|
|
|
|
|
|
/** Saves sources to a data array */
|
|
|
|
EXPORT obs_data_array_t obs_save_sources(void);
|
|
|
|
|
2014-02-13 07:58:31 -08:00
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
2014-02-13 09:21:16 -08:00
|
|
|
/* View context */
|
2014-02-13 07:58:31 -08:00
|
|
|
|
|
|
|
/**
|
2014-02-13 09:21:16 -08:00
|
|
|
* Creates a view context.
|
2014-02-13 07:58:31 -08:00
|
|
|
*
|
2014-02-13 09:21:16 -08:00
|
|
|
* A view can be used for things like separate previews, or drawing
|
2014-02-13 07:58:31 -08:00
|
|
|
* sources separately.
|
|
|
|
*/
|
2014-02-13 09:21:16 -08:00
|
|
|
EXPORT obs_view_t obs_view_create(void);
|
2014-02-13 07:58:31 -08:00
|
|
|
|
2014-02-13 09:21:16 -08:00
|
|
|
/** Destroys this view context */
|
|
|
|
EXPORT void obs_view_destroy(obs_view_t view);
|
2014-02-13 07:58:31 -08:00
|
|
|
|
2014-02-13 09:21:16 -08:00
|
|
|
/** Sets the source to be used for this view context. */
|
|
|
|
EXPORT void obs_view_setsource(obs_view_t view, uint32_t channel,
|
2014-02-13 07:58:31 -08:00
|
|
|
obs_source_t source);
|
|
|
|
|
2014-02-13 09:21:16 -08:00
|
|
|
/** Gets the source currently in use for this view context */
|
|
|
|
EXPORT obs_source_t obs_view_getsource(obs_view_t view,
|
2014-02-13 07:58:31 -08:00
|
|
|
uint32_t channel);
|
|
|
|
|
2014-02-13 09:21:16 -08:00
|
|
|
/** Renders the sources of this view context */
|
|
|
|
EXPORT void obs_view_render(obs_view_t view);
|
2014-02-13 07:58:31 -08:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Display context */
|
|
|
|
|
|
|
|
/**
|
2014-02-13 07:58:31 -08:00
|
|
|
* Adds a new window display linked to the main render pipeline. This creates
|
|
|
|
* a new swap chain which updates every frame.
|
2013-09-30 19:37:13 -07:00
|
|
|
*
|
2014-02-13 07:58:31 -08:00
|
|
|
* @param graphics_data The swap chain initialization data.
|
|
|
|
* @return The new display context, or NULL if failed.
|
2013-09-30 19:37:13 -07:00
|
|
|
*/
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT obs_display_t obs_display_create(struct gs_init_data *graphics_data);
|
2014-02-13 07:58:31 -08:00
|
|
|
|
|
|
|
/** Destroys a display context */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_display_destroy(obs_display_t display);
|
|
|
|
|
2014-02-13 07:58:31 -08:00
|
|
|
/** Changes the size of this display */
|
|
|
|
EXPORT void obs_display_resize(obs_display_t display, uint32_t cx, uint32_t cy);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Adds a draw callback for this display context
|
|
|
|
*
|
|
|
|
* @param display The display context.
|
|
|
|
* @param draw The draw callback which is called each time a frame
|
|
|
|
* updates.
|
|
|
|
* @param param The user data to be associated with this draw callback.
|
|
|
|
*/
|
|
|
|
EXPORT void obs_display_add_draw_callback(obs_display_t display,
|
|
|
|
void (*draw)(void *param, uint32_t cx, uint32_t cy),
|
|
|
|
void *param);
|
|
|
|
|
|
|
|
/** Removes a draw callback for this display context */
|
|
|
|
EXPORT void obs_display_remove_draw_callback(obs_display_t display,
|
|
|
|
void (*draw)(void *param, uint32_t cx, uint32_t cy),
|
|
|
|
void *param);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Sources */
|
|
|
|
|
2014-02-01 21:46:13 -08:00
|
|
|
/** Returns the translated display name of a source */
|
2013-11-13 05:24:20 -08:00
|
|
|
EXPORT const char *obs_source_getdisplayname(enum obs_source_type type,
|
2013-12-20 16:23:19 -08:00
|
|
|
const char *id, const char *locale);
|
2013-11-13 05:24:20 -08:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
|
|
|
* Creates a source of the specified type with the specified settings.
|
|
|
|
*
|
|
|
|
* The "source" context is used for anything related to presenting
|
2013-12-20 18:35:12 -08:00
|
|
|
* or modifying video/audio. Use obs_source_release to release it.
|
2013-09-30 19:37:13 -07:00
|
|
|
*/
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT obs_source_t obs_source_create(enum obs_source_type type,
|
2014-01-27 22:14:58 -08:00
|
|
|
const char *id, const char *name, obs_data_t settings);
|
2013-11-20 17:36:46 -08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Adds/releases a reference to a source. When the last reference is
|
|
|
|
* released, the source is destroyed.
|
|
|
|
*/
|
2014-02-02 17:34:06 -08:00
|
|
|
EXPORT void obs_source_addref(obs_source_t source);
|
|
|
|
EXPORT void obs_source_release(obs_source_t source);
|
2013-11-20 17:36:46 -08:00
|
|
|
|
2013-12-15 16:41:35 -08:00
|
|
|
/** Notifies all references that the source should be released */
|
2013-11-20 17:36:46 -08:00
|
|
|
EXPORT void obs_source_remove(obs_source_t source);
|
2013-11-20 14:00:16 -08:00
|
|
|
|
|
|
|
/** Returns true if the source should be released */
|
|
|
|
EXPORT bool obs_source_removed(obs_source_t source);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
|
|
|
* Retrieves flags that specify what type of data the source presents/modifies.
|
|
|
|
*/
|
2013-10-17 17:21:42 -07:00
|
|
|
EXPORT uint32_t obs_source_get_output_flags(obs_source_t source);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2014-03-07 05:55:21 -08:00
|
|
|
/** Gets the default settings for a source type */
|
2014-03-23 01:07:54 -07:00
|
|
|
EXPORT obs_data_t obs_get_source_defaults(enum obs_source_type type,
|
2014-03-07 05:55:21 -08:00
|
|
|
const char *id);
|
|
|
|
|
2014-02-01 21:46:13 -08:00
|
|
|
/** Returns the property list, if any. Free with obs_properties_destroy */
|
2014-03-23 01:07:54 -07:00
|
|
|
EXPORT obs_properties_t obs_get_source_properties(enum obs_source_type type,
|
2014-02-01 21:46:13 -08:00
|
|
|
const char *id, const char *locale);
|
|
|
|
|
2014-03-23 01:07:54 -07:00
|
|
|
/**
|
|
|
|
* Returns the properties list for a specific existing source. Free with
|
|
|
|
* obs_properties_destroy
|
|
|
|
*/
|
|
|
|
EXPORT obs_properties_t obs_source_properties(obs_source_t source,
|
|
|
|
const char *locale);
|
|
|
|
|
2014-01-17 05:24:34 -08:00
|
|
|
/** Updates settings for this source */
|
2014-01-27 22:14:58 -08:00
|
|
|
EXPORT void obs_source_update(obs_source_t source, obs_data_t settings);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Renders a video source. */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_source_video_render(obs_source_t source);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Gets the width of a source (if it has video) */
|
2013-10-17 17:21:42 -07:00
|
|
|
EXPORT uint32_t obs_source_getwidth(obs_source_t source);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Gets the height of a source (if it has video) */
|
2013-10-17 17:21:42 -07:00
|
|
|
EXPORT uint32_t obs_source_getheight(obs_source_t source);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-12-22 00:30:18 -08:00
|
|
|
/** If the source is a filter, returns the parent source of the filter */
|
|
|
|
EXPORT obs_source_t obs_filter_getparent(obs_source_t filter);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** If the source is a filter, returns the target source of the filter */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT obs_source_t obs_filter_gettarget(obs_source_t filter);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Adds a filter to the source (which is used whenever the source is used) */
|
2013-11-20 14:00:16 -08:00
|
|
|
EXPORT void obs_source_filter_add(obs_source_t source, obs_source_t filter);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Removes a filter from the source */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_source_filter_remove(obs_source_t source, obs_source_t filter);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Modifies the order of a specific filter */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_source_filter_setorder(obs_source_t source, obs_source_t filter,
|
|
|
|
enum order_movement movement);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
/** Gets the settings string for a source */
|
2014-01-27 22:14:58 -08:00
|
|
|
EXPORT obs_data_t obs_source_getsettings(obs_source_t source);
|
2013-12-20 18:35:12 -08:00
|
|
|
|
|
|
|
/** Gets the name of a source */
|
|
|
|
EXPORT const char *obs_source_getname(obs_source_t source);
|
|
|
|
|
|
|
|
/** Sets the name of a source */
|
|
|
|
EXPORT void obs_source_setname(obs_source_t source, const char *name);
|
|
|
|
|
|
|
|
/** Gets the source type and identifier */
|
2013-12-28 04:33:16 -08:00
|
|
|
EXPORT void obs_source_gettype(obs_source_t source, enum obs_source_type *type,
|
2013-12-20 18:35:12 -08:00
|
|
|
const char **id);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-12-26 22:10:15 -08:00
|
|
|
/** Returns the signal handler for a source */
|
|
|
|
EXPORT signal_handler_t obs_source_signalhandler(obs_source_t source);
|
|
|
|
|
|
|
|
/** Returns the procedure handler for a source */
|
|
|
|
EXPORT proc_handler_t obs_source_prochandler(obs_source_t source);
|
|
|
|
|
2014-02-20 14:53:16 -08:00
|
|
|
/** Sets the user volume for a source that has audio output */
|
2014-01-07 10:03:15 -08:00
|
|
|
EXPORT void obs_source_setvolume(obs_source_t source, float volume);
|
|
|
|
|
2014-02-20 14:53:16 -08:00
|
|
|
/** Sets the presentation volume for a source */
|
|
|
|
EXPORT void obs_source_set_present_volume(obs_source_t source, float volume);
|
|
|
|
|
|
|
|
/** Gets the user volume for a source that has audio output */
|
2014-01-07 10:03:15 -08:00
|
|
|
EXPORT float obs_source_getvolume(obs_source_t source);
|
|
|
|
|
2014-02-20 14:53:16 -08:00
|
|
|
/** Gets the presentation volume for a source */
|
|
|
|
EXPORT float obs_source_get_present_volume(obs_source_t source);
|
|
|
|
|
2014-02-20 15:16:25 -08:00
|
|
|
/** Sets the audio sync offset (in nanoseconds) for a source */
|
|
|
|
EXPORT void obs_source_set_sync_offset(obs_source_t source, int64_t offset);
|
|
|
|
|
|
|
|
/** Gets the audio sync offset (in nanoseconds) for a source */
|
|
|
|
EXPORT int64_t obs_source_get_sync_offset(obs_source_t source);
|
|
|
|
|
2014-02-20 16:44:42 -08:00
|
|
|
/** Enumerates child sources used by this source */
|
|
|
|
EXPORT void obs_source_enum_sources(obs_source_t source,
|
|
|
|
obs_source_enum_proc_t enum_callback,
|
|
|
|
void *param);
|
|
|
|
|
|
|
|
/** Enumerates the entire child source tree used by this source */
|
|
|
|
EXPORT void obs_source_enum_tree(obs_source_t source,
|
|
|
|
obs_source_enum_proc_t enum_callback,
|
|
|
|
void *param);
|
|
|
|
|
2014-02-20 21:04:14 -08:00
|
|
|
/** Returns true if active, false if not */
|
|
|
|
EXPORT bool obs_source_active(obs_source_t source);
|
|
|
|
|
2014-04-26 23:47:50 -07:00
|
|
|
/**
|
|
|
|
* Sometimes sources need to be told when to save their settings so they
|
|
|
|
* don't have to constantly update and keep track of their settings. This will
|
|
|
|
* call the source's 'save' callback if any, which will save its current
|
|
|
|
* data to its settings.
|
|
|
|
*/
|
|
|
|
EXPORT void obs_source_save(obs_source_t source);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Sometimes sources need to be told when they are loading their settings
|
|
|
|
* from prior saved data. This is different from a source 'update' in that
|
|
|
|
* it's meant to be used after the source has been created and loaded from
|
|
|
|
* somewhere (such as a saved file).
|
|
|
|
*/
|
|
|
|
EXPORT void obs_source_load(obs_source_t source);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Functions used by sources */
|
|
|
|
|
|
|
|
/** Outputs asynchronous video data */
|
2013-12-17 21:30:22 -08:00
|
|
|
EXPORT void obs_source_output_video(obs_source_t source,
|
2013-10-26 14:32:06 -07:00
|
|
|
const struct source_frame *frame);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Outputs audio data (always asynchronous) */
|
2013-12-17 21:30:22 -08:00
|
|
|
EXPORT void obs_source_output_audio(obs_source_t source,
|
2013-10-24 00:57:55 -07:00
|
|
|
const struct source_audio *audio);
|
|
|
|
|
|
|
|
/** Gets the current async video frame */
|
|
|
|
EXPORT struct source_frame *obs_source_getframe(obs_source_t source);
|
|
|
|
|
2013-10-24 01:03:45 -07:00
|
|
|
/** Releases the current async video frame */
|
2013-10-24 00:57:55 -07:00
|
|
|
EXPORT void obs_source_releaseframe(obs_source_t source,
|
|
|
|
struct source_frame *frame);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-12-22 00:30:18 -08:00
|
|
|
/** Default RGB filter handler for generic effect filters */
|
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
|
|
|
EXPORT void obs_source_process_filter(obs_source_t filter, effect_t effect,
|
|
|
|
uint32_t width, uint32_t height, enum gs_color_format format,
|
2013-12-22 01:03:40 -08:00
|
|
|
enum allow_direct_render allow_direct);
|
2013-12-22 00:30:18 -08:00
|
|
|
|
2014-02-20 21:04:14 -08:00
|
|
|
/**
|
|
|
|
* Adds a child source. Must be called by parent sources on child sources
|
|
|
|
* when the child is added. This ensures that the source is properly activated
|
|
|
|
* if the parent is active.
|
|
|
|
*/
|
|
|
|
EXPORT void obs_source_add_child(obs_source_t parent, obs_source_t child);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Removes a child source. Must be called by parent sources on child sources
|
|
|
|
* when the child is removed. This ensures that the source is properly
|
|
|
|
* deactivated if the parent is active.
|
|
|
|
*/
|
|
|
|
EXPORT void obs_source_remove_child(obs_source_t parent, obs_source_t child);
|
|
|
|
|
Implement volume handling
- Remove obs_source::type because it became redundant now that the
type is always stored in the obs_source::info variable.
- Apply presentation volumes of 1.0 and 0.0 to sources when they
activate/deactivate, respectively. It also applies that presentation
volume to all sub-sources, with exception of transition sources.
Transition sources must apply presentation volume manually to their
sub-sources with the new transition functions below.
- Add a "transition_volume" variable to obs_source structure, and add
three functions for handling volume for transitions:
* obs_transition_begin_frame
* obs_source_set_transition_vol
* obs_transition_end_frame
Because the to/from targets of a transition source might both contain
some of the same sources, handling the transitioning of volumes for
that specific situation becomes an issue.
So for transitions, instead of modifying the presentation volumes
directly for both sets of sources, we do this:
- First, call obs_transition_begin_frame at the beginning of each
transition frame, which will reset transition volumes for all
sub-sources to 0. Presentation volumes remain unchanged.
- Call obs_source_set_transition_vol on each sub-source, which will
then add the volume to the transition volume for each source in
that source's tree. Presentation volumes still remain unchanged.
- Then you call obs_trandition_end_frame when complete, which will
then finally set the presentation volumes to the transition
volumes.
For example, let's say that there's one source that's within both the
"transitioning from" sources and "transition to" sources. It would
add both the fade in and fade out volumes to that source, and then
when the frame is complete, it would set the presentation volume to
the sum of those two values, rather than set the presentation volume
for that same source twice which would cause weird volume jittering
and also set the wrong values.
2014-02-21 18:41:38 -08:00
|
|
|
/** Begins transition frame. Sets all transitioning volume values to 0.0f. */
|
|
|
|
EXPORT void obs_transition_begin_frame(obs_source_t transition);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Adds a transitioning volume value to a source that's being transitioned.
|
|
|
|
* This value is applied to all the sources within the the source.
|
|
|
|
*/
|
|
|
|
EXPORT void obs_source_set_transition_vol(obs_source_t source, float vol);
|
|
|
|
|
|
|
|
/** Ends transition frame and applies new presentation volumes to all sources */
|
|
|
|
EXPORT void obs_transition_end_frame(obs_source_t transition);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Scenes */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Creates a scene.
|
|
|
|
*
|
|
|
|
* A scene is a source which is a container of other sources with specific
|
|
|
|
* display oriantations. Scenes can also be used like any other source.
|
|
|
|
*/
|
2013-12-28 04:33:16 -08:00
|
|
|
EXPORT obs_scene_t obs_scene_create(const char *name);
|
2013-12-30 05:56:39 -08:00
|
|
|
|
2014-02-02 17:34:06 -08:00
|
|
|
EXPORT void obs_scene_addref(obs_scene_t scene);
|
|
|
|
EXPORT void obs_scene_release(obs_scene_t scene);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Gets the scene's source context */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT obs_source_t obs_scene_getsource(obs_scene_t scene);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-12-28 04:33:16 -08:00
|
|
|
/** Gets the scene from its source, or NULL if not a scene */
|
|
|
|
EXPORT obs_scene_t obs_scene_fromsource(obs_source_t source);
|
|
|
|
|
2014-01-01 09:22:55 -08:00
|
|
|
/** Determines whether a source is within a scene */
|
|
|
|
EXPORT obs_sceneitem_t obs_scene_findsource(obs_scene_t scene,
|
|
|
|
const char *name);
|
|
|
|
|
|
|
|
/** Enumerates sources within a scene */
|
|
|
|
EXPORT void obs_scene_enum_items(obs_scene_t scene,
|
|
|
|
bool (*callback)(obs_scene_t, obs_sceneitem_t, void*),
|
|
|
|
void *param);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Adds/creates a new scene item for a source */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT obs_sceneitem_t obs_scene_add(obs_scene_t scene, obs_source_t source);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2014-02-02 17:34:06 -08:00
|
|
|
EXPORT void obs_sceneitem_addref(obs_sceneitem_t item);
|
|
|
|
EXPORT void obs_sceneitem_release(obs_sceneitem_t item);
|
2013-12-30 05:56:39 -08:00
|
|
|
|
2014-01-30 00:31:52 -08:00
|
|
|
/** Removes a scene item. */
|
|
|
|
EXPORT void obs_sceneitem_remove(obs_sceneitem_t item);
|
|
|
|
|
|
|
|
/** Gets the scene parent associated with the scene item. */
|
2014-01-04 12:38:56 -08:00
|
|
|
EXPORT obs_scene_t obs_sceneitem_getscene(obs_sceneitem_t item);
|
|
|
|
|
2014-01-30 00:31:52 -08:00
|
|
|
/** Gets the source of a scene item. */
|
2013-12-30 05:56:39 -08:00
|
|
|
EXPORT obs_source_t obs_sceneitem_getsource(obs_sceneitem_t item);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
/* Functions for gettings/setting specific oriantation of a scene item */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_sceneitem_setpos(obs_sceneitem_t item, const struct vec2 *pos);
|
|
|
|
EXPORT void obs_sceneitem_setrot(obs_sceneitem_t item, float rot);
|
|
|
|
EXPORT void obs_sceneitem_setorigin(obs_sceneitem_t item,
|
2013-10-14 12:42:45 -07:00
|
|
|
const struct vec2 *origin);
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_sceneitem_setscale(obs_sceneitem_t item,
|
|
|
|
const struct vec2 *scale);
|
|
|
|
EXPORT void obs_sceneitem_setorder(obs_sceneitem_t item,
|
|
|
|
enum order_movement movement);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_sceneitem_getpos(obs_sceneitem_t item, struct vec2 *pos);
|
|
|
|
EXPORT float obs_sceneitem_getrot(obs_sceneitem_t item);
|
|
|
|
EXPORT void obs_sceneitem_getorigin(obs_sceneitem_t item, struct vec2 *center);
|
|
|
|
EXPORT void obs_sceneitem_getscale(obs_sceneitem_t item, struct vec2 *scale);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Outputs */
|
|
|
|
|
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
|
|
|
EXPORT const char *obs_output_getdisplayname(const char *id,
|
|
|
|
const char *locale);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/**
|
|
|
|
* Creates an output.
|
|
|
|
*
|
|
|
|
* Outputs allow outputting to file, outputting to network, outputting to
|
|
|
|
* directshow, or other custom outputs.
|
|
|
|
*/
|
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
|
|
|
EXPORT obs_output_t obs_output_create(const char *id, const char *name,
|
2014-01-27 22:14:58 -08:00
|
|
|
obs_data_t settings);
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_output_destroy(obs_output_t output);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Starts the 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
|
|
|
EXPORT bool obs_output_start(obs_output_t output);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Stops the output. */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_output_stop(obs_output_t 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
|
|
|
/** Returns whether the output is active */
|
|
|
|
EXPORT bool obs_output_active(obs_output_t output);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2014-03-07 05:55:21 -08:00
|
|
|
/** Gets the default settings for an output type */
|
|
|
|
EXPORT obs_data_t obs_output_defaults(const char *id);
|
|
|
|
|
2014-02-01 21:46:13 -08:00
|
|
|
/** Returns the property list, if any. Free with obs_properties_destroy */
|
2014-03-23 01:07:54 -07:00
|
|
|
EXPORT obs_properties_t obs_get_output_properties(const char *id,
|
|
|
|
const char *locale);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the property list of an existing output, if any. Free with
|
|
|
|
* obs_properties_destroy
|
|
|
|
*/
|
|
|
|
EXPORT obs_properties_t obs_output_properties(obs_output_t output,
|
2014-02-01 21:46:13 -08:00
|
|
|
const char *locale);
|
|
|
|
|
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
|
|
|
/** Updates the settings for this output context */
|
2014-01-27 22:14:58 -08:00
|
|
|
EXPORT void obs_output_update(obs_output_t output, obs_data_t settings);
|
2013-10-14 12:37:52 -07:00
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Specifies whether the output can be paused */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT bool obs_output_canpause(obs_output_t output);
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/** Pauses the output (if the functionality is allowed by the output */
|
2013-10-14 12:37:52 -07:00
|
|
|
EXPORT void obs_output_pause(obs_output_t output);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
/* Gets the current output settings string */
|
2014-01-27 22:14:58 -08:00
|
|
|
EXPORT obs_data_t obs_output_get_settings(obs_output_t output);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2014-03-10 13:10:35 -07:00
|
|
|
/** Returns the signal handler for an output */
|
|
|
|
EXPORT signal_handler_t obs_output_signalhandler(obs_output_t output);
|
|
|
|
|
|
|
|
/** Returns the procedure handler for an output */
|
|
|
|
EXPORT proc_handler_t obs_output_prochandler(obs_output_t output);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Sets the current video media context associated with this output,
|
|
|
|
* required for non-encoded outputs
|
|
|
|
*/
|
|
|
|
EXPORT void obs_output_set_video(obs_output_t output, video_t video);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Sets the current audio/video media contexts associated with this output,
|
|
|
|
* required for non-encoded outputs. Can be null.
|
|
|
|
*/
|
|
|
|
EXPORT void obs_output_set_media(obs_output_t output,
|
|
|
|
video_t video, audio_t audio);
|
|
|
|
|
|
|
|
/** Returns the video media context associated with this output */
|
|
|
|
EXPORT video_t obs_output_video(obs_output_t output);
|
|
|
|
|
|
|
|
/** Returns the audio media context associated with this output */
|
|
|
|
EXPORT audio_t obs_output_audio(obs_output_t output);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Sets the current video encoder associated with this output,
|
|
|
|
* required for encoded outputs
|
|
|
|
*/
|
|
|
|
EXPORT void obs_output_set_video_encoder(obs_output_t output,
|
|
|
|
obs_encoder_t encoder);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Sets the current audio encoder associated with this output,
|
|
|
|
* required for encoded outputs
|
|
|
|
*/
|
|
|
|
EXPORT void obs_output_set_audio_encoder(obs_output_t output,
|
|
|
|
obs_encoder_t encoder);
|
|
|
|
|
|
|
|
/** Returns the current video encoder associated with this output */
|
|
|
|
EXPORT obs_encoder_t obs_output_get_video_encoder(obs_output_t output);
|
|
|
|
|
|
|
|
/** Returns the current audio encoder associated with this output */
|
|
|
|
EXPORT obs_encoder_t obs_output_get_audio_encoder(obs_output_t output);
|
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
/** Sets the current service associated with this output. */
|
|
|
|
EXPORT void obs_output_set_service(obs_output_t output, obs_service_t service);
|
|
|
|
|
|
|
|
/** Gets the current service associated with this output. */
|
|
|
|
EXPORT obs_service_t obs_output_get_service(obs_output_t output);
|
|
|
|
|
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
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Functions used by outputs */
|
|
|
|
|
|
|
|
/** Optionally sets the video conversion info. Used only for raw output */
|
|
|
|
EXPORT void obs_output_set_video_conversion(obs_output_t output,
|
|
|
|
const struct video_scale_info *conversion);
|
|
|
|
|
|
|
|
/** Optionally sets the audio conversion info. Used only for raw output */
|
|
|
|
EXPORT void obs_output_set_audio_conversion(obs_output_t output,
|
|
|
|
const struct audio_convert_info *conversion);
|
|
|
|
|
2014-04-01 11:55:18 -07:00
|
|
|
/** Returns whether data capture can begin with the specified flags */
|
|
|
|
EXPORT bool obs_output_can_begin_data_capture(obs_output_t output,
|
|
|
|
uint32_t flags);
|
|
|
|
|
Implement RTMP module (still needs drop code)
- Implement the RTMP output module. This time around, we just use a
simple FLV muxer, then just write to the stream with RTMP_Write.
Easy and effective.
- Fix the FLV muxer, the muxer now outputs proper FLV packets.
- Output API:
* When using encoders, automatically interleave encoded packets
before sending it to the output.
* Pair encoders and have them automatically wait for the other to
start to ensure sync.
* Change 'obs_output_signal_start_fail' to 'obs_output_signal_stop'
because it was a bit confusing, and doing this makes a lot more
sense for outputs that need to stop suddenly (disconnections/etc).
- Encoder API:
* Remove some unnecessary encoder functions from the actual API and
make them internal. Most of the encoder functions are handled
automatically by outputs anyway, so there's no real need to expose
them and end up inadvertently confusing plugin writers.
* Have audio encoders wait for the video encoder to get a frame, then
start at the exact data point that the first video frame starts to
ensure the most accrate sync of video/audio possible.
* Add a required 'frame_size' callback for audio encoders that
returns the expected number of frames desired to encode with. This
way, the libobs encoder API can handle the circular buffering
internally automatically for the encoder modules, so encoder
writers don't have to do it themselves.
- Fix a few bugs in the serializer interface. It was passing the wrong
variable for the data in a few cases.
- If a source has video, make obs_source_update defer the actual update
callback until the tick function is called to prevent threading
issues.
2014-04-07 22:00:10 -07:00
|
|
|
/** Initializes encoders (if any) */
|
|
|
|
EXPORT bool obs_output_initialize_encoders(obs_output_t output, uint32_t flags);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Begins data capture from media/encoders.
|
|
|
|
*
|
|
|
|
* @param output Output context
|
|
|
|
* @param flags Set this to 0 to use default output flags set in the
|
|
|
|
* obs_output_info structure, otherwise set to a either
|
|
|
|
* OBS_OUTPUT_VIDEO or OBS_OUTPUT_AUDIO to specify whether to
|
|
|
|
* connect audio or video. This is useful for things like
|
|
|
|
* ffmpeg which may or may not always want to use both audio
|
|
|
|
* and video.
|
|
|
|
* @return true if successful, false otherwise.
|
|
|
|
*/
|
|
|
|
EXPORT bool obs_output_begin_data_capture(obs_output_t output, uint32_t flags);
|
|
|
|
|
|
|
|
/** Ends data capture from media/encoders */
|
|
|
|
EXPORT void obs_output_end_data_capture(obs_output_t output);
|
|
|
|
|
Implement RTMP module (still needs drop code)
- Implement the RTMP output module. This time around, we just use a
simple FLV muxer, then just write to the stream with RTMP_Write.
Easy and effective.
- Fix the FLV muxer, the muxer now outputs proper FLV packets.
- Output API:
* When using encoders, automatically interleave encoded packets
before sending it to the output.
* Pair encoders and have them automatically wait for the other to
start to ensure sync.
* Change 'obs_output_signal_start_fail' to 'obs_output_signal_stop'
because it was a bit confusing, and doing this makes a lot more
sense for outputs that need to stop suddenly (disconnections/etc).
- Encoder API:
* Remove some unnecessary encoder functions from the actual API and
make them internal. Most of the encoder functions are handled
automatically by outputs anyway, so there's no real need to expose
them and end up inadvertently confusing plugin writers.
* Have audio encoders wait for the video encoder to get a frame, then
start at the exact data point that the first video frame starts to
ensure the most accrate sync of video/audio possible.
* Add a required 'frame_size' callback for audio encoders that
returns the expected number of frames desired to encode with. This
way, the libobs encoder API can handle the circular buffering
internally automatically for the encoder modules, so encoder
writers don't have to do it themselves.
- Fix a few bugs in the serializer interface. It was passing the wrong
variable for the data in a few cases.
- If a source has video, make obs_source_update defer the actual update
callback until the tick function is called to prevent threading
issues.
2014-04-07 22:00:10 -07:00
|
|
|
/**
|
|
|
|
* Signals that the output has stopped itself.
|
|
|
|
*
|
|
|
|
* @param output Output context
|
|
|
|
* @param code Error code (or OBS_OUTPUT_SUCCESS if not an error)
|
|
|
|
*/
|
|
|
|
EXPORT void obs_output_signal_stop(obs_output_t output, int code);
|
2014-04-01 11:55:18 -07:00
|
|
|
|
2013-11-20 14:00:16 -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
|
|
|
/* ------------------------------------------------------------------------- */
|
2014-02-01 21:46:13 -08:00
|
|
|
/* Encoders */
|
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
|
|
|
|
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
|
|
|
EXPORT const char *obs_encoder_getdisplayname(const char *id,
|
|
|
|
const char *locale);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Creates a video encoder context
|
|
|
|
*
|
|
|
|
* @param id Video encoder ID
|
|
|
|
* @param name Name to assign to this context
|
|
|
|
* @param settings Settings
|
|
|
|
* @return The video encoder context, or NULL if failed or not found.
|
|
|
|
*/
|
Implement RTMP module (still needs drop code)
- Implement the RTMP output module. This time around, we just use a
simple FLV muxer, then just write to the stream with RTMP_Write.
Easy and effective.
- Fix the FLV muxer, the muxer now outputs proper FLV packets.
- Output API:
* When using encoders, automatically interleave encoded packets
before sending it to the output.
* Pair encoders and have them automatically wait for the other to
start to ensure sync.
* Change 'obs_output_signal_start_fail' to 'obs_output_signal_stop'
because it was a bit confusing, and doing this makes a lot more
sense for outputs that need to stop suddenly (disconnections/etc).
- Encoder API:
* Remove some unnecessary encoder functions from the actual API and
make them internal. Most of the encoder functions are handled
automatically by outputs anyway, so there's no real need to expose
them and end up inadvertently confusing plugin writers.
* Have audio encoders wait for the video encoder to get a frame, then
start at the exact data point that the first video frame starts to
ensure the most accrate sync of video/audio possible.
* Add a required 'frame_size' callback for audio encoders that
returns the expected number of frames desired to encode with. This
way, the libobs encoder API can handle the circular buffering
internally automatically for the encoder modules, so encoder
writers don't have to do it themselves.
- Fix a few bugs in the serializer interface. It was passing the wrong
variable for the data in a few cases.
- If a source has video, make obs_source_update defer the actual update
callback until the tick function is called to prevent threading
issues.
2014-04-07 22:00:10 -07:00
|
|
|
EXPORT obs_encoder_t obs_video_encoder_create(const char *id, const char *name,
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
obs_data_t settings);
|
Add preliminary output/encoder interface
- First, I redid the output interface for libobs. I feel like it's
going in a pretty good direction in terms of design.
Right now, the design is so that outputs and encoders are separate.
One or more outputs can connect to a specific encoder to receive its
data, or the output can connect directly to raw data from libobs
output itself, if the output doesn't want to use a designated encoder.
Data is received via callbacks set when you connect to the encoder or
raw output. Multiple outputs can receive the data from a single
encoder context if need be (such as for streaming to multiple channels
at once, and/or recording with the same data).
When an encoder is first connected to, it will connect to raw output,
and start encoding. Additional connections will receive that same
data being encoded as well after that. When the last encoder has
disconnected, it will stop encoding. If for some reason the encoder
needs to stop, it will use the callback with NULL to signal that
encoding has stopped. Some of these things may be subject to change
in the future, though it feels pretty good with this design so far.
Will have to see how well it works out in practice versus theory.
- Second, Started adding preliminary RTMP/x264 output plugin code.
To speed things up, I might just make a direct raw->FFmpeg output to
create a quick output plugin that we can start using for testing all
the subsystems.
2014-01-16 21:34:51 -08:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Creates an audio encoder context
|
|
|
|
*
|
|
|
|
* @param id Audio Encoder ID
|
|
|
|
* @param name Name to assign to this context
|
|
|
|
* @param settings Settings
|
|
|
|
* @return The video encoder context, or NULL if failed or not found.
|
|
|
|
*/
|
Implement RTMP module (still needs drop code)
- Implement the RTMP output module. This time around, we just use a
simple FLV muxer, then just write to the stream with RTMP_Write.
Easy and effective.
- Fix the FLV muxer, the muxer now outputs proper FLV packets.
- Output API:
* When using encoders, automatically interleave encoded packets
before sending it to the output.
* Pair encoders and have them automatically wait for the other to
start to ensure sync.
* Change 'obs_output_signal_start_fail' to 'obs_output_signal_stop'
because it was a bit confusing, and doing this makes a lot more
sense for outputs that need to stop suddenly (disconnections/etc).
- Encoder API:
* Remove some unnecessary encoder functions from the actual API and
make them internal. Most of the encoder functions are handled
automatically by outputs anyway, so there's no real need to expose
them and end up inadvertently confusing plugin writers.
* Have audio encoders wait for the video encoder to get a frame, then
start at the exact data point that the first video frame starts to
ensure the most accrate sync of video/audio possible.
* Add a required 'frame_size' callback for audio encoders that
returns the expected number of frames desired to encode with. This
way, the libobs encoder API can handle the circular buffering
internally automatically for the encoder modules, so encoder
writers don't have to do it themselves.
- Fix a few bugs in the serializer interface. It was passing the wrong
variable for the data in a few cases.
- If a source has video, make obs_source_update defer the actual update
callback until the tick function is called to prevent threading
issues.
2014-04-07 22:00:10 -07:00
|
|
|
EXPORT obs_encoder_t obs_audio_encoder_create(const char *id, const char *name,
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
obs_data_t settings);
|
2014-02-01 21:46:13 -08: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
|
|
|
/** Destroys an encoder context */
|
|
|
|
EXPORT void obs_encoder_destroy(obs_encoder_t encoder);
|
Add preliminary output/encoder interface
- First, I redid the output interface for libobs. I feel like it's
going in a pretty good direction in terms of design.
Right now, the design is so that outputs and encoders are separate.
One or more outputs can connect to a specific encoder to receive its
data, or the output can connect directly to raw data from libobs
output itself, if the output doesn't want to use a designated encoder.
Data is received via callbacks set when you connect to the encoder or
raw output. Multiple outputs can receive the data from a single
encoder context if need be (such as for streaming to multiple channels
at once, and/or recording with the same data).
When an encoder is first connected to, it will connect to raw output,
and start encoding. Additional connections will receive that same
data being encoded as well after that. When the last encoder has
disconnected, it will stop encoding. If for some reason the encoder
needs to stop, it will use the callback with NULL to signal that
encoding has stopped. Some of these things may be subject to change
in the future, though it feels pretty good with this design so far.
Will have to see how well it works out in practice versus theory.
- Second, Started adding preliminary RTMP/x264 output plugin code.
To speed things up, I might just make a direct raw->FFmpeg output to
create a quick output plugin that we can start using for testing all
the subsystems.
2014-01-16 21:34:51 -08:00
|
|
|
|
2014-04-01 11:55:18 -07:00
|
|
|
/** Returns the codec of the encoder */
|
|
|
|
EXPORT const char *obs_encoder_get_codec(obs_encoder_t encoder);
|
|
|
|
|
2014-03-07 05:55:21 -08:00
|
|
|
/** Gets the default settings for an encoder type */
|
|
|
|
EXPORT obs_data_t obs_encoder_defaults(const char *id);
|
|
|
|
|
2014-02-14 14:13:36 -08:00
|
|
|
/** Returns the property list, if any. Free with obs_properties_destroy */
|
2014-03-23 01:07:54 -07:00
|
|
|
EXPORT obs_properties_t obs_get_encoder_properties(const char *id,
|
|
|
|
const char *locale);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the property list of an existing encoder, if any. Free with
|
|
|
|
* obs_properties_destroy
|
|
|
|
*/
|
|
|
|
EXPORT obs_properties_t obs_encoder_properties(obs_encoder_t encoder,
|
2014-02-14 14:13:36 -08:00
|
|
|
const char *locale);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Updates the settings of the encoder context. Usually used for changing
|
|
|
|
* bitrate while active
|
|
|
|
*/
|
2014-02-14 14:13:36 -08:00
|
|
|
EXPORT void obs_encoder_update(obs_encoder_t encoder, obs_data_t settings);
|
Add preliminary output/encoder interface
- First, I redid the output interface for libobs. I feel like it's
going in a pretty good direction in terms of design.
Right now, the design is so that outputs and encoders are separate.
One or more outputs can connect to a specific encoder to receive its
data, or the output can connect directly to raw data from libobs
output itself, if the output doesn't want to use a designated encoder.
Data is received via callbacks set when you connect to the encoder or
raw output. Multiple outputs can receive the data from a single
encoder context if need be (such as for streaming to multiple channels
at once, and/or recording with the same data).
When an encoder is first connected to, it will connect to raw output,
and start encoding. Additional connections will receive that same
data being encoded as well after that. When the last encoder has
disconnected, it will stop encoding. If for some reason the encoder
needs to stop, it will use the callback with NULL to signal that
encoding has stopped. Some of these things may be subject to change
in the future, though it feels pretty good with this design so far.
Will have to see how well it works out in practice versus theory.
- Second, Started adding preliminary RTMP/x264 output plugin code.
To speed things up, I might just make a direct raw->FFmpeg output to
create a quick output plugin that we can start using for testing all
the subsystems.
2014-01-16 21:34:51 -08:00
|
|
|
|
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
|
|
|
/** Gets extra data (headers) associated with this context */
|
2014-02-14 14:13:36 -08:00
|
|
|
EXPORT bool obs_encoder_get_extra_data(obs_encoder_t encoder,
|
|
|
|
uint8_t **extra_data, size_t *size);
|
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 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
|
|
|
/** Returns the current settings for this encoder */
|
2014-01-27 22:14:58 -08:00
|
|
|
EXPORT obs_data_t obs_encoder_get_settings(obs_encoder_t encoder);
|
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-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
/** Sets the video output context to be used with this encoder */
|
|
|
|
EXPORT void obs_encoder_set_video(obs_encoder_t encoder, video_t video);
|
|
|
|
|
|
|
|
/** Sets the audio output context to be used with this encoder */
|
|
|
|
EXPORT void obs_encoder_set_audio(obs_encoder_t encoder, audio_t audio);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Returns the video output context used with this encoder, or NULL if not
|
|
|
|
* a video context
|
|
|
|
*/
|
|
|
|
EXPORT video_t obs_encoder_video(obs_encoder_t encoder);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the audio output context used with this encoder, or NULL if not
|
|
|
|
* a audio context
|
|
|
|
*/
|
|
|
|
EXPORT audio_t obs_encoder_audio(obs_encoder_t encoder);
|
|
|
|
|
2014-04-01 11:55:18 -07:00
|
|
|
/** Duplicates an encoder packet */
|
|
|
|
EXPORT void obs_duplicate_encoder_packet(struct encoder_packet *dst,
|
|
|
|
const struct encoder_packet *src);
|
|
|
|
|
|
|
|
EXPORT void obs_free_encoder_packet(struct encoder_packet *packet);
|
|
|
|
|
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
|
|
|
|
2013-11-20 14:00:16 -08:00
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Stream Services */
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -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
|
|
|
EXPORT const char *obs_service_getdisplayname(const char *id,
|
|
|
|
const char *locale);
|
|
|
|
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -07:00
|
|
|
EXPORT obs_service_t obs_service_create(const char *id, const char *name,
|
2014-01-27 22:14:58 -08:00
|
|
|
obs_data_t settings);
|
2013-11-20 14:00:16 -08:00
|
|
|
EXPORT void obs_service_destroy(obs_service_t service);
|
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
EXPORT const char *obs_service_getname(obs_service_t service);
|
|
|
|
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -07:00
|
|
|
/** Gets the default settings for a service */
|
|
|
|
EXPORT obs_data_t obs_service_defaults(const char *id);
|
|
|
|
|
|
|
|
/** Returns the property list, if any. Free with obs_properties_destroy */
|
|
|
|
EXPORT obs_properties_t obs_get_service_properties(const char *id,
|
|
|
|
const char *locale);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the property list of an existing service context, if any. Free with
|
|
|
|
* obs_properties_destroy
|
|
|
|
*/
|
|
|
|
EXPORT obs_properties_t obs_service_properties(obs_service_t service,
|
|
|
|
const char *locale);
|
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
/** Gets the service type */
|
|
|
|
EXPORT const char *obs_service_gettype(obs_service_t service);
|
|
|
|
|
|
|
|
/** Updates the settings of the service context */
|
|
|
|
EXPORT void obs_service_update(obs_service_t service, obs_data_t settings);
|
|
|
|
|
|
|
|
/** Returns the current settings for this service */
|
|
|
|
EXPORT obs_data_t obs_service_get_settings(obs_service_t service);
|
|
|
|
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -07:00
|
|
|
/** Returns the URL for this service context */
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
EXPORT const char *obs_service_get_url(obs_service_t service);
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -07:00
|
|
|
|
|
|
|
/** Returns the stream key (if any) for this service context */
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
EXPORT const char *obs_service_get_key(obs_service_t service);
|
|
|
|
|
|
|
|
/** Returns the username (if any) for this service context */
|
|
|
|
EXPORT const char *obs_service_get_username(obs_service_t service);
|
|
|
|
|
|
|
|
/** Returns the password (if any) for this service context */
|
|
|
|
EXPORT const char *obs_service_get_password(obs_service_t service);
|
libobs: Add services API, reduce repeated code
Add API for streaming services. The services API simplifies the
creation of custom service features and user interface.
Custom streaming services later on will be able to do things such as:
- Be able to use service-specific APIs via modules, allowing a more
direct means of communicating with the service and requesting or
setting service-specific information
- Get URL/stream key via other means of authentication such as OAuth,
or be able to build custom URLs for services that require that sort
of thing.
- Query information (such as viewer count, chat, follower
notifications, and other information)
- Set channel information (such as current game, current channel title,
activating commercials)
Also, I reduce some repeated code that was used for all libobs objects.
This includes the name of the object, the private data, settings, as
well as the signal and procedure handlers.
I also switched to using linked lists for the global object lists,
rather than using an array of pointers (you could say it was..
pointless.) ..Anyway, the linked list info is also stored in the shared
context data structure.
2014-04-19 20:38:53 -07:00
|
|
|
|
2013-11-20 14:00:16 -08:00
|
|
|
|
2014-02-09 04:51:06 -08:00
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
/* Source frame allocation functions */
|
|
|
|
EXPORT void source_frame_init(struct source_frame *frame,
|
|
|
|
enum video_format format, uint32_t width, uint32_t height);
|
|
|
|
|
|
|
|
static inline void source_frame_free(struct source_frame *frame)
|
|
|
|
{
|
|
|
|
if (frame) {
|
|
|
|
bfree(frame->data[0]);
|
|
|
|
memset(frame, 0, sizeof(struct source_frame));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct source_frame *source_frame_create(
|
|
|
|
enum video_format format, uint32_t width, uint32_t height)
|
|
|
|
{
|
|
|
|
struct source_frame *frame;
|
|
|
|
|
2014-02-09 11:34:07 -08:00
|
|
|
frame = (struct source_frame*)bzalloc(sizeof(struct source_frame));
|
2014-02-09 04:51:06 -08:00
|
|
|
source_frame_init(frame, format, width, height);
|
|
|
|
return frame;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void source_frame_destroy(struct source_frame *frame)
|
|
|
|
{
|
|
|
|
if (frame) {
|
|
|
|
bfree(frame->data[0]);
|
|
|
|
bfree(frame);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|