I encountered a situation where I wanted to delete a callback for a
signal while inside of that signal. However it would hard lock, and
even after that, it would mess up the loop for the callback list.
So, change the mutex of the individual signals to a recursive-style
mutex, and then if a callback of a signal is deleted while currently in
that signal, just mark it for deletion, which will happen after the
signal is complete.
Previously we were using glGetAttribLocation on all inputs/outputs and
then just discarding if it was returned -1. However, we have a boolean
value of 'input' in gl_parser_attrib, so there's no need to be doing
this and discarding potentially useful error handling information.
BGRX was being treated as "BGR input" with "RGBA storage", where it
should have been "BGRA input" with "RGB storage". So the input for the
texture was expecting 24 bits of packed BGR rather than 32bit BGRX
pixels, and was internally storing it with alpha available.
Apparently, despite the fact that Apple added
kAudioHardwarePropertyTranslateUIDToDevice in 10.8, it's not actually
usable in 10.8, only 10.9. So, instead of being able to use it like a
normal, sane person, we have to enumerate all devices manually and find
the AudioDeviceID ourselves. A slight annoyance and a mark against
apple's competence, but audio devices should now be working again on
10.8 at least, so whatever.
This adds support for the more smooth volume levels that accounts for
both level and magnitude. Currently, it just averages level and
magnitude, later on a full audio meter control can be made that would
properly utilize level, magnitude, and peak.
Also cleaned up the code a bit and removed some trailing whitespace.
This replaces the older code which simply queried the max volume level
value for any given audio.
I'm still not 100% sure on if this is how I want to approach the
problem, particularly, whether this should be done in obs_source or in
audio_line, but it can always be moved later if needed.
This uses the calculations by the awesome Bill Hamilton that OBS1 used
for its volume levels. It calculates the current max (level),
magnitude, and current peak. This data then can be used to create
awesome volume meter controls later on.
NOTE: Will probably need optimization, does one float at a time right
now.
Also, change some of the naming conventions. I actually need to change
a lot of the naming conventions in general so that all words are
separated by underscores. Kind of a bad practice there on my part.
The biggest problem with DirectShow is that available configuration
capabilities can change if you so much as look at it the wrong way.
Previously, configuring devices often didn't configure the device
settings correctly, you would choose one setting and then another
setting wouldn't be compatible with that settings.
Let's take the terrible microsoft lifecam series for example. First,
you'd be at 640x480 happily webcam'ing away, which is using the YUY2
format. Then you decide "hey, this webcam resolution is a bit low. I
would love to have it a bit high resolution so it's a bit more crisp and
clear." You'd select 1280x720, and then suddenly the only format
supported is MJPEG output. However, the interface has to update that
fact, it can't list YUY2 if MJPEG is the only one available for this
resolution. This doesn't just apply to formats either, this applies to
framerates and such as well. Some framerates will only be supported by
certain resolutions which can in turn only be supported by certain
formats.
This causes user interface for configuration to be really be a nightmare
to manage if you want these features to be available to the user. It's
extremely annoying because you have to update all the configuration UI
after something has changed, double check the configuration values, and
if the values aren't supported, update those configuration values.
This covers the basics of devices. Mostly functional but not at 100%
yet. Uses 'libdshowcapture' library to capture directshow video/audio.
Both libdshowcapture and the plugin still need some work. Should at
least capture basic webcams and capture cards for the time being.
There was a fundamental flaw with the string type conversion functions
where the sizes were not being properly accounted for. They were using
the 'len' value as a value for the output rather than only for the
input, which was bad because the output could have more or less
characters than the input.
jp9000
Palana
Danni