If FFmpeg's experimental aac encoder is used, this changes the cutoff
frequency to better values in order to try to help make up for the
inherent lack of encoder quality a bit. If FFmpeg is compiled to use
another encoder by default, these settings will not be applied.
This function simplifies drawing textures for sources in order to help
reduce boilerplate code. If a source is a custom drawn source, it will
automatically set up the effect to draw the sprite. If it's not a
custom drawn source, it will simply draw the sprite as per normal. If
the source uses a specific color matrix, it will also handle that as
well.
When the image data is copied into a texture with flipping set to true
each row has to be copied into the (height - row - 1)th row instead of
the row with the same number. Otherwise it will just create an unflipped
copy.
XComposite, which is currently our only capture method for windows,
doesn't handle X border width. This works in a lot of cases but anytime
there's a border, a bug occurs where the lower right is clipped. This
patch has two goals:
1) To position and size the capture texture correctly in accordance to
the border.
2) Adds a configuration option to allow people to toggle it (which in
most cases will simply do nothing) with a default of not including it.
Apparently the audio isn't guaranteed to start up past the first video
frame, so it would trigger that assert (which I'm glad I put in). I
didn't originally have this happen when I was testing because my audio
buffering was not at the default value and didn't trigger it to occur.
A blunder on my part, and once again a fine example of how you should
never make assumptions about possible code path.
Some applications defer loading OpenGL until after they are visible as
running applications, which causes SyphonInject to not install a server
on the first try (e.g. Minecraft does this)
In some cases the actual application (bundle identifier) would get
overwritten with a wrapper application bundle identifier when the
application names matched (this happened with e.g., Minecraft)
This adds helper function to disable/enable all properties which is
used in the device selected callback to enable/disable the properties
when the selected device is available/unavailable.
This adds some code to the device enumeration that checks if the
currently selected device is present. In case it is not it will
add the device but disable it.
This moves the calls to the property modified functions so the old
handler can close the device. Otherwise this would cause the device
to be opened multiple times.
This replaces the var in the source struct that are handling the
timestamp offset with a local one in the capture thread.
This change is mostly to make the code more readable.
This moves the enabling/resetting of the file descriptors inside the
capture loop so it is done before each select call. Why this even worked
before is unclear, but doing it the *right* way seems to reduce latency.
Transparency is now disabled by default, so that alpha values from
injected back buffers don't propagate to OBS (e.g. Minecraft doesn't
render properly in OBS unless "Allow Transparency" is disabled)
When a new device starts up, make it so that the first timestamp that
occurs starts from 0. This prevents the internal source timestamp
handling from trying to buffer new frames to the new timestamp value in
case the device changes.
Due to potential driver issues with certain devices, the timestamps are
not always reliable. This option allows of using the time in which the
frame was received as a timestamp instead.
This moves the 'flags' variable from the obs_source_frame structure to
the obs_source structure, and allows user flags to be set for a specific
source. Having it set on the obs_source_frame structure didn't make
much sense.
OBS_SOURCE_UNBUFFERED makes it so that the source does not buffer its
async video output in order to try to play it on time. In other words,
frames are played as soon as possible after being received.
Useful when you want a source to play back as quickly as possible
(webcams, certain types of capture devices)
This reverts commit c3f4b0f018.
The obs_source_frame should not need to take flags to do this. This
shouldn't be a setting associated with the frame, but rather a setting
associated with the source itself. This was the wrong approach to
solving this particular problem.
This reverts commit cd306d975a.
This removes the 'unbuffered' property for the time being. There should
be a better way of handling this, such as using system timestamps.
Also, the obs_source_frame::flags member needs to be removed and
replaced with something a bit more ideal.
This bug would happen if audio packets started being received before
video packets. It would erroneously cause audio packets to be
completely thrown away, and in certain cases would cause audio and video
to start way out of sync.
My original intention was "don't accept audio until video has started",
but instead mistakenly had the effect of "don't start audio until a
video packet has been received". This was originally was intended as a
way to handle outputs hooking in to active encoders and compensating
their existing timestamp information.
However, this made me realize that there was a major flaw in the design
for handling this, so I basically rewrote the entire thing.
Now, it does the following steps when inserting packets:
- Insert packets in to the interleaved packet array
- When both audio/video packets are received, prune packets up until the
point in which both audio/video start at the same time
- Resort the interleaved packet array
I have tested this code extensively and it appears to be working well,
regardless of whether or not the encoders were already active with
another output.
In video-io.c, video frames could skip, but what would happen is the
frame's timestamp would repeat for the next frame, giving the next frame
a non-monotonic timestamp, and then jump. This could mess up syncing
slightly when the frame is finally given to an outputs.
Apparently I unintentionally typed received_video = false twice instead
of one for video and one for audio.
This fixes a bug where audio would not start up again on an output that
had recently started and then stopped.
When the output sets a new audio/video encoder, it was not properly
removing itself from the previous audio/video encoders it was associated
with. It was erroneously removing itself from the encoder parameter
instead.
jp9000
fryshorts
Christoph Hohmann
Eric Bataille
Zachary Lund
Palana
dodgepong
Gol-D-Ace