- Feb 23, 2014
-
-
Jim authored
Split off activate to activate and show callbacks, and split off deactivate to deactivate and hide callbacks. Sources didn't previously have a means to know whether it was actually being displayed in the main view or just happened to be visible somewhere. Now, for things like transition sources, they have a means of knowing when they have actually been "activated" so they can initiate their sequence. A source is now only considered "active" when it's being displayed by the main view. When a source is shown in the main view, the activate callback/signal is triggered. When it's no longer being displayed by the main view, deactivate callback/signal is triggered. When a source is just generally visible to see by any view, the show callback/signal is triggered. If it's no longer visible by any views, then the hide callback/signal is triggered. Presentation volume will now only be active when a source is active in the main view rather than also in auxilary views. Also fix a potential bug where parents wouldn't properly increment or decrement all the activation references of a child source when a child was added or removed.
-
- Feb 20, 2014
-
-
Jim authored
-
- Feb 14, 2014
-
-
Jim authored
There were a *lot* of warnings, managed to remove most of them. Also, put warning flags before C_FLAGS and CXX_FLAGS, rather than after, as -Wall -Wextra was overwriting flags that came before it.
-
- Feb 12, 2014
-
-
Jim authored
-
Jim authored
-
Jim authored
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.
-
- Feb 02, 2014
-
-
Jim authored
- Add property list callbacks to sources/outputs/encoders so that if necessary user interface can be automatically generated or perhaps a property list widget can be used for them. - Change some of the property API names. obs_property_list_t felt a bit awkward when actually using it, so I just renamed it to obs_properties_t. - Removed the getdata/setdata nad getparam/setparam functions from sources/services, they will be superseded by the dynamic procedure call API.
-
- Feb 01, 2014
-
-
Jim authored
Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
-
- Jan 28, 2014
-
-
Jim authored
- Add 'set_default' functions to obs-data.*. These functions ensure that a paramter exists and that the parameter is of a specific type. If not, it will create or overwrite the value with the default setting instead. These functions are meant to be explicitly called before using any of the 'get' functions. The reason why it was designed this way is to encourage defaults to be set in a single place/function. For example, ideal usage is to create one function for your data, "set_my_defaults(obs_data_t data)", set all the default values within that function, and then call that function on create/update, that way all defaults are centralized to a single place. - Ensure that data passed to sources/encoders/outputs/etc is always valid, and not a null value. - While I'm remembering, fix a few defaults of the main program config file data.
-
Jim authored
Add a fairly easy to use settings interface that can be passed to plugins, and replaced the old character string system that was being used before. The new data interface allows for an easier method of getting/altering settings for plugins, and is built to be serializable to/from JSON. Also, removed another wxFormBuilder file that was no longer in use.
-
- Jan 17, 2014
-
-
Jim authored
Just a minor fix mostly because I noticed that I kept accidentally forgetting to add checks to the code properly. This is one of those cases where macros come in useful, as macros can automate the process and help prevent these mistakes from happening by accident.
-
Jim authored
- 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.
-
- Jan 14, 2014
-
-
Jim authored
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.
-
- Jan 12, 2014
-
-
Jim authored
- Add preliminary (yet to be tested) handling of timestamp invalidation issues that can happen with specific devices, where timestamps can reset or go backward/forward in time with no rhyme or reason. Spent the entire day just trying to figure out the best way to handle this. If both audio and video are present, it will increment a reference counter if video timestamps invalidate, and decrement the reference counter when the audio timestamps invalidate. When the reference counter is not 0, it will not send audio as the audio will have invalid timing. What this does is it ensures audio data will never go out of bounds in relation to the video, and waits for both audio and video timestamps to "jump" together before resuming audio. - Moved async video frame timing adjustment code into obs_source_getframe instead so it's automatically handled whenever called. - Removed the 'audio wait buffer' as it was an unnecessary complexity that could have had problems in the future. Instead, audio will not be added until video starts for sources that have both async audio/video. Audio could have buffered for too long of a time anyway, who knows what devices are going to do. - Fixed a minor conversion warning in audio-io.c
-
- Jan 10, 2014
-
-
Jim authored
- Often, timestamps will go "back" in time with certain.. terrible devices that no one should use. When this occurs, timing is now reset so that the new audio comes in directly after the old audio seamlessly.
-
- Jan 07, 2014
-
-
Jim authored
- Added a volume variable to the obs_source structure and implemented functions for manipulating source volume. - Added a volume variable to the audio_data structure so that the volume will be applied when mixing.
-
- Jan 04, 2014
-
-
Jim authored
Scenes will now signal via their source when an item has been added or removed from them. "add" - Item added to the scene. Parameters: "scene": Scene that the item was added to. "item": Item that was added. "remove" - Item removed from the scene. Parameters: "scene": Scene that the item was removed from. "item": Item that was removed.
-
- Dec 30, 2013
-
-
Jim authored
-
- Dec 27, 2013
-
-
Jim authored
-
- Dec 20, 2013
- Dec 03, 2013
-
-
Jim authored
With the permission of my fellow contributors, I'm switching obs-studio back to GPL v2+ to prevent issues between this project and the original OBS project, and for personal reasons to avoid legal ambiguity (not political reasons, I admittedly would prefer GPL v3+)
-
- Nov 20, 2013
- Nov 13, 2013
-
-
Jim authored
added support for jansson, added new output files, made some adjustments to the API, fixed a UI subclass issue
-
- Oct 31, 2013
-
-
Jim authored
finish up most of the source audio stuff and rename some variables/structs/enum to be a bit more consistent
-
- Oct 26, 2013
- Oct 24, 2013
-
-
Jim authored
added intial async audio/video code, fixed a few bugs, improved thread safety, and made a few other minor adjustments
-
- Oct 17, 2013
-
-
Jim authored
-
- Oct 14, 2013
-
-
Jim authored
change names, fix some bugs, minor GL/D3D fixes, update tests, fix effect files, output a little more debug information
-
Peter SZTANOJEV authored
-
- Oct 01, 2013
-
-
Jim authored
-
- Sep 30, 2013
-
-
Jim authored
-