Commit Graph

11 Commits (1044fa0e8654076c88505dc1d2b2ab38001b5c09)

Author SHA1 Message Date
jp9000 966b943d5b Remove majority of warnings
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.
2014-02-14 15:13:36 -07:00
jp9000 8e81d8be56 Revamp API and start using doxygen
The API used to be designed in such a way to where it would expect
exports for each individual source/output/encoder/etc.  You would export
functions for each and it would automatically load those functions based
on a specific naming scheme from the module.

The idea behind this was that I wanted to limit the usage of structures
in the API so only functions could be used.  It was an interesting idea
in theory, but this idea turned out to be flawed in a number of ways:

 1.) Requiring exports to create sources/outputs/encoders/etc meant that
     you could not create them by any other means, which meant that
     things like faruton's .net plugin would become difficult.

 2.) Export function declarations could not be checked, therefore if you
     created a function with the wrong parameters and parameter types,
     the compiler wouldn't know how to check for that.

 3.) Required overly complex load functions in libobs just to handle it.
     It makes much more sense to just have a load function that you call
     manually.  Complexity is the bane of all good programs.

 4.) It required that you have functions of specific names, which looked
     and felt somewhat unsightly.

So, to fix these issues, I replaced it with a more commonly used API
scheme, seen commonly in places like kernels and typical C libraries
with abstraction.  You simply create a structure that contains the
callback definitions, and you pass it to a function to register that
definition (such as obs_register_source), which you call in the
obs_module_load of the module.

It will also automatically check the structure size and ensure that it
only loads the required values if the structure happened to add new
values in an API change.

The "main" source file for each module must include obs-module.h, and
must use OBS_DECLARE_MODULE() within that source file.

Also, started writing some doxygen documentation in to the main library
headers.  Will add more detailed documentation as I go.
2014-02-12 08:04:50 -07:00
jp9000 b067440f73 Use bzalloc instead of bmalloc then memset
Reduces needless code repetition and still allows for proper memory
alignment.  Cleans up the code a bit.
2014-02-09 12:34:07 -07:00
jp9000 458325fc6f Add property list callbacks
- Add property list callbacks to sources/outputs/encoders so that if
  necessary user interface can be automatically generated or perhaps a
  property list widget can be used for them.

- Change some of the property API names.  obs_property_list_t felt a bit
  awkward when actually using it, so I just renamed it to
  obs_properties_t.

- Removed the getdata/setdata nad getparam/setparam functions from
  sources/services, they will be superseded by the dynamic procedure
  call API.
2014-02-01 22:46:13 -07:00
jp9000 9116be8d9c Improve safety for settings usage
- 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.
2014-01-28 18:41:24 -07:00
jp9000 c6300d0956 Add a couple more setting data safety measures
Prevent null dereferencing if data is null, instead just make the
functions return and ignore the get/set requests.
2014-01-28 15:45:30 -07:00
jp9000 6c44291693 Implement settings interface for plugins
Add a fairly easy to use settings interface that can be passed to
plugins, and replaced the old character string system that was being
used before.  The new data interface allows for an easier method of
getting/altering settings for plugins, and is built to be serializable
to/from JSON.

Also, removed another wxFormBuilder file that was no longer in use.
2014-01-27 23:14:58 -07:00
jp9000 563613db8f Rename obs-data.h to obs-internal.h
Renaming obs-data.h to avoid confusion about its usage
2014-01-26 18:48:14 -07:00
jp9000 8d63845dd4 Use macros to improve safety loading callbacks
Just a minor fix mostly because I noticed that I kept accidentally
forgetting to add checks to the code properly.  This is one of those
cases where macros come in useful, as macros can automate the process
and help prevent these mistakes from happening by accident.
2014-01-17 06:24:34 -07:00
jp9000 ff1afac5f8 Updated comments for outputs/encoders
Changed the comments to properly reflect the new callbacks, as I had
forgotten to update the comments for them both.

Also, changed "setbitrate" and "request_keyframe" return values to be
boolean.
2014-01-17 00:00:21 -07:00
jp9000 29b7d3621c 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 22:34:51 -07:00