libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
/******************************************************************************
|
|
|
|
|
Copyright (C) 2015 by Hugh Bailey <obs.jim@gmail.com>
|
|
|
|
|
|
|
|
|
|
This program is free software: you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
the Free Software Foundation, either version 2 of the License, or
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
|
|
#include <inttypes.h>
|
|
|
|
|
#include "obs-internal.h"
|
|
|
|
|
|
2016-06-20 16:07:29 -07:00
|
|
|
static inline bool delay_active(const struct obs_output *output)
|
|
|
|
|
{
|
|
|
|
|
return os_atomic_load_bool(&output->delay_active);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool delay_capturing(const struct obs_output *output)
|
|
|
|
|
{
|
|
|
|
|
return os_atomic_load_bool(&output->delay_capturing);
|
|
|
|
|
}
|
|
|
|
|
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
static inline void push_packet(struct obs_output *output,
|
2019-06-22 22:13:45 -07:00
|
|
|
struct encoder_packet *packet, uint64_t t)
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
{
|
|
|
|
|
struct delay_data dd = {0};
|
|
|
|
|
|
|
|
|
|
dd.msg = DELAY_MSG_PACKET;
|
2019-06-22 22:13:45 -07:00
|
|
|
dd.ts = t;
|
2016-12-07 12:45:25 -08:00
|
|
|
obs_encoder_packet_create_instance(&dd.packet, packet);
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
|
|
|
|
|
pthread_mutex_lock(&output->delay_mutex);
|
|
|
|
|
circlebuf_push_back(&output->delay_data, &dd, sizeof(dd));
|
|
|
|
|
pthread_mutex_unlock(&output->delay_mutex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void process_delay_data(struct obs_output *output,
|
2019-06-22 22:13:45 -07:00
|
|
|
struct delay_data *dd)
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
{
|
|
|
|
|
switch (dd->msg) {
|
|
|
|
|
case DELAY_MSG_PACKET:
|
2016-06-20 16:07:29 -07:00
|
|
|
if (!delay_active(output) || !delay_capturing(output))
|
2016-12-07 12:45:25 -08:00
|
|
|
obs_encoder_packet_release(&dd->packet);
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
else
|
|
|
|
|
output->delay_callback(output, &dd->packet);
|
|
|
|
|
break;
|
|
|
|
|
case DELAY_MSG_START:
|
|
|
|
|
obs_output_actual_start(output);
|
|
|
|
|
break;
|
|
|
|
|
case DELAY_MSG_STOP:
|
2016-06-11 11:42:29 -07:00
|
|
|
obs_output_actual_stop(output, false, dd->ts);
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void obs_output_cleanup_delay(obs_output_t *output)
|
|
|
|
|
{
|
|
|
|
|
struct delay_data dd;
|
|
|
|
|
|
|
|
|
|
while (output->delay_data.size) {
|
|
|
|
|
circlebuf_pop_front(&output->delay_data, &dd, sizeof(dd));
|
|
|
|
|
if (dd.msg == DELAY_MSG_PACKET) {
|
2016-12-07 12:45:25 -08:00
|
|
|
obs_encoder_packet_release(&dd.packet);
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
output->active_delay_ns = 0;
|
2016-06-20 16:07:29 -07:00
|
|
|
os_atomic_set_long(&output->delay_restart_refs, 0);
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool pop_packet(struct obs_output *output, uint64_t t)
|
|
|
|
|
{
|
|
|
|
|
uint64_t elapsed_time;
|
|
|
|
|
struct delay_data dd;
|
|
|
|
|
bool popped = false;
|
|
|
|
|
bool preserve;
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------ */
|
|
|
|
|
|
|
|
|
|
preserve = (output->delay_cur_flags & OBS_OUTPUT_DELAY_PRESERVE) != 0;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&output->delay_mutex);
|
|
|
|
|
|
|
|
|
|
if (output->delay_data.size) {
|
|
|
|
|
circlebuf_peek_front(&output->delay_data, &dd, sizeof(dd));
|
|
|
|
|
elapsed_time = (t - dd.ts);
|
|
|
|
|
|
|
|
|
|
if (preserve && output->reconnecting) {
|
|
|
|
|
output->active_delay_ns = elapsed_time;
|
|
|
|
|
|
|
|
|
|
} else if (elapsed_time > output->active_delay_ns) {
|
|
|
|
|
circlebuf_pop_front(&output->delay_data, NULL,
|
2019-06-22 22:13:45 -07:00
|
|
|
sizeof(dd));
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
popped = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&output->delay_mutex);
|
|
|
|
|
|
|
|
|
|
/* ------------------------------------------------ */
|
|
|
|
|
|
|
|
|
|
if (popped)
|
|
|
|
|
process_delay_data(output, &dd);
|
|
|
|
|
|
|
|
|
|
return popped;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void process_delay(void *data, struct encoder_packet *packet)
|
|
|
|
|
{
|
|
|
|
|
struct obs_output *output = data;
|
|
|
|
|
uint64_t t = os_gettime_ns();
|
|
|
|
|
push_packet(output, packet, t);
|
2019-06-22 22:13:45 -07:00
|
|
|
while (pop_packet(output, t))
|
|
|
|
|
;
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void obs_output_signal_delay(obs_output_t *output, const char *signal)
|
|
|
|
|
{
|
2016-01-18 20:01:58 -08:00
|
|
|
struct calldata params;
|
|
|
|
|
uint8_t stack[128];
|
|
|
|
|
|
|
|
|
|
calldata_init_fixed(¶ms, stack, sizeof(stack));
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
calldata_set_ptr(¶ms, "output", output);
|
|
|
|
|
calldata_set_int(¶ms, "sec", output->active_delay_ns / 1000000000);
|
|
|
|
|
signal_handler_signal(output->context.signals, signal, ¶ms);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool obs_output_delay_start(obs_output_t *output)
|
|
|
|
|
{
|
|
|
|
|
struct delay_data dd = {
|
|
|
|
|
.msg = DELAY_MSG_START,
|
2019-06-22 22:13:45 -07:00
|
|
|
.ts = os_gettime_ns(),
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
};
|
|
|
|
|
|
2016-06-20 16:07:29 -07:00
|
|
|
if (!delay_active(output)) {
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
bool can_begin = obs_output_can_begin_data_capture(output, 0);
|
|
|
|
|
if (!can_begin)
|
|
|
|
|
return false;
|
|
|
|
|
if (!obs_output_initialize_encoders(output, 0))
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&output->delay_mutex);
|
|
|
|
|
circlebuf_push_back(&output->delay_data, &dd, sizeof(dd));
|
|
|
|
|
pthread_mutex_unlock(&output->delay_mutex);
|
|
|
|
|
|
2016-06-11 11:42:29 -07:00
|
|
|
os_atomic_inc_long(&output->delay_restart_refs);
|
|
|
|
|
|
2016-06-20 16:07:29 -07:00
|
|
|
if (delay_active(output)) {
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
do_output_signal(output, "starting");
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!obs_output_begin_data_capture(output, 0)) {
|
|
|
|
|
obs_output_cleanup_delay(output);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void obs_output_delay_stop(obs_output_t *output)
|
|
|
|
|
{
|
|
|
|
|
struct delay_data dd = {
|
|
|
|
|
.msg = DELAY_MSG_STOP,
|
2019-06-22 22:13:45 -07:00
|
|
|
.ts = os_gettime_ns(),
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&output->delay_mutex);
|
|
|
|
|
circlebuf_push_back(&output->delay_data, &dd, sizeof(dd));
|
|
|
|
|
pthread_mutex_unlock(&output->delay_mutex);
|
|
|
|
|
|
|
|
|
|
do_output_signal(output, "stopping");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void obs_output_set_delay(obs_output_t *output, uint32_t delay_sec,
|
2019-06-22 22:13:45 -07:00
|
|
|
uint32_t flags)
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
{
|
|
|
|
|
if (!obs_output_valid(output, "obs_output_set_delay"))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if ((output->info.flags & OBS_OUTPUT_ENCODED) == 0) {
|
2019-06-22 22:13:45 -07:00
|
|
|
blog(LOG_WARNING,
|
|
|
|
|
"Output '%s': Tried to set a delay "
|
|
|
|
|
"value on a non-encoded output",
|
|
|
|
|
output->context.name);
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
output->delay_sec = delay_sec;
|
|
|
|
|
output->delay_flags = flags;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint32_t obs_output_get_delay(const obs_output_t *output)
|
|
|
|
|
{
|
2019-06-22 22:13:45 -07:00
|
|
|
return obs_output_valid(output, "obs_output_set_delay")
|
|
|
|
|
? output->delay_sec
|
|
|
|
|
: 0;
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint32_t obs_output_get_active_delay(const obs_output_t *output)
|
|
|
|
|
{
|
2019-06-22 22:13:45 -07:00
|
|
|
return obs_output_valid(output, "obs_output_set_delay")
|
|
|
|
|
? (uint32_t)(output->active_delay_ns / 1000000000ULL)
|
|
|
|
|
: 0;
|
libobs: Add encoded output delay support
This feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
2015-09-06 15:39:46 -07:00
|
|
|
}
|