Apparently someone dumb (aka me) neglected to properly handle the inline
graphics hook API functions. You're not supposed to 'extern' inline
functions, they need to be defined for each file when ever they're used.
Apparently neglected to use the reference operator. I think this may
partially be one of the reasons why many developers still choose to use
pointers instead of references, but fortunately an actual GOOD compiler
warns about this (aka anything but vc)
Clears up a warning (to prevent && and || confusion), and clarifies what
specifically the if statement is trying to accomplish (check to see if
the capture is valid)
On windows, for whatever reason sockets use the SOCKET type which is not
a signed integer. Still, even though it's not a signed integer, -1 is
used to indicate an invalid socket, but the way you use it is via
microsoft's fabulously dumb little INVALID_SOCKET define, so we have to
make librtmp use that instead.
The HWND type is a void pointer, but HWND values are global and always
32bit despite, so casting to 32bit can cause cast warnings on actual
good compilers like gcc via mingw. This change correctly handles the
casting to 32bits without producing unwanted warnings or errors on
mingw.
win-capture should not postfix .lib to psapi.
The graphics hook also requires psapi when linking.
Also change some link libs as mingw-w64 libraries are not postfixed
.lib.
Hopefully we can get this function merged for mingw-w64 4.1. As for the
4.0 release, adding a new header is a big change, it'll have to wait for
the next version.
Remove the .lib postfix from strmiids
ksuser provides KSCATEGORY_ENCODER and similar GUIDS used
wmcodecdspuuid provides MEDIASUBTYPE_H264 MEDIASUBTYPE_RAW_AAC1 and
MEDIASUBTYPE_I420 so no need to define them in dshow-formats. The
submodule will have to be updated to support this change.
I feel like due to lack of user understanding, it's important to specify
that the higher the preset is (veryfast/superfast/ultrafast) the less
CPU that the encoder will use
Add CBR, CRF to properties so that it can be changed by the user. If
CBR is on, CRF will be disabled. Also added a 'Use Custom Buffer Size'
option to make it so that the buffer size will automatically be set to
the bitrate if its value is false. This is primarily a convenience
feature for users.
Certain RTMP services will support multi audio tracks via RTMP. This
updates librtmp with custom code that enables multiple streams per
connection to be used; each subsequent stream typically containing extra
audio tracks. The audio encoder names are used to indicate the names of
tracks, and the name of the tracks are used for the stream keys for
those subsequent tracks.
This makes FFmpeg usable as an output, and removes or changes most of
the code that was originally intended for testing purposes.
Changes the settings for the FFmpeg output to the following:
* url: Sets the output URL or file path
* video_bitrate: Sets the video bitrate
* audio_bitrate: Sets the audio bitrate
* video_encoder: Sets the video encoder (by name, blank for default)
* audio_encoder: Sets the audio encoder (by name, blank for default)
* video_settings: Sets custom video encoder FFmpeg settings
* audio_settings: Sets custom audio encoder FFmpeg settings
* scale_width: Image scale width (0 if none)
* scale_height: Image scale height (0 if none)
The reason why scale_width and scale_height are provided is because it
may internally convert formats, and it may be a bit more optimal to use
that scaler instead of the pre-output scaler just in case it already has
to convert formats internally anyway (though you can do it either way
you wish).
Video format handling has also changed; it will now attempt to use the
closest format to the current format if available for a given video
codec.
API changed:
--------------------------
void obs_output_set_audio_encoder(
obs_output_t *output,
obs_encoder_t *encoder);
obs_encoder_t *obs_output_get_audio_encoder(
const obs_output_t *output);
obs_encoder_t *obs_audio_encoder_create(
const char *id,
const char *name,
obs_data_t *settings);
Changed to:
--------------------------
/* 'idx' specifies the track index of the output */
void obs_output_set_audio_encoder(
obs_output_t *output,
obs_encoder_t *encoder,
size_t idx);
/* 'idx' specifies the track index of the output */
obs_encoder_t *obs_output_get_audio_encoder(
const obs_output_t *output,
size_t idx);
/* 'mixer_idx' specifies the mixer index to capture audio from */
obs_encoder_t *obs_audio_encoder_create(
const char *id,
const char *name,
obs_data_t *settings,
size_t mixer_idx);
Overview
--------------------------
This feature allows multiple audio mixers to be used at a time. This
capability was able to be added with surprisingly very little extra
overhead. Audio will not be mixed unless it's assigned to a specific
mixer, and mixers will not mix unless they have an active mix
connection.
Mostly this will be useful for being able to separate out specific audio
for recording versus streaming, but will also be useful for certain
streaming services that support multiple audio streams via RTMP.
I didn't want to use a variable amount of mixers due to the desire to
reduce heap allocations, so currently I set the limit to 4 simultaneous
mixers; this number can be increased later if needed, but honestly I
feel like it's just the right number to use.
Sources:
Sources can now specify which audio mixers their audio is mixed to; this
can be a single mixer or multiple mixers at a time. The
obs_source_set_audio_mixers function sets the audio mixer which an audio
source applies to. For example, 0xF would mean that the source applies
to all four mixers.
Audio Encoders:
Audio encoders now must specify which specific audio mixer they use when
they encode audio data.
Outputs:
Outputs that use encoders can now support multiple audio tracks at once
if they have the OBS_OUTPUT_MULTI_TRACK capability flag set. This is
mostly only useful for certain types of RTMP transmissions, though may
be useful for file formats that support multiple audio tracks as well
later on.
Add a check to the cursor render function to ensure the cursor texture
exists. It seems like it is very unlikely but still possible, that the
first tick which should set the texture might fail. In that case obs
would crash in the render function.
Previously a DirectShow hardware encoder would get 'stuck' and couldn't
be recreated due to a strange issue with the graph filter not properly
shutting down the encoder. This would make it so that the user could
only use the encoder once, and then it wouldn't work anymore any time it
was initialized again. dshowcapture version 0.4.2 ensures that the
encoder can restart properly by manually shutting down the filter graph.
jp9000
martell
Radzaquiel
Gol-D-Ace
Bernd Buschinski
Akagi201
fryshorts