Since 65eb3c0815 we tried to get as close
a sync between audio and video tracks as we could before starting to
send frames to the output.
But in be717dbb2c when multi-track audio
was considered for synchronization it continued to try and line ALL
audio packets up with one video packet. While audio and video packets
are similar size this will work out. But once video packets duration is
smaller than 1/2 audio packet duration this may fail forever. In
practice with AAC's 20-23ms frame duration we can often get tracks
producing frames 5-10ms out of phase. For 60fps video this mostly fine
as 16ms frame duration will cover the gap, but for framerates as low as
100 its possible to fail to synchronize. In practice this is ~50%
for 6 audio tracks and 120fps video on my system, or 100% at 240fps.
The Pulseaudio implementation of audio monitoring was actually listing audio sources.
This change corrects that, so all possible outputs are available.
When creating a group, a newly allocated group `sub_scene` is released
just after calling `obs_scene_add_internal`.
If another thread released the scene-item, which is the sub_scene,
use-after-free might happen.
If the recording path is left empty in Settings, a leak can occur in
window-basic-stats.cpp because a bmalloc is called for a size 1.
This fixes the leak by checking against the path in the
os_get_free_disk_space function.
Signed-off-by: pkv <pkv@obsproject.com>
It was possible to set the encoder to scale the video to the same size
as the output, resulting in unnecessary passes through swscale and
skipping hardware encoders. This was a common user error in Advanced
Output mode where they would tick the rescale box but leave it at the
same resolution as their main output.
By adding the range data we can get successful handling of full range
color via custom FFmpeg output. Previously it would always default to 0
which would yield partial/limited output. Without the colorspace info
the output file is correctly tagged, but not undergone the actual
conversion.
As clang and gcc use "default" visibility (as in "not hidden") when
no visibility is specified, all functions are implicitly exported.
When changing default visibility to "hidden", the corresponding symbols
are not exposed anymore and linking fails. This PR updates all
functions signatures that were added in recent commits but not set to
be EXPORTed.
Also makes required OpenGL imports for texture sharing on macOS
mandatory.
When the `pos` variable is non-zero, audio does not get mixed correctly.
This is due to the fact that the `pos` variable was erroneously being
applied to the input rather than the output.
This makes multiple changes to resolve issues with monitoring. We have
added a number of things over time to resolve various issues due to our
misunderstanding of the pulse api and the explicitly wrong pulse api
documentation.
First is removing the prior stream write tracking. Write tracking
was incorrect as pulse sends you the total number of bytes it wants
written at that time and not a incremental, but also this write tracking
is unhelpful since we can just let begin_write signal when we should
stop writing.
Second removing underflow tracking, this sort of worked to detect high
latency sources like vlc which buffer ~1s of data before writing audio
data. It worked because it would grow the buffer in PA until we could
write enough data into it, but it didn't allow us to leverage that
larger buffer because we never paused the PA stream.
To solve the buffering/high latency issue instead start the PA stream
corked and only uncork it once we have enough data to reach the targeted
latency. We also check how much data we recieve from the source and if
it appears to be high latency providing us with much more data than our
target latency we increase the latency to match the source. Fixing the
VLC source issue and resulting in a smooth start to audio instead of
underruns while we play and increase latency.
Finally add some handling for pulses incorrectly documented API. Notably
that begin_write may request more or less data from you so handle both
cases. And stop attempting to use attr.maxlength which is not updated
after set_buffer_attr calls and was always -1, and tlength is just more
appropriate.
old mantis resulting in some changes, still fixed. https://obsproject.com/mantis/view.php?id=1076fixes#7574
New video formats introduced for ProRes 4444 encoding have not been
implemented in function calls used for video decoding, which makes the
switch statements non-exhaustive.
This does not functionally change the status quo (decoding ProRes 4444
files could still be broken because libobs does not explicitly handle
the colour format).
tytan652