Decoupling the audio from the video causes the audio to be played right
when it's received rather than attempt to sync up to the video frames.
This is useful with certain async sources/devices when the audio/video
timestamps are not reliable.
Naturally because it plays audio right when it's received, this should
only be used when the async source is operating in unbuffered mode,
otherwise the video frame timing will be out of sync by the amount of
buffering the video currently has.
Follow-up to 47aa56b (PR #620). Windows 10 revision detection broke in
Build 15036 (Creators Update) after Revision 296. This aims to further
fix revision detection on Windows 10.
The cmake script code used to find and depend on pulseaudio for audio
monitoring on linux was unintentionally being triggered on mac. This
patch makes it so that the pulseaudio cmake code is ignored on mac.
This function had a number of bugs and just wasn't working properly at
all. This function is currently not used in public builds because GPU
is used for color conversion instead (hence why it had probably not
really been tested), but a need came up where CPU conversion was useful
for the sake of testing something else in the back-end, and it needed to
be fixed before CPU conversion could be used.
When an async video frame comes in and it sets the timing_adjust value
(used to sync audio to video based upon their timestamps), it would use
os_gettime_ns as a base. Instead, it should use OBS' current video
frame time so that the audio and video playback is as accurate as
possible relative to the actual exact timestamp of the video frame.
(Results are almost insignificant, but it's nice to be as precise as
possible)
During packet interleaving (for outputs), ensure that if two packets
coincide with the same timestamp, that the video packet always comes
first instead of the audio packet.
This fix is required to make FLV demux properly with certain demuxers;
some FLV demuxers expect the video packet before the audio packet when
two packets coincide with the same timestamps.
(This commit also modifies the obs-outputs module)
The first video packet video offset (the value used to set the starting
point of video data) would be set to the DTS value of the first video
packet. However, when b-frames are used, the first DTS value will be
negative. This was originally done because FLV muxing requires that the
first packet's DTS start from 0. Unfortunately, this would also
effectively cause the first packet's PTS/DTS value to be shifted forward
by the negative amount, which would cause video sync to be off by a
video frame or two.
This fixes it to start at the PTS value instead and preserve any
negative offsets. Additionally, the FLV muxing code has been fixed to
ensure that it adjusts the starting video DTS to 0, and now correctly
adjusts the first audio packet's timestamp according to that DTS as well
(which it didn't do before).
On audio encoder startup, audio encoders paired with a video encoder
would unintentionally discard a single audio data segment, causing it to
be 1024 audio frames out of sync.
Certain PSAPI functions moved to KERNEL32 after Vista, setting
PSAPI_VERSION 1 uses the old PSAPI exports for compatibility. Vista
support was unintentionally broken by a6318ff.
With certain combinations of CMake (<3.9) and ImageMagick (>=7),
configure will silently fail setting up support for ImageMagick,
even if the user requested for it, and the build will move on
(as long as FFMPEG_AVCODEC is found). This commit adds a check
that will stop configure in such cases.
Closesjp9000/obs-studio#1018
For those resolutions the last two chroma samples of every other
line would be overwritten by the last chroma samples of the previous
line (depending on sampler used), producing artifacts on the left
edge of the resulting image (e.g. any color present on the right
edge of the image would "bleed" to every other line on
the left edge)
Fixes https://obsproject.com/mantis/view.php?id=508
The toggle_visibility set only by init_hotkeys() call, but used each
time in obs_sceneitem_destroy() call. Because zero hotkey_pair_id is
valid - we need to set item property other than zero here.
Closesjp9000/obs-studio#1000
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 4e3e67bb8c.
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.
