This recent commit [1] broke SRT & RIST streaming because
obs_output_video now returns a NULL pointer for encoded outputs.
This fixes it by retrieving the pointer from the encoder.
[1] fb57eff212
Co-authored-by: tt2468 <tt2468@gmail.com>
Signed-off-by: pkv <pkv@obsproject.com>
(This commit also modifies obs-ffmpeg)
This change was meant for track matte stingers to prevent the last frame
from having risk of flashing due to their transparent nature, but this
code had a negative side effect on normal stingers as well.
Fixesobsproject/obs-studio#8981
Rendezvous mode with SRT protocol is used to punch through firewalls.
Although caller or listener mode are much more widespread, it is
sometimes in use. The rendezvous mode was broken in obs because we
would bind to the remote IP, instead of a local IP. This fixes the bug.
Note that there is also a bug in libsrt preventing our code to work.
But Version 1.5.2+ of libsrt fixes that.
Signed-off-by: pkv <pkv@obsproject.com>
Previously would always end up with OBS_MEDIA_STATE_ENDED whether the
video reaches the end or the user stops the source (state is set to
STOPPED, but becomes ENDED right after). This fixes it so that if the
user stops the source, it will remain stopped.
Default ffmpeg initial buffer fullness (75%) is too low
and results in significantly lower video quality on AMD cards.
Changing it to 100% fixes the quality and also matches what
AMF encoder is doing.
Passing struct darray type will loose the actual type of the contents.
Uses a defined type of `DARRAY(struct encoder_packet)` to carry the
type when crossing functions.
Some options do not require a media source restart. Saving source
unchanged source settings should also not trigger a restart.
I tried to also make it so speed changes do not require a restart by
manipulating the elapsed timestamp for the source, but it sometimes
causes the first few milliseconds after saving settings to be rough or
slightly distorted. I am also unsure whether a/v frame buffers should be
cleared on a speed change (and how to) so I made it so restarts are
required for speed changes. Chiyo also mentioned that successive quick
speed changes will cause maximum audio buffering (which I was able to
reproduce once).
Nonlocal file playback is unaffected, and will cause the media source to
restart because I am not aware of the possible consequences and because
there's no restart button for it.
Changing "Apply alpha in linear space" is only visible after a few
milliseconds (when mp_media_next_video is called for new frames).
If `is_stinger` and `full_decode` are toggled during runtime, even
though it shouldn't be possible as they are not accessible in the UI,
a media restart will be triggered.
Creation of Info.plist files through Xcode is more canonical and
future-proof, as it will automatically pick up changes/updates
introduced by Apple. Non-standard keys can still be added via a
template file, which will then be extended by Xcode with the default
keys.
Effectively reverting parts of d314d47, this commit removes the new
functions that got added to remove the flags parameter. Instead, it just
marks the parameter as unused and documents this. Having what is
effectively an API break just to remove a parameter is a bit overkill.
The other parts of d314d47 which cleaned up the usage of the flags
parameter are untouched here.
Switching to a static library that contains version information as
const char strings has multiple benefits:
* The version information provided externally via compiler definitions
will fail compilation early if malformed
* An updated version string (which will happen with every commit) will
not invalidate existing compilation units, because only the static
library is affected by the change
* An update of the version change just requires a recompilation of the
static library and a linker update
* An update of the version will _not_ infect the rest of the codebase
(as it does currently, because everything includes obsconfig.h one
way or another)
* Other modules which used the macro definition directly have been
updated as much as possible to use the proper getter method from
`libobs` instead (some Windows-specific modules use preprocessor
string composition, the value has been added as a compiler definition
directly in those cases)
* Because the impact of a version change due to a commit hash change
is limited to the static library, ccache hit rates should be
improved considerably
This deprecates the following functions, replacing them with new
versions:
- `obs_output_can_begin_data_capture()` - now `*capture2()`
- `obs_output_initialize_encoders()` - now `*encoders2()`
- `obs_output_begin_data_capture()` - now `*capture2()`
The flags parameter was initially designed to support audio-only or
video-only operation of an output which had the `OBS_OUTPUT_AV` flag,
however, full support for that was never implemented, and there are
likely fundamental issues with an implementation, mainly that most
outputs are programmed assuming that there will always be at least one
audio and one video track. This requires new flags specifying support
for optional audio/video, among other things.
An implementation to allow audio/video to be optional is best done
using the flag technique above, with audio/video enablement specified
by whether media (raw, `video_t/audio_t`) or encoder (`obs_encoder_t`)
objects are specified.
Since every implementation I could find always specifies `flags` as 0,
I was able to safely conclude that immediately removing the parameter's
functionality is safe to do.
The name of the obs_output_t won't appear in usual operation but some
output types have the translation and others do not. Let's translate
them.
Also translate `FilePath` property name.
A commit 4e140d2ff added AMF error messages but they were never used.
A commit 45d029b1f removed some code but a translation key "Advanced"
was left.
A commit 77fbfbe5c removed code to translate NVENC.TooManyBFrames but
the translation key was left.
A commit 6cc7cf3d5 removed the code to select codecs but the translation
was left.
If P216 or P416 color formats are selected with AMF, these color formats
were not explicitly handled, so the switch statements would end up in
the default case. If the user had also selected a Rec. 2100 color space,
this would result in the strange error message:
"OBS does not support 8-bit output of Rec. 2100."
This message is confusing and does not correctly reflect the chosen
settings. Let's explicitly handle the P216/P416 cases and provide a more
accurate error message.
If P216 or P416 color formats are selected with NVENC, OBS will fall
back from the native implementation to the FFmpeg implementation. Here,
P216 and P416 were not explicitly handled, so the switch statements
would end up in the default case. If the user had also selected a Rec.
2100 color space, this would result in the strange error message:
"OBS does not support 8-bit output of Rec. 2100."
This message is confusing and does not correctly reflect the chosen
settings. Let's explicitly handle the P216/P416 cases and provide a more
accurate error message.
Fixes an issue where update/destroy of a media source during reconnect
would block the parent thread until the next reconnect attempt. This
would result in significant quantities of dropped frames, delayed OBS
shutdown, or frozen UI during this period.
In avcodec.h, the docs for AVCodecContext->framerate say:
encoding: May be used to signal the framerate of CFR content to an
encoder.
OBS is designed to always output Constant Frame Rate (CFR) content.
Instead of letting this be implied, let's explicitly set the framerate
per the docs.
When using FFmpeg-based NVENC, with b-frames, and a non-1 framerate
numerator (eg. `1001/60000` aka 59.94fps), the DTS values outputted
by FFmpeg result in invalid DTS values.
Detect when using an unpatched FFmpeg build and correct the values
accordingly.
