RTMP was not being recognized due to a case-sensitive comparison; this
changes to a case insensitive comparison to fix the issue.
Fixes a bug found in beta channel.
Signed-off-by: pkv <pkv@obsproject.com>
This enables audio multi-track support in UI for mpegts streams (srt,
rist ...).
The UI changes were coded though to allow re-use by other protocols.
Signed-off-by: pkv <pkv@obsproject.com>
A bug which was technically introduced in df446c3f6e: the author
assigned video mixes to the virtual camera and did not realize you have
to wait for full capture stop with the "deactivate" signal rather than
the "stop" signal. This situation is understandable because these
signals are likely confusing and need more documentation.
The way an output works when it stops is it has three stages:
- "stopping", which is the moment the user themselves stop the output
- "stop", when the output's implementation has stopped and returns
success or an error code
- "deactivate", when the output inself (not the implementation) has
fully stopped capturing encoded or raw frame data after the
implementation has stopped. This is done in a separate thread,
end_data_capture_thread(), for performance and data race reasons, and
is when it's "actually fully stopped for real this time"
(Lain note: I sincerely apologize for this confusing signal design)
The author of df446c3f6e was likely confused as to why they could not
destroy the video mix in the "stop" signal without triggering a race
condition in end_data_capture_thread(), and instead decided to make a
workaround to clear the video mix set to the output before destroying
the video mix. Unsetting the video mix I'm guessing *seemed* to fix the
problem for them at the time, and destroying the video mix separately
after that automatically stops capture, so it *technically* worked
because the deactivate thread cannot be called until the
implementation's stop signal has executed. However, it was still the
incorrect way to handle the problem, because it circumvents the output's
mechanism for deactivating the frame data capture by destroying the view
instead.
The reason this was the incorrect way to handle the problem became
exposed in 7cd7ca80f8, when tytan made it so it uses the main video mix
under certain circumstances. The main view is special and cannot be
destroyed, so the mechanism to stop frame data capture that the
virtualcam was using before failed, and raw frame data capture continued
perpetually until the end of the program erroneously.
This fix solves the bug by using the "deactivate" signal rather than the
"stop" signal, thus allowing the output to fully end its data capture
and *then* destroy the video mix.
Fixesobsproject/obs-studio#9153
This change allows the virtual camera to really output what is in the
program view, some plugin interract with this view but their changes
does not appear on the virtual camera.
Commit f1223ca566
(UI: Set fragmented MP4/MOV as default for beta/rc)
changed RecFormat to RecFormat2.
This conflicts with the use of RecFormat introduced in
d18b38e784
(UI: Enable multiple audio tracks in Simple Output recording).
This fixes the issue.
An unused var is also removed.
Signed-off-by: pkv <pkv@obsproject.com>
This adds support for multiple audio tracks in Simple Output for
recordings.
This is enabled for all quality presets (including "Lossless") except
"Same as Stream".
This is also enabled for the Replay Buffer.
An exception is made for flv recording format since it only allows a
single audio track.
The recorded track (and streaming track) is then Track 1 as before.
Signed-off-by: pkv <pkv@obsproject.com>
"New Socket Loop" and "Low Latency Mode" RTMP options are only available
on Windows.
Those options should be ignored and forced-disabled on non-Windows
builds.
Previously, an output that does not implement `info.get_output_type`
would result in these log messages saying `(null)`. This uses the actual
ID directly from the output itself instead.
Also removes two extra calls to `obs_encoder_set_video()` as they are
redundant and unnecessary.
