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.
YouTube Gaming is live since today (26 August 2015) and people will ask
for it.
This makes it a bit clearer that YouTube and YouTube Gaming
(which share the same ingestion system) work with OBS MP.
This will use the services.json file present in the cache, or if it has
the wrong format version or is corrupted for whatever reason, uses the
local version instead.
Also a minor refactor, makes it so that you call the open_services_file
function to get the services array, rather than having to get the file
name each time.
I made the rather tough call of not showing all services by default; I
didn't want to have to do this, but too many services are asking to be
put in to the program, and any time I add a service in to the list, I
feel uncomfortable because I feel like I'm potentially advertising them,
and/or they're using our program to advertise as well. Some of these
services are particularly bad at policing illegal/copyrighted content,
host content that I personally find distasteful or incredibly stupid
(what the heck is up with these "vaping" streams?), or are just fairly
terrible websites in general that I just feel uncomfortable with showing
by default.
However, I do not really want to reject anyone either, I want to let
their users be able to use our program with relative ease, but more than
anything I just simple don't want to be seen as "endorsing" some of
these websites (more than others in particular). I know that a "show
all services" checkbox is probably pretty pointless/superfluous thing to
do, but I feel like it's at the very least a means of saying "hey, I
don't really endorse these guys," or "use at your own risk," or
"warning: this website is incredibly terrible."
Honestly, I couldn't really think of any better solution that would
a.) still list all services without outright censoring them, and
b.) prevent us from being seen as "endorsing" all services.
(Although maybe this whole thing feels a bit.. passive aggressive. I
feel like I'm tipping over someone's garden gnome in the middle of the
night while they're sleeping. Still, it's something.)
NOTE: This code is backward compatible; i.e., if you previously had a
service selected that's not common but don't have the "show all"
checkbox checked, it'll still show that service for convenience.
Services almost always recommend this be enabled, and I generally want
to make configuration easier for users; with CBR they don't have to set
things like the CRF value.
Livecoding.tv (coding), gaminglive.tv (gaming), and beam.pro
(gaming/music)
I really don't see any problems with adding these particular services to
the local list while the actual remote ingest lookup code has yet to be
even started yet (as of this writing). They seem to be harmless
services that are dedicated to specific types of content (stated above).
API changed from:
------------------------
EXPORT void obs_service_apply_encoder_settings(obs_service_t *service,
obs_encoder_t *video_encoder,
obs_encoder_t *audio_encoder);
void obs_service_info::apply_encoder_settings(void *data
obs_encoder_t *video_encoder,
obs_encoder_t *audio_encoder);
To:
------------------------
EXPORT void obs_service_apply_encoder_settings(obs_service_t *service,
obs_data_t *video_encoder_settings,
obs_data_t *audio_encoder_settings);
void obs_service_info::apply_encoder_settings(void *data
obs_data_t *video_encoder_settings,
obs_data_t *audio_encoder_settings);
These changes make it so that instead of an encoder potentially being
updated more than once with different settings, that these functions
will be called for the specific settings being used, and the settings
will be updated according to what's required by the service.
This fixes that design flaw and ensures that there's no case where
obs_encoder_update is called where the settings might not have
service-specific settings applied.
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.
jp9000
Radzaquiel
Gol-D-Ace
Haden F
Taylor Blau
dodgepong
Jess Mayo
CommanderRoot
Night