Warns users that two separate QSV encoders can't be active at the same
time.
This should be considered a temporary solution to two issues:
1.) Encoders need to be able to report these errors themselves
2.) If the QSV encoder is ever changed to allow more than one encoder at
the same time this should be removed
Currently, multiple QSV encoders cannot be active at the same time
(otherwise it will crash). This is a temporary solution to prevent
crashes from occurring when more than one QSV encoder tries to start up
at the same time.
Additionally, in the future there should be a way for encoders to be
able to communicate with the front-end when an error such as this
occurs.
If the parent source of a scroll filter has a 0 width or 0 height, the
scroll filter would do a division by zero on the size_i variable, which
would then cause the offset variable to perpetually have a non-finite
value, thus preventing the scroll filter from rendering properly after
that due to the non-finite offset value being uploaded to the shader.
(Note: this commit also modifies the obs-filters and test-input modules)
Changes the obs_source_process_filter_begin return type so that it
returns true/false to indicate that filter processing should or should
not continue (for example if the filter is bypassed or if there's some
other sort of issue that causes the filtering to fail)
On outputs that use already-active video/audio encoder, the audio
pruning to sync up audio packets with video packets doesn't always get
called (for example if the video pruning function was called). Always
prune excess starting audio packets.
How to crash:
1. Use recent ffmpeg shared libraries.
2. Add a ffmpeg_source, a small static picture (e.g. jpeg) with loop
3. After a while of high cpu usage, it crashed. Seems reproduced more
easily on faster computer
Closes#533
Fixes a race condition during shutdown where the dialogs aren't deleted
before another render attempt occurs, by which time the sources are
already freed, resulting in a crash.
This is supposed to assign -1 to the sampler_id to indicate that no
sampler need be assigned for the texture, but instead it was leaving the
variable with uninitialized data, resulting in a crash when used.
From MSDN: "The behavior of the least significant bit of the return value
is retained strictly for compatibility with 16-bit Windows applications
(which are non-preemptive) and should not be relied upon."
This caused problems with hotkeys firing if the user pressed a hotkey key
in another application, followed by the modifier keys at any other time.
OBS would then think the hotkey key was just pressed based on the was_down
behavior and incorrectly trigger a hotkey event.
Fixes 0000443.
There's no need to duplicate the packet as the reference count will be 1
after the av_read_frame call. Duplicating causes heap corruption when a
synthetic clock packet is duplicated and assigned the buffer from the
stack-based temporary packet which is then double-freed by the decoder
thread.
To be able to use index buffers, they must also be bound to a vertex
array object along with the vertex buffers.
Ideally, if there are multiple index buffers for a vertex buffer,
separate VAOs should be created for each combination.
When using QSV is used on a windows 7 machine with a dedicated card, you
have to fake a monitor connection to your Intel graphics to be able to
use QSV. If you do not, the initialization will fail with an error.
The error for that situation is not handled properly, and a variable
will be used while null. Instead, the function should safely return
after that error is received.
Also, do not call ClearData in the destructor unless QSV has been
properly initialized (if m_pmfxENC is null).
The if statement erroneously ended with a ';', which means that the code
is always executed, but there's no reason to even have these if checks
in the first place as the functions themselves return safely with null
pointers.
If audio buffering is very high, the audio packets built up in the
interleaved buffer would be significantly before the first video packet,
causing the offset between the starting video/audio packet pairs to be
significantly off, leading to desync.
This issue was not spotted until recently because it only happens when
streaming/recording with same encoders while audio buffering is very
high.
When using a chain hook method (forward or reverse), it was unwisely
assumed that the previous hook in the chain would not overwrite new
hooks when it's called. When the game capture hook calls the previous
hook in the chain, certain other programs that hook (in this case,
rivatuner on-screen display) would overwrite the hook with older data
and erase the game capture hook, causing it to only capture the first
frame and then never capture again.
This patch ensures that the hook is always saved before calling the next
hook in the chain and then restored after the call returns. It also
preserves any new hooks that may be added on top of it at any point.
