Microphones and other input devices can often have bad or erroneous
timestamps. Although we handle bad timestamps much better in
obs-studio, there are still lingering issues that can crop up from time
to time with device QPC timestamps that leads to mic data not playing
back properly. It's best if it be off by default rather than on, which
will now cause it to use system timestamps for input devices by default.
This changes it to the same handling as OBS1 for this case.
RemoveScene would always remove the currently selected item from the
scenes list, even if that item didn't reference the actual scene being
removed; finding the proper item via its OBSRef fixes this issue.
How to reproduce the original issue:
Create two scenes "a" and "b", set a hotkey for switching to scene "a",
select scene "b" and press the remove scene button, then while the
confirmation dialog is up press the hotkey while the UI is out of focus.
The active scene should have switched to "a", while the dialog still
displays "b" as its target; now confirm the removal of "b". Note how "a"
was removed from the scenes list instead.
Reported at https://obsproject.com/mantis/view.php?id=333
This reverts commit 35b2ce565a.
There is far too much potential for issues to occur if the first-time
start creates a display capture by default on linux and windows.
Display capture on windows laptops will not be guaranteed to capture
properly, leaving the user with a blank screen. Display capture on
linux downloads its image off the graphics processor, so it's quite
inefficient to have on by default.
The new 'offset' value was not being passed back to the caller, which
caused the caller to continue to use the old value and thus would cause
an invalid hook and crash.
The call to CoInitializeEx in the win-mf module caused some sort of
conflict with the decklink module, causing the decklink module to crash
on exit. Instead, let libobs handle COM initialization.
If the GL capture part of the game capture hook fails to initialized for
whatever reason, it will go in to an infinite reacquire loop. If it
fails to initialize shared texture capture, try shared memory capture
instead.
When an encoder has been removed (such as CoreAudio) and the audio
bitrates currently configured no longer are available to the current
audio encoders anymore, it would cause GetAACEncoderForBitrate to return
false with no encoder available.
To fix the issue, instead just choose the closest bitrate relative to
the current bitrate (rounded up).
Using gzdopen will not work properly if the C standard library used to
get the descriptor is not the same library as the one that was compiled
with zlib. When this is the case, it causes zlib to fail to write a
file, and would report a C standard library error. Use gzopen and
gzopen_w instead to ensure that the file is opened and closed by zlib
itself, ensuring that zlib and the libobs do not have to share the C
standard library between each other.
After some more testing, utvideo not only gives better encoding
performance, but also better compression and better decoding
performance. It's pretty much superior all around over huffyuv.
So certain high-profile individuals were complaining that it was
difficult to configure recording settings for quality in OBS. So, I
decided to add a very easy-to-use auto-configuration for high quality
encoding -- including lossless encoding. This feature will
automatically configure ideal recording settings based upon a specified
quality level.
Recording quality presets added to simple output:
- Same as stream: Copies the encoded streaming data with no extra usage
hit.
- High quality: uses a higher CRF value (starting at 23) if using x264.
- Indistinguishable quality: uses a low CRF value (starting at 16) if
using x264.
- Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a
user tries to select lossless, they will be warned both via a dialog
prompt and a warning message in the settings window to ensure they
understand that it requires tremendous amounts of free space. It will
always use the AVI file format.
Extra Notes:
- When High/Indistinguishable quality is set, it will allow you to
select the recording encoder. Currently, it just allows you to select
x264 (at either veryfast or ultrafast). Later on, it'll be useful to
be able to set up pre-configured presets for hardware encoders once
more are implemented and tested.
- I decided to allow the use of x264 at both veryfast or ultrafast
presets. The reasoning is two-fold:
1.) ultrafast is perfectly viable even for near indistinguishable
quality as long as it has the appropriate CRF value. It's nice if you
want to record but would like to or need to reduce the impact of
encoding on the CPU. It will automatically compensate for the preset at
the cost of larger file size.
2.) It was suggested to just always use ultrafast, but ultrafast
requires 2-4x as much disk space for the same CRF (most likely due to
x264 compensating for the preset). Providing veryfast is important if
you really want to reduce file size and/or reduce blocking at lower
quality levels.
- When a recording preset is used, a secondary audio encoder is also
spawned at 192 bitrate to ensure high quality audio. I chose 192
because that's the limit of the media foundation aac encoder on
windows, which I want to make sure is used if available due to its
high performance.
- The CRF calculation is based upon resolution, quality, and whether
it's set to ultrafast. First, quality sets the base CRF, 23 for
"good" quality, 16 for "very high" quality. If set to ultrafast,
it'll subtract 2 points from the CRF value to help compensate. Lower
resolutions will also lower the CRF value to help improve higher
details with a smaller pixel ratio.
For game capture, if a game is running at for example 800 FPS and limit
capture framerate is off, it would try to capture all 800 of those
frames, dramatically reducing performance more than what would ever be
necessary.
When limit capture framerate is off, instead of capturing all frames,
capture frames at an interval of twice the OBS FPS, identical to how
OBS1 works by default. This should greatly increase performance under
that circumstance.
This also adds the ability to detect whether it stopped due to lack of
space or not -- particularly useful for the FFmpeg output due to
lossless file format support.
For the FFmpeg output, the encoder ids are sort of superfluous. They
really should be optional. If they're not set, it should use the
encoder name string instead to determine the ids automatically.
It seems that certain encoders (quicksync) do not have proper back-end
support in the windows media foundation libraries for certain CPUs.
Quicksync doesn't appear to support CPUs that are not haswell (4xxx) or
above. It's really annoying, but there's not much we can do about it
until we implement our own custom quicksync implementation.
This check simply makes it attempt to spawn an encoder to check to see
whether the encoder can actually be created before registering an
encoder.
The previous commit (672378d20) was supposed to fix issues with the
encoder releasing while data was still being processed, but did not
account for when the encoder has never started up. That was my fault.
Furthermore, the way in which it was waiting to drain events was
incorrect. The encoder may still be active even though there aren't any
events queued. The proper way to wait for an async encoder to finish up
is to process output samples until it requests more input samples.
After I made it so that the encoder internal data gets destroyed when
all outputs stop using it (fa7286f8), the media foundation h264 encoder
started having crashes on shutdown. After a lot of testing, I realized
that the reason it started happening is almost assuredly because active
encoding events had not yet been completed.
After making it wait on those events by calling DrainEvents(true), the
crashes stopped. So asynchronous actions were clearly still occurring
and it was shutting down while data was still being processed, thus
leading to a crash.
Adds a VideoToolbox based H264 encoder for OSX, which most notably
allows the use of hardware encoding (Quicksync).
NOTES:
- Hardware encoding is handled by Apple itself internally. The plugin
itself has little control over many details due to the way that Apple
designed the VideoToolbox interface. Generally however, quicksync is
used if available on the CPU, and quicksync is almost always available
due to the fact that macs are exclusively Intel.
- The VideoToolbox does not seem to implement CBR, so it won't be
available. These encoders are generally not recommended for
streaming.
Implements hardware encoders through the Media Foundation interface
provided by Microsoft.
Supports:
- Quicksync (Intel)
- VCE (AMD)
- NVENC (NVIDIA, might only be supported through MF on Windows 10)
Notes:
- NVENC and VCE do not appear to have proper CBR implementations. This
isn't a fault of our code, but the Media Foundation libraries.
Quicksync however appears to be fine.
API changed from:
obs_source_info::get_name(void)
obs_output_info::get_name(void)
obs_encoder_info::get_name(void)
obs_service_info::get_name(void)
API changed to:
obs_source_info::get_name(void *type_data)
obs_output_info::get_name(void *type_data)
obs_encoder_info::get_name(void *type_data)
obs_service_info::get_name(void *type_data)
This allows the type data to be used when getting the name of the
object (useful for plugin wrappers primarily).
NOTE: Though a parameter was added, this is backward-compatible with
older plugins due to calling convention. The new parameter will simply
be ignored by older plugins, and the stack (if used) will be cleaned up
by the caller.
This is useful for allowing the ability to have private data associated
with the object type definition structures. This private data can be
useful for things like plugin wrappers for other languages, or providing
dynamically generated object types.
Selecting any supported FFmpeg format where ff_format_desc_extensions
returns NULL would crash the std::string constructor, so we pass an
empty extension instead (rtsp is one candidate format that triggers
the crash, on my machine at least)
