Fixes mantis issue https://obsproject.com/mantis/view.php?id=1379
For some devices with hdmi input, the Front Center channel and the LFE
channel are swapped. For some others they are not.
To solve the issue a new swap setting is added so that the user can
swap the two channels if needed.
Decklink cards accept 2, 8 or 16 audio channels.
If obs audio output is setup to n channels ( 8 >= n > 2), and the
decklink card captures n channels, one needs to squash the silent
channels (n+1, .., 8) or sampling issues occur.
This had been done on windows but is required also on macOs and linux.
The commit adds the fix for macOS and linux.
Some code factoring has also been done.
Closesobsproject/obs-studio#1350
The list of channel layouts available for decklink input is missing 2.1
& 4.1 layouts. The commit adds them. This aligns the decklink input
with the speaker layouts available at outputs. Having different layouts
as input and output invokes FFmpeg resampler, which remixes the channels
in non trivial way except when downmixing to stereo. This patch allows
to avoid such uncontrolled remix of channels with decklink input.
(also obs, deps/media-playback, libobs/audio-monitoring, decklink,
linux-alsa, linux-pulseaudio, mac-capture, obs-ffmpeg, win-dshow,
win-wasapi)
Default channel layout for 4 channels is 4.0 in FFmpeg.
Replacing quad with 4.0 will improve compatibility since FFmpeg has
better support of its default channel layouts.
(also modifies obs-ffmpeg, audio-monitoring, win-wasapi, decklink,
obs-outputs)
Removes speaker layouts which are not exposed in UI. The speaker
layouts selectable by users in the UI are the most common ones. It is
not necessary to keep other layouts. (This basically removes
5POINT1_SURROUND, 7POINT1_SURROUND, SURROUND =3.0).
(This commit also modifies the following modules: UI,
deps/media-playback, coreaudio-encoder, decklink, linux-alsa,
linux-pulseaudio, mac-capture, obs-ffmpeg, obs-filters, obs-libfdk,
obs-outputs, win-dshow, and win-wasapi)
Adds surround sound audio support to the core, core plugins, and user
interface.
Compatible streaming services: Twitch, FB 360 live
Compatible protocols: rtmp / mpeg-ts tcp udp
Compatible file formats: mkv mp4 ts (others untested)
Compatible codecs: ffmpeg aac, fdk_aac, CoreAudio aac,
opus, vorbis, pcm (others untested).
Tested streaming servers: wowza, nginx
HLS, mpeg-dash : surround passthrough
Html5 players tested with live surround:
videojs, mediaelement, viblast (hls+dash), hls.js
Decklink: on win32, swap channels order for 5.1 7.1
(due to different channel mapping on wav, mpeg, ffmpeg)
Audio filters: surround working.
Monitoring: surround working (win macOs linux (pulse-audio)).
VST: stereo plugins keep in general only the first two channels.
surround plugins should work (e.g. mcfx does).
OS: win, macOs, linux (alsa, pulse-audio).
Misc: larger audio bitrates unlocked to accommodate more channels
NB: mf-aac only supports mono and stereo + 5.1 on win 10
(not implemented due to lack of usefulness)
Closesjp9000/obs-studio#968
Use unbuffered async mode by default, and when in unbuffered mode,
decouple audio/video so that audio plays as soon as it's received.
This is a workaround for decklink device drivers having unreliable
video/audio timestamps (audio/video sync drifting over time). From
testing, it seems that the handling of video and audio is completely
separate in the driver; along with the timestamp calculations. For
example, when the thread of the decklink audio callback is stalled, it
would cause the timestamps of the audio alone to go out of sync, which
indicates timestamps are calculated more or less on the spot independent
of what video is doing (which is how we replicated the issue fixed by
b63e4b055e). Because decklink drivers treats the audio and video as
essentially decoupled, we must also treat it as decoupled. This is what
was causing video/audio to drift out of sync over time.
This replaces the name-based detection of the 4K intensity pro, and
allows other devices to be able to use the BGRA pixel format, if the
user so chooses.
cleaning up my previous commit a bit. we can just keep the
appropriate BMDPixelFormat as a data member and keep StartCapture() a
bit clearer.
this might also be helpful if (when?) the detection code needs to be
more robust or configurable
detect the device type when initializing the device instance and
determine whether to capture YUV or RGB. tested with a Blackmagic
Intensity Pro and a Blackmagic Intensity Pro 4K in the same machine,
capturing at the same time, on Linux
This is my fault; I made an idiotic assumption about the data and it
ended up causing the plugin to crash. This is definitely one of my more
embarrassing moments.
System timestamps were being used instead of timestamps from the
audio/video input. This would cause potential desync as well as
incremental buffering when using devices with the blackmagic video
source. Using the timestamps direct from the SDK itself fixes those
issues, and causes audio/video to play back properly and in sync.
Colin Edwards
pkv
Jim
mntone
Brian S. Stephan
Skyler Lipthay