Commit Graph

24 Commits (796ad993359e97c9cd684bc9a5e17713dc42ade1)

Author SHA1 Message Date
jp9000 b13ae5cac6 Fix jannson_config.h for vs proj files 2014-05-01 03:51:44 -07:00
Palana 9f43e6c257 Add yuv_to_rgb matrices and video_format_get_parameters utility 2014-04-24 16:47:06 +02:00
Palana b77b9feb61 Add helper to convert from FOURCC to VIDEO_FORMAT 2014-04-24 16:46:54 +02:00
jp9000 8830c4102f 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 02:19:03 -07:00
jp9000 4a6d19f206 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
jp9000 b6c1439778 Remove /SAFESEH compiler flag from 32bit release
For the strangest reason, it would cause errors when linking to ffmpeg
on the 32bit windows release build
2014-04-14 13:47:04 -07:00
jp9000 92522d1886 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
jp9000 0cf9e0cfdd Add preliminary FLV/RTMP output (incomplete)
- obs-outputs module:  Add preliminary code to send out data, and add
   an FLV muxer.  This time we don't really need to build the packets
   ourselves, we can just use the FLV muxer and send it directly to
   RTMP_Write and it should automatically parse the entire stream for us
   without us having to do much manual code at all.  We'll see how it
   goes.

 - libobs:  Add AVC NAL packet parsing code

 - libobs/media-io:  Add quick helper functions for audio/video to get
   the width/height/fps/samplerate/etc rather than having to query the
   info structures each time.

 - libobs (obs-output.c):  Change 'connect' signal to 'start' and 'stop'
   signals.  'start' now specifies an error code rather than whether it
   simply failed, that way the client can actually know *why* a failure
   occurred.  Added those error codes to obs-defs.h.

 - libobs:  Add a few functions to duplicate/free encoder packets
2014-04-01 11:55:18 -07:00
jp9000 4f7ab552df Reimplement monitor capture
- Implement windows monitor capture (code is so much cleaner than in
   OBS1).  Will implement duplication capture later

 - Add GDI texture support to d3d11 graphics library

 - Fix precision issue with sleep timing, you have to call
   timeBeginPeriod otherwise windows sleep will be totally erratic.
2014-03-05 10:43:14 -07:00
jp9000 e9342143a7 Simplify and extend callback/signalling system
- Signals and dynamic callbacks now require declarations to be made
  before being used.  What this does is allows us to get information
  about the functions dynamically which can be relayed to the user and
  plugins for future extended usage (this should have big implications
  later for scripting in particular, hopefully).

- Reduced the number of types calldata uses from "everything I could
  think of" to simply integer, float, bool, pointer/object, string.
  Integer data is now stored as long long.  Floats are now stored as
  doubles (check em).

- Use a more consistent naming scheme for lexer error/warning macros.

- Fixed a rather nasty bug where switching to an existing scene would
  cause it to increment sourceSceneRefs, which would mean that it would
  never end up never properly removing the source when the user clicks
  removed (stayed in limbo, obs_source_remove never got called)
2014-03-01 05:54:55 -07:00
jp9000 5441dca937 Fix VS2013 project files
Last commit was on mac so I was unable to incude the VS project files
additions for threading-windows.c.
2014-02-26 23:56:48 -07:00
jp9000 f2d4de3c03 Implement automatic video scaling (if requested)
Add a scaler interface (defaults to swscale), and if a separate output
wants to use a different scale or format than the default output format,
allow a scaler instance to be created automatically for that output,
which will then receive the new scaled output.
2014-02-18 13:37:56 -07:00
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 4bc282f5e9 Rename obs_viewport to obs_view
I felt like the name could cause a bit of confusion with typical
graphics viewports, so I just changed it to view instead.
2014-02-13 10:21:16 -07:00
jp9000 515f44be8e Revamp rendering system to allow custom rendering
Originally, the rendering system was designed to only display sources
and such, but I realized there would be a flaw; if you wanted to render
the main viewport in a custom way, or maybe even the entire application
as a graphics-based front end, you wouldn't have been able to do that.

Displays have now been separated in to viewports and displays.  A
viewport is used to store and draw sources, a display is used to handle
draw callbacks.  You can even use displays without using viewports to
draw custom render displays containing graphics calls if you wish, but
usually they would be used in combination with source viewports at
least.

This requires a tiny bit more work to create simple source displays, but
in the end its worth it for the added flexibility and options it brings.
2014-02-13 08:58:31 -07:00
jp9000 4be4dd735e Use force inlining of YUV conversion functions
Force inling of the 444->420 conversion functions because their CPU
usage goes up pretty heavily without it when compiling without
optimizations
2014-02-09 07:59:00 -07:00
jp9000 0d17d13116 Implement properties definition interface
Implement a properties definition interface to allow modules to export
general properties associated with objects of libobs.

The properties definition interface allows the option for automatic
settings UI generation (which will make simple plugins easier to develop
without the need for user interface), as well as allow real-time
property editing of values of things like sources/outputs/etc without
having to open property dialogs.  More property types can be added in
the future as needed as well.
2014-02-01 18:01:31 -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 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
jp9000 62c2b1d74e 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 01:58:47 -07:00
jp9000 6ac6256ac5 fill in rest of signal/callback/proc 2013-12-26 04:26:17 -07:00
jp9000 e9ded173f1 add my signal/callback interface from another project, also update license of utility files to ISC 1.3 2013-12-25 22:40:33 -07:00
jp9000 aead95f5e3 converted project to vs2013, removed 2010 support (ugh) 2013-12-14 16:01:30 -07:00