Instead of logging the relative encoded count (which is susceptible to
integer overflow), log the output frame count instead. If there's an
issue with encoding, it'll show up when all encoding stops regardless.
This reverts commit 4e3e67bb8cf6cb508b4d30b85451c0c4f20b7539.
The way this is handled will erroneously report 0 frames encoded when
frames have actually been properly encoded, which is best avoided.
Additionally, and overflow would be generated for drawn frames where
none occurred before. The encoded value should probably not even be
present in the log for the output due to the way it's handled.
Some plugins are using the OBS_VERSION macro obs-config.h to specify the
current version, which will bake the string in to the plugin, making it
so that if the plugin is not replaced for a patch, it could potentially
have the incorrect version. This makes it so that a plugin/frontend can
get the current version string that's baked in to libobs itself.
When item in the old scene had only Scale Filter, texture renderer
was not created for an item in the new scene. However if the item also
had Crop set, the texture renderer was created.
Now after copying the data, texture renderer is created for the item in
the new scene when needed.
Closesjp9000/obs-studio#969
Scene items would incorrectly have pre-multiplied alpha when they were
scaled with different scale filtering, when they were cropped, or when
the item itself was a scene. This happens because the scene renders the
items to a texture in those cases, and when they are rendered to a
texture the blend function would be the default srcalpha/invsrcalpha
blend function, which would cause alpha to become pre-multiplied in the
texture's result rather than straight alpha.
This changes the behavior to directly copy the color/alpha to the
texture using the one/zero blend function instead, which makes the
resulting texture straight alpha. (Note that you do not want to turn
off the blend mode for the same result because certain sources can have
custom drawing that may rely on blending being available)
Related Issue: https://obsproject.com/mantis/view.php?id=954Closesjp9000/obs-studio#966
This allows the ability for certain types of modules (particularly
scripting-related modules) to initialize extra data when all other
modules have loaded. Because front-ends may wish to have custom
handling for loading modules, the front-end must manually call
obs_post_load_modules after it has completed loading all plug-in
modules.
Closesjp9000/obs-studio#965
For specific types of transitions (stingers in this case), there is no
blending done of the two targets, so wasting GPU resources rendering
them to textures is unnecessary.
Allows the ability to change the output type in case one service
requires a different output type.
NOTE: This should be considered a temporarily yet simple solution to a
specific problem: support for RTMP-like outputs. This will allows
seamless integration of supporting different RTMP-like output types
within the same service. This should probably be replaced with a more
ideal solution later, such as implementing a completely different
service type instead, when time permits.
If size is 0 after popping data from the front or back, set the
start/end points to 0 as well to ensure that any subsequent buffer
pushes start from the beginning of the buffer rather than the middle of
the buffer. Reduces potential unnecessary operations in that case.
Additionally, this fixes a bug with circulebuf_pop_back where if start
position was 0, and all the data was popped off the buffer (equal to the
capacity), the end position would be equal to the original size. As an
example to replicate the bug, push 5, pop 5, then push 10. The
start/end points will be invalid.
Closesjp9000/obs-studio#954
If a source is created with settings, default values would not be set on
data items that already had values set. The check here was supposed to
be a not equal rather than an equal because you're not supposed to be
able to set a default value of one type on an item that already exists
but is of a different type.
This bug would make it so that if a particular setting was removed,
there would be no default value to fall back on, and it would always be
0 or NULL for all values.
It's likely this bug wasn't encountered until now because before now
there had been no reason to clear or remove settings on most things.
I believe the issue with the next to impossible frame count to be an integer underflow, as in order to achieve those you'd have to have recorded for at least 345 days with 144 fps. So this commit fixes them by using a normal integer first and then deciding on the result if it should be used or be replaced with a 0.
When an output fails to connect and it's already been prematurely
stopped, the event to mark the output as stopped would not be signaled,
causing obs_output_destroy to lock up indefinitely while waiting for the
event to be signaled.
Rather than have the back-end try to determine whether the output can or
cannot stop, allow the stop callback to continue in the plugin either
way and let the plugin itself make that determination.
This fixes a bug where the back-end wouldn't have data active while
connecting, therefore the stop callback wouldn't be called, and once
connected it wouldn't know that it was supposed to stop. In other words
trying to call obs_output_stop on an output that was in a state of
connecting would do nothing and the output would never stop.
Fixes a potential issue where copying filters from one source to another
might add filters from the old source that are not compatible with the
new source.
(This commit also modifies the decklink, linux-v4l2, mac-avcapture,
obs-ffmpeg, and win-dshow modules)
Originally, async buffering for sources was supposed to be a
user-controllable flag. However, that turned out to be less than ideal
because sources (such as the win-dshow plugin) were programmed with
automatic control over their buffering (such as automatically detecting
USB 2.0 capture devices and then enabling in those cases).
The fact that it was a flag caused a design flaw to where buffering
values would be overwritten when a source is loaded from save data.
Because of that, this flag is being deprecated and replaced with a
specific function to enable unbuffered mode instead.
This reverts commit d85224bb9b01173b4ceed866482c435681f3f9b1.
Would cause other flags to stop saving. Buffering needs to be split off
from the source flags.
Make sure the target file exists before attempting to create a backup.
This will allow for the function to work correctly if the target does
not yet exist.
Prevents lagged frames (frames that took too long to render) to be
counted as skipped frames (frames that are skipped due to encoding
taking too long to process)
Originally, obs_get_video_info would recreate the obs_video_info
structure that was originally passed to it from obs_reset_video. This
changes that to just store a copy of the obs_video_info when calling
obs_reset_video, and then copying that to the parameter of
obs_get_video_info when called.
When frames are skipped the skipped frame count would increment, but the
total frame count would not increment, causing the percentage
calculation to fail.
Additionally, the skipped frames log reporting has been moved to
media-io/video-io.c instead of each output.
libobs' shader language is basically HLSL, and tex.Load uses an int3 for
2D textures, with texture mipmap index for the last component. This bug
bypassed testing because the front-end automatically switches to OpenGL
if D3D11 initialization fails, and when converted to GLSL, works fine
because texelFetch only requires two components. This also means
there's a bug in GLSL shader conversion code, because it's essentially
ignoring the third component when it shouldn't be.
Eventually, most things should be replaced with Load where applicable
(though in some cases sub-pixel sampling is desired).
This commit also fixes a bug where NV12 async sources wouldn't render
correctly.
