First, if the private data of the source fails to be created, then do
not destroy the source. If the source is destroyed, all the user's data
associated with that source is lost, which could end up being a
potential problem. Instead, let it linger as a 'dead' source until the
user chooses to fix the problem (though this should never really happen,
the source module functions should be programmed to handle this
scenario)
Secondly, rename new_frame_ready to ready_async_frame, and fix a
potential memory leak with it.
obs_source_output_video can cause cached frames to be freed twice if
called with a partially destroyed source, among other undesirable
effects; freeing the source private data right after the destroy signal
has been processed ensures proper behavior
- Add volume control
These volume controls are basically nothing more than sliders. They
look terrible and hopefully will be as temporary as they are
terrible.
- Allow saving of specific non-user sources via obs_load_source and
obs_save_source functions.
- Save data of desktop/mic audio sources (sync data, volume data, etc),
and load the data on startup.
- Make it so that a scene is created by default if first time using the
application. On certain operating systems where supported, a default
capture will be created. Desktop capture on mac, particularly. Not
sure what to do about windows because monitor capture on windows 7 is
completely terrible and is bad to start users off with.
I had forgotten how constants worked when compiled; constants are
uploaded as constant registers. When constants are used with shaders,
multiple constants are often packed in to a single register when
possible to reduce constant register count.
For example, one 'float' constant and one 'float3' constant will be
packed in to a single register (c0.x for constant 1, c0.yzw for constant
2), but two 'float' constants and one 'float3' constant must inhabit two
registers (c0.xy for constant 1, c1.xyz for constant 2), so it must
start on a new register boundry (every 16 bytes).
I had first instinctively thought it was just a simple case of
alignment like it is on the CPU, but then I realized that it didn't
sound right, so I went back and did some more tests and then ultimately
remembered how constants actually are uploaded.
Starting with VS2012, microsoft made a terribly stupid change to the way
working directory is handled. It basically will not work properly if
you need to run your executable from a specific location, it would only
run properly from debug if you also had your target directory set to an
environment variable, which was incredibly stupid. The visual studio
development team is run by chimpanzees with tiny brains, headed by
a broken AI core designed by gilbert gottfried.
I made a workaround for it so that it's much easier to set up debugging
in VS2013, so that all you need to do is enter in the the working
directory for it to work properly. Still somewhat of a pain but the Qt
addin kept overwriting the god forsaken environment path, and made
setting it up much more difficult than it was supposed to be.
If a source with async video wasn't currently active, it would endlessly
buffer the video data, which would cause memory to grow endlessly until
available memory was extinguished.
This really needs to be replaced with a proper caching mechanism at some
point.
With this option enabled the plugin will generate timestamps
based on the system time instead of using the ones provided by
pulse audio. This might fix problems with audio desync and may
become the default/only option in the future.
The defaults functions will now return the default device for the
input/output as provided by pulseaudio.
The default output device is the monitor of the default sink.
This saves scenes/sources from json on exit, and properly loads it back
up when starting up the program again, as well as the currently active
scene.
I had to add a 'load' and 'save' callback to the source interface
structure because I realizes that certain sources (such as scenes)
operate different with their saved data; scenes for example would have
to keep track of their settings information constantly, and that was
somewhat unacceptable to make it functional.
The optional 'load' callback will be called only after having loaded
setttings specifically from file/imported data, and the 'save' function
will be called only specifically when data actually needs to be saved.
I also had to adjust the obs_scene code so that it's a regular input
source type now, and I also modified it so that it doesn't have some
strange custom creation code anymore. The obs_scene_create function is
now simply just a wrapper for obs_source_create. You could even create
a scene with obs_source_create manually as well.
The 'wait' constant was a terrible means of trying to ensure that the
packets were interleaved. Instead, calculate the current highest
timestamps of each encoder that's present in the interleaved buffer, and
use that as a means of detecting whether the current packet should be
sent off. This will guarantee sorting without relying on some arbirary
constant that 'assumes' that it'll be interleaved. It also reduces
buffering any more than what is needed to interleave.
It didn't really look very nice in most cases and the controls were
always compacted, doing this makes it look a bit better.
Also change it so the properties window shows the properties on the
bottom below the source rather than to the right, seeing as in most
cases the source has a greater width than height, and it feels just a
little bit better to look at (thought that's just my opinion).
Controls still stretch really far sometimes though, I wonder what should
be done about that to be honest. Maybe prevent it from scrolling to the
right?
BtbN
Palana
jp9000
paibox
fryshorts