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.
When a source's private data is being created by a module, it wasn't
able to call most source functions because most functions rely on the
obs_source_info part of the context to be set. This fixes that issue.
It was strange that this wasn't already the case because the other
context types already did the same thing.
This uses the reverse planar YUV 4:2:0 conversion shader to output a YUV
texture without having to convert it via CPU. Again, this will reduce
video upload bandwidth usage to 37.5% of the original rate. I suspect
this will be particularly useful for when an FFmpeg or libav input
plugin for playing videos is made.
NOTE: There's an issue with certain texture sizes right now I haven't
been able to identify, if the full size of texture data divided by the
base texture width is an uneven number, the V chroma plane seems like it
can potentially shift, though I only had this happen with 160x90
resolution C920. Almost all resolutions tend to be even. Needs further
testing with more devices that support planar YUV 4:2:0 output.
This adds button support to properties, which will allow a properties
pane to let the user click a button to activate something with a
particular obs context. When pressed, the button will execute the
callback given, with the context's private data as a parameter.
