Skip to content
Snippets Groups Projects
  1. Feb 01, 2014
    • Jim's avatar
      Add module UI export capability · a12656bd
      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.
      a12656bd
  2. Jan 28, 2014
    • Jim's avatar
      Improve safety for settings usage · 9116be8d
      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.
      9116be8d
    • Jim's avatar
      Implement settings interface for plugins · 6c442916
      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.
      6c442916
  3. Jan 17, 2014
    • Jim's avatar
      Use macros to improve safety loading callbacks · 8d63845d
      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.
      8d63845d
    • Jim's avatar
      Add preliminary output/encoder interface · 29b7d362
      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.
      29b7d362
  4. Jan 14, 2014
    • Jim's avatar
      Simplify media i/o interfaces · 62c2b1d7
      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.
      62c2b1d7
  5. Jan 12, 2014
    • Jim's avatar
      Add preliminary handling of timestamp invalidation · 9f1a3c31
      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
      9f1a3c31
  6. Jan 10, 2014
    • Jim's avatar
      Detect audio timestamp jumps and reset timing · 2a893064
      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.
      2a893064
  7. Jan 07, 2014
    • Jim's avatar
      Implement volumes for sources · 3838abe1
      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.
      3838abe1
  8. Jan 04, 2014
    • Jim's avatar
      Added add/remove signals to scenes · a2a8a5f1
      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.
      a2a8a5f1
  9. Dec 30, 2013
  10. Dec 27, 2013
  11. Dec 20, 2013
  12. Dec 03, 2013
  13. Nov 20, 2013
  14. Nov 13, 2013
  15. Oct 31, 2013
  16. Oct 26, 2013
  17. Oct 24, 2013
  18. Oct 17, 2013
  19. Oct 14, 2013
  20. Oct 01, 2013
  21. Sep 30, 2013
Loading