Media files that have a very low framerate or very long interval between
frames would cause the media playback to stall indefinitely until the
next frame is played. This adds a 200ms timeout to ensure that the
media can be destroyed without being forced to wait indefinitely for the
next frame.
Certain functions such as avformat_open_input and av_read_frame can
block, causing the program to someone wait very long periods of time
when a network URL is used with the media source. The
interrupt_callback member variable in AVFormatContext allows safely
canceling IO operations when trying to shut down or stop the
media-playback interface.
(Note: This commit also modifies deps/media-playback)
Allows buffering network-based media sources where supported. Default
is two megabytes of buffering.
Currently, when media-playback is used with a network address, video has
to wait for the first keyframe before it starts decoding. This is
probably not wise because the first packet of video may contain
additional header information, and because audio is forced to wait and
buffer while waiting for a keyframe, potentially causing a lot of audio
to get backed up unnecessarily which could inadvertently cause sync or
audio playback issues.
So, instead of waiting for a keyframe before decoding starts, decode
right away, and make it wait for a keyframe before calling the video
callback instead.
When using the full installer, there'll be a section where you can
choose what to install -- one section is a tree view with a "plugins"
section, and in that section there's "Browser plugin" and "Realsense
plugin". Instead of superfluously saying "plugin" for each of those,
replace with "source" instead -- so browser source and realsense source.
Also somewhat helps prevent the user from getting confused and thinking
we're installing a browser or something.
This reverts commit d1343dc064484aacaf3e34e477111795b555b758.
Apparently people are having issues caused by this specific commit.
Going to temporarily revert for the time being.
When custom server is used, it would still use the "common" RTMP service
to cap its bitrate. So if Twitch was selected and you changed over to
custom RTMP server, it would still cap to Twitch's bitrate limits even
though you're not using Twitch anymore.
There's no need to reset vertex buffers like this anymore. This would
unintentionally cause certain things (such as the freetype text source
on windows) to stop rendering properly.
When an output fails to connect and it's already been prematurely
stopped, the event to mark the output as stopped would not be signaled,
causing obs_output_destroy to lock up indefinitely while waiting for the
event to be signaled.
Prevents the output from hard-locking on itself when the stop call would
trigger the callback and then try to lock again. Probably could be
solved with a recursive mutex, but at that point it's not really
necessary.
Rather than have the back-end try to determine whether the output can or
cannot stop, allow the stop callback to continue in the plugin either
way and let the plugin itself make that determination.
This fixes a bug where the back-end wouldn't have data active while
connecting, therefore the stop callback wouldn't be called, and once
connected it wouldn't know that it was supposed to stop. In other words
trying to call obs_output_stop on an output that was in a state of
connecting would do nothing and the output would never stop.
The radio buttons had been changed so "Streaming" would be selected by
default, but it only sets the wizard's "type" to streaming if the user
actually clicks the radio button themselves manually, so it would stay
set to "Invalid" by mistake, causing settings to not be applied.
When media returns frames with negative linesizes, it means they're
inverted RGB formats and start from the last line of the image and move
back to the top via the negative linesize number. This would cause a
crash because this wasn't being taken in to account, and it would
traverse in to invalid memory.
Changes the default autoconfig test bitrate to 10000kb/s, which will
then be capped by the user's service selection (so it'll still only use
6000 on Twitch for example, but will allow 10000 on Youtube and others).
