CMake doesn't expect CMake package files to be separated in
subdirectories on Windows and instead expects all files to be put in
a single directory `cmake` found within one of the PREFIX paths.
Also fixes circular dependency in w32-pthreads CMake package config
file.
Checking the format of the AVCodecContext will result in using the
format of the hardware-side frames, not the software-side frames. This
uses the software frame parameters itself to initialize the swscale
context.
Fixes issue #10369.
Since the update to FFmpeg 6.1, streams to a Media Source are broken
if hardware decoding is enabled (both RTMP or SRT have been reported).
The video is black although the audio is decoded fine.
The manual copy of metadata introduced in commit [1] does not work any
more for some unfathomable reasons.
As a fix we call instead the av_frame_copy_props function used in FFmpeg
app in a similar context (hardware decoding) [2].
The metadata are copied without issues.
There is no need to guard the use of that function since it was
introduced 9 years ago in avutil/frame.c.
[1] 22fde5cdcd
[2] https://github.com/FFmpeg/FFmpeg/master/fftools/ffmpeg_dec.c
Signed-off-by: pkv <pkv@obsproject.com>
The optimization silences the warning about type limits on platforms
with `char` type as `unsigned char`.
The original condition is semantically identical to the optimized one
because the signed-to-unsigned cast is well-defined in C standard.
Inlined functions in Python's header files result in unresolvable
symbols at link time when building in Debug config on Windows.
This downgrades the upper limit on Windows to 3.10 again until a proper
fix can be found.
macOS is unaffected because it can link binaries with dynamic runtime
lookup.
Prior code would not only iterate over possible versioned python DLL
names, but also replace possible named subdirectories contained in the
path string.
This commit changes the same code to only change the filename and leave
the path prefix intact.
Fixes for using FFmpeg 6.1 due to deprecations. Uses `#if` macros to
allow builds for using older versions of FFmpeg.
AVFrame.key_frame was replaced with a flag in AVFrame.flags. The commit
adding the flag is [1] in FFmpeg's repository, and the deprecation is in
commit [2].
In summary of the "key_frame" change, AVFrame.key_frame is deprecated,
and AVFrame.flags indicates with a bit flag if it is a key frame (with
the enum/defined AV_FRAME_FLAG_KEY).
[1]: avutil/frame: add a keyframe flag to AVFrame
cc11191fda
[2]: avutil/frame: deprecate key_frame
3e06f6f040
Fixes for using FFmpeg 6.1 due to deprecations. Uses `#if` macros to
allow builds for using older versions of FFmpeg.
The change in deps/media-playback/media-playback/decode.c is due to
FFmpeg moving "side_data" into AVCodecParameters which is mentioned in
commit [1] in FFmpeg's repository.
In summary of the "side_data" change, AVStream.side_data is deprecated
and replaced with AVStream.codecpar->coded_side_data, and
AVStream.nb_side_data is replaced with
AVStream.codecpar->nb_coded_side_data.
[1]: avcodec/codec_par: add side data to AVCodecParameters
21d7cc6fa9
Python automatically creates bytecode caches which end up inside the
application bundle of OBS Studio on macOS. These directories will lead
to a hash mismatch when Sparkle attempts to apply a delta update (to
ensure that the patch can be applied).
As the added directories will make the hash check fail, having a valid
Python framework configured in OBS Studio (even without any script
added) will thus prevent Sparkle from using delta updates.
This commit adds a utility to connect to a TCP endpoint that may
be dual-stack IPv4/IPv6 using fast fallback. It will attempt the
prefered address family first, followed by the other 200ms later.
The first to connect will be the socket that is handed back
to the caller.
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.
