1. 26 1月, 2014 15 次提交
  2. 25 1月, 2014 15 次提交
  3. 24 1月, 2014 4 次提交
    • B
      Clean old cmake files · 8fa309c9
      BtbN 提交于
      8fa309c9
    • J
      Merge branch 'qt-ui' · 610d4415
      jp9000 提交于
      610d4415
    • J
      Fix render issues with main preview widget · 4cba9d33
      jp9000 提交于
       - I seem to have fixed ths issues with the main preview widget.  It
         seems you just need to set the right window attributes to stop it from
         breaking.  Though when opengl is enabled, there appears to be a weird
         background glitch in the Qt stuff -- I'm not entirely sure what's
         going on.  Bug in Qt?
      
         Also fixed the layout issues, and the widget now properly resizes and
         centers in to its parent widget.
      
       - Prevent the render loop from accessing data if the data isn't valid.
         Because obs->data is freed before the graphics stuff, it can cause
         the graphics to keep trying to query the obs->data.displays_mutex
         after it had already been destroyed.
      4cba9d33
    • J
      Change the UI to Qt (work in progress) · afeed34b
      jp9000 提交于
      ```-----------------------------------------------
      Notes and details
      ```
      
      -----------------------------------------------
      Why was this done?  Because wxWidgets was just lacking in many areas.  I
      know wxWidgets is designed to be used with native controls, and that's
      great, but wxWidgets just is not a feature-complete toolkit for
      multiplatform applications.  It lacks in dialog editors, its code is
      archaic and outdated, and I just feel frustrated every time I try to do
      things with it.
      
      Qt on the other hand..  I had to actually try Qt to realize how much
      better it was as a toolkit.  They've got everything from dialog editors,
      to an IDE, a debugger, build tools, just everything, and it's all
      top-notch and highly maintained.  The focus of the toolkit is
      application development, and they spend their time trying to help
      people do exactly that:  make programs.  Great support, great tools,
      and because of that, great toolkit.  I just didn't want to alienate any
      developers by being stubborn about native widgets.
      
      There *are* some things that are rather lackluster about it and design
      choices I disagree with though.  For example, I realize that to have an
      easy to use toolkit you have to have some level of code generation.
      However, in my personal and humble opinion, moc just feels like a
      terrible way to approach the problem.  Even now I feel like there are a
      variety of ways you could handle code generation and automatic
      management of things like that.  I don't like the idea of circumventing
      the language itself like that.  It feels like one giant massive hack.
      
      --------------------------------------------------
      Things that aren't working properly:
      --------------------------------------------------
       - Settings dialog is not implemented.  The dialog is complete but the
         code to handle the dialog hasn't been constructed yet.
      
       - There is a problem with using Qt widgets as a device target on
         windows, with at least OpenGL: if I have the preview widget
         automatically resize itself, it seems to cause some sort of video
         card failure that I don't understand.
      
       - Because of the above, resizing the preview widget has been disabled
         until I can figure out what's going on, so it's currently only a
         32x32 area.
      
       - Direct3D doesn't seem to render correctly either, seems that the
         viewport is messed up or something.  I'm sort of confused about
         what's going on with it.
      
       - The new main window seems to be triggering more race conditions than
         the wxWidgets main window dialog did.  I'm not entirely sure what's
         going on here, but this may just be existing race conditions within
         libobs itself that I just never spotted before (even though I tend to
         be very thorough with race conditions any time I use variables
         cross-thread)
      afeed34b
  4. 20 1月, 2014 2 次提交
  5. 19 1月, 2014 1 次提交
    • J
      Add preliminary ffmpeg plugin (still testing) · fc8851e9
      jp9000 提交于
      - Added some code for FFmpeg output that I'm still playing around with.
        Right now I'm just trying to get it to output to file and try to
        understand the FFmpeg/libav APIs.  Hopefully in the future this plugin
        can be used for any sort of output to FFmpeg.
      
      - Fixed a cast warning in audio-io.c with size_t -> uint32_t
      
      - Renamed the 'video_info' and 'audio_info' structures to
        'video_conver_info' and 'audio_convert_info' to better represent their
        actual purpose, and to avoid confusion with 'audio_output_info' and
        'video_output_info' structures.
      
      - Removed a few macros from obs-def.h that were at one point going to be
        used but no longer going to be used (at least for now)
      fc8851e9
  6. 17 1月, 2014 3 次提交
    • J
      Use macros to improve safety loading callbacks · 8d63845d
      jp9000 提交于
      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
    • J
      Updated comments for outputs/encoders · ff1afac5
      jp9000 提交于
      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.
      ff1afac5
    • J
      Add preliminary output/encoder interface · 29b7d362
      jp9000 提交于
      - 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