- 12 5月, 2015 2 次提交
- 07 5月, 2015 4 次提交
- 18 4月, 2015 1 次提交
-
-
由 jp9000 提交于
Allows the ability to hint at encoders what format should be used. This is particularly useful if libobs is currently operating in planar 4:4:4, but you want to force an encoder used for streaming to convert to NV12 to prevent streaming issues.
-
- 10 4月, 2015 4 次提交
-
-
由 jp9000 提交于
This effect preserves detail of images that are scaled below half size by using sampling 9 pixels.
-
由 jp9000 提交于
This function sets the background color for a display
-
由 jp9000 提交于
If you don't need to see what's displayed, then this is particularly useful for two reasons: 1. It reduces the number of draw/present calls 2. It can prevent issues with certain hardware setups where rendering on a monitor hooked up to a separate card can experience slowdowns
-
由 jp9000 提交于
Sometimes it can be useful to turn off rendering to the display in order to reduce the number of draw calls and present calls.
-
- 26 3月, 2015 9 次提交
-
-
由 jp9000 提交于
These are basically just capabilities of a source, that and too much text on one line.
-
由 jp9000 提交于
Gets the output flags by its source type.
-
由 jp9000 提交于
-
由 jp9000 提交于
-
由 jp9000 提交于
-
由 jp9000 提交于
obs_source_process_filter tried to do everything in a single function, but the problem is that effect parameters would not properly be accounted for due to the way it internally draws, therefore it was necessary to split the functions in to two, you first call obs_source_process_filter_begin, then you set your effect parameters, then you finally call obs_source_process_filter_end. This ensures that when the filter is drawn, that the effect parameters are set.
-
由 jp9000 提交于
This allows a filter to skip its step and move on to the next target in the chain without affecting performance.
-
由 jp9000 提交于
These functions are primarily for use with filters, filters need to be able to get the width/height of a target source without it necessarily getting the post-filtered dimensions.
-
由 jp9000 提交于
When a frame is processed by a filter, it comes directly from the source's video frame cache. However, if a filter is using or processing those frames for whatever reason, there would be no guarantee that the frames would persist during processing, and frames could eventually be deallocated unexpected, for example when the resolution or format changes. So the solution is to implement simple reference counting for the frames so that the frames will exist until they have been released by any source or filter that's using them.
-
- 23 3月, 2015 2 次提交
- 13 3月, 2015 1 次提交
-
-
由 jp9000 提交于
Core API functions changed: ----------------------------- EXPORT bool obs_reset_audio(struct audio_output_info *aoi); EXPORT bool obs_get_audio_info(struct audio_output_info *aoi); To: ----------------------------- EXPORT bool obs_reset_audio(const struct obs_audio_info *oai); EXPORT bool obs_get_audio_info(struct obs_audio_info *oai); Core structure added: ----------------------------- struct obs_audio_info { uint32_t samples_per_sec; enum speaker_layout speakers; uint64_t buffer_ms; }; Non-interleaved (planar) floating point output is standard with audio filtering, so to prevent audio filters from having to worry about different audio format implementations and for the sake consistency between user interfaces, make it so that audio is always set to non-interleaved floating point output.
-
- 08 3月, 2015 1 次提交
-
-
由 jp9000 提交于
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.
-
- 07 3月, 2015 3 次提交
-
-
由 jp9000 提交于
-
由 jp9000 提交于
Enumerates filters that are currently present on a source.
-
由 jp9000 提交于
The obs_source_get_width and obs_source_get_height functions need to account for filters that may change their width/height such as a crop filter or something similar. As a side effect of this commit, because these functions need to lock the filter mutex, these functions can no longer be used with a const-qualified obs_source_t pointer.
-
- 05 3月, 2015 1 次提交
-
-
由 Socapex 提交于
Allows setting a specific position for scene items rather than just up/down/top/bottom
-
- 03 3月, 2015 1 次提交
-
-
由 jp9000 提交于
obs_source_inc_showing and obs_source_dec_showing are used to indicate that a source is showing or no longer being shown in a particular area of the program outside from the main render view. One could use an obs_view, but I felt like it was unnecessary because using an obs_view just to display a single source feels somewhat superfluous.
-
- 11 2月, 2015 1 次提交
-
-
由 jp9000 提交于
Instead of having services automatically apply encoder settings on initialization (whether the output wants to or not), instead make it something that must be explicitly called by the developer. There are cases where the developer may not wish to apply the service-specific settings, or may wish to override them for whatever reason.
-
- 08 2月, 2015 1 次提交
-
-
由 jp9000 提交于
Before: After: obs_service_gettype obs_service_get_type It seems there was an API function that was missed when we were doing our big API consistency update. Unsquishes obs_service_gettype to obs_service_get_type.
-
- 05 2月, 2015 5 次提交
-
-
由 jp9000 提交于
'obs_encoder_get_type' to get the type of an existing encoder, and 'obs_get_encoder_type' to get the type via its identifier
-
由 jp9000 提交于
This allows the ability to get the codec of an encoder via its identifier string
-
由 jp9000 提交于
-
由 jp9000 提交于
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 提交于
The comment says "these are different", but doesn't state why. Actually, I should really rename the output flags so they're not flags, but instead just "caps", because that's really all that they are.
-
- 04 1月, 2015 1 次提交
-
-
由 jp9000 提交于
If an async video source stops video for whatever reason, it would get stuck on the last frame that was played. This was particularly awkward when I wanted to give the user the ability to deactivate a source such as a webcam because it would get stuck on the last frame.
-
- 03 1月, 2015 2 次提交
- 28 12月, 2014 1 次提交
-
-
由 jp9000 提交于
This flag is actually useful under a number of circumstances, and has been requested a number of times.
-