The windows media foundation H264 encoders have been deprecated for over
a year, and microsoft's media foundation AAC encoder has had a continued
issue with occasional random audio glitches. The FFmpeg AAC encoder has
had recent development, and is more than sufficient to be able to handle
the task of encoding in terms of both quality and performance, so it's
better just to use the FFmpeg encoder from here on out.
As this plugin is no longer needed, for the next year or two it'll still
be compiled and included, but as a blank plugin that does nothing. The
reason why it's still being included as a blank no-operation plugin is
to overwrite older versions of the plugin. That way if a user installs
a newer OBS version over an older one, it won't load up the older win-mf
plugin where the encoders still were enabled.
This also fixes some rarely reported media foundation crashes that can
happen on startup.
(Note: This commit also modifies coreaudio-encoder, win-capture, and
win-mf modules)
This reduces logging to the user's log file. Most of the things
specified are not useful for examining log files, and make reading log
files more painful.
The things that are useful to log should be up to the front-end to
implement. The core and core plugins should have minimal mandatory
logging.
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.
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.
Gol-D-Ace
jp9000
Colin Edwards
Matt Gajownik
Dmitry-Me
Kurt Kartaltepe
John Bradley
dodgepong