I've come to realize that it's probably not wise to deviate from the
original version's functionality due to the fact that the original
version works without issues. I'm wondering if some of the capture
problems have been due to the fact that the direct hook method (via
CreateRemoteThread) was removed, so I put it back in, made it default,
and added an option to use anti-cheat compatibility just like in the
original version.
Certain input streams (such as remote streams that are already active)
can start up mid-stream with a very high initial timestamp values.
Because of this, it would cause the libff timer to delay for that
initial timestamp, which often would cause it to not render at all
because it was stuck waiting.
To fix the problem, we should ignore the timestamp difference of the
first frame when it's above a certain threshold.
Now that we're using the timestamps from the stream for playback,
certain types of streams and certain file formats will not start from a
pts of 0. This causes the start of the playback to be delayed. This
code simply ensures that there's no delay on startup. This is basically
the same code as used in FFmpeg itself for handling this situation.
Adds setting profiles to the basic user interface. For each profile, a
subdirectory for the profile will be created in
[config_dir]/obs-studio/basic/profiles which will contain the settings
data for each profile.
Adds scene collections to the menu bar, which allows you to duplicate,
rename, remove, or add clean new scene collections.
Scene files are now stored in ./obs-studio/basic/scenes directory with
filesystem-safe names.
This particularly affected audio encoding, audio encoding previously
would count samples and use it to create an encoding timestamp, but
because I was using a standard integer (which is 32bit by default on
x86), it would max out at about 0x7FFFFFFF samples, which is about 12
hours of samples at 48000 sample rate. After that, it would start going
into negative territory (overflowing). By changing it to int64_t, it
will make it so that audio at 48000 samples per second would only be
able to overflow after about.. 6.09 million years. In other words,
this should fix the issue for good.
Livecoding.tv (coding), gaminglive.tv (gaming), and beam.pro
(gaming/music)
I really don't see any problems with adding these particular services to
the local list while the actual remote ingest lookup code has yet to be
even started yet (as of this writing). They seem to be harmless
services that are dedicated to specific types of content (stated above).
When hooking 64bit functions, sometimes the offset between the function
being hooked and the hook itself can be large enough to where it
requires a 64bit offset to be used. However, because a 64bit jump
requires overwriting so many code instructions in the function, it can
sometimes overwrite code in to an adjacent function, thereby causing a
crash.
The 64bit hook bounce (created by R1CH) is designed to prevent using
very long jumps in the target by creating executable memory within a
32bit offset of that target, and then writing it with the 64bit long
jump instruction instead. Then in the target function, it will jump to
that memory instead, thus forcing the actual hooked function to use a
32bit hook instead of a 64bit hook, and using at most 5 bytes for the
actual hook, preventing any likelihood of it overwriting an adjacent
function.
Originally this value defaulted to 1.5 downscaling, but on very high
resolution displays this would cause the default to be above 1280x720,
which is not ideal for streaming/recording due to the CPU usage
requirements.
Instead, it will now find the closest resolution with a pixel count
equivalent to or closest below 1280x720, and use that instead.
This prevents the weird stretching effect that occurs whenever a windows
is in the process of being resized by the user.
Originally it was intended as an optimization, but even on half-decent
computers it doesn't really have much benefit.
Apparently some raw lingering pointers to the item widgets may be
present inside of the QListView if you delete the item widgets directly,
and the only way to ensure those pointers are properly cleared is to
call ->clear() on the list widget instead of deleting each item
individually.
We were deleting each item individually because we thought that
->deleteLater might be also be called on other data within, but after
some testing, that turned out to not be the case, so it's safe to call
->clear() on the list widget.
As a note, deleting item widgets directly is dangerous due to the
potential for lingering raw internal pointers, and our case is unique
where we can get away with it; do not delete list item widgets directly
unless you intend on calling ->clear() or ->takeItem on the specific
item you do it to after.
Again, the reason why we are deleting list widget items manually is due
to the fact that Qt will always use ->deleteLater() on them if they are
not deleted manually, which puts their deletion on the queue. Only
problem is they cannot be removed from the queue once added, so
lingering references to sources will persist until the queue processes
them, which causes major problems if we need those objects deleted right
away.
When initializing with a default scene, save the data to ensure a file
is actually present when needed (such as for scene collections which may
need the file)
Add a central function for clearing all data: scenes, sources, widgets
such as lists that may contain source references in their sub-items,
dialogs which may contain source references. In certain circumstances
this data must be fully released and manually freed to ensure that there
are no outstanding references to obs data (such as on shutdown, where
all data should be properly freed).
These functions are designed to manually delete item widgets within
other widgets to prevent ->deleteLater from being called on them. This
prevents the item widgets from being stuck in the event queue, and
prevents references to things like sources from being stuck in the event
queue along with them if they're used in the item widget's class or
functions.
Right now, information about global audio sources is stored in both
scene files and in the config. These must be separated; there's no need
to store them in both when they can just be stored in the scenes file.
jp9000
Palana
Gol-D-Ace