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>
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
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.
Adds a check to make sure that delayed preload is ignored if the stinger
is restarted/interrupted. Just adds this check to the previous commit to
make sure that it doesn't redundantly try to preload a frame when
playback is restarted.
The `mp_media::obsframe` varaible is a variable used to store the
current frame, or the first frame on stop. However, it's never cleared,
and while decoding a frame, it's invalid. The variable was added for
delayed preloading of the first frame for stingers.
Now, for more context, when media sources stop, it stores the first
frame of the video so it can set the source's current async texture to
that frame, effectively preloading the first frame into the backend,
making it so that when you play back that media, it's able to start
playback instantly without having to wait for the thread to play back
that frame, causing seamless playback.
Normally, preload happens right when first frame is finished decoding,
thus it wasn't a problem before these variables and delayed preloading
was added. However, with stingers, I delayed that preload further
because stingers are kind of a special case because the stinger does not
clear itself right away on stop. Because of that, it was causing it to
flash the first frame at the end of the stinger. This is why `obsframe`
and `request_preload` were added: it's a way of signaling the media
source to preload the first frame when the stinger itself is fully
completed. It was added to fix that stinger bug.
However, if the user interrupts playback of the stinger (e.g. swaps to
another scene while in the middle of the transition), that
`request_preload` might still be queued and happen while the media
source is still decoding, and thus, while `obsframe` is invalid.
I realize that we should probably refactor and clean up the
media-playback lib.
It's possible that frame_ready is false when this function is called,
which implies that the mp_decode frame field is not valid. However we
dereference the frame by counting the number of audio channels before
checking the value of frame_ready, causing a crash.
Every time a media player instance would be initialized, it would
create a new `Set FFmpeg options:` log message. With lots of looping
media sources, this gets incredibly spammy. It's already being logged
by the media source itself, so this line is pretty much unnecessary.
The incorrect variable was used in a comparison, causing playback to
stop prematurely depending on whether the audio data or video data ended
first.
Closesobs-project/obs-studio#8422
Also modifies libobs & deps/media-playback.
AV_CODEC_CAP_TRUNCATED was removed in avcodec 60 [1].
We ifdef the code depending on it to allow compilation.
[1] avcodec: remove FF_API_FLAG_TRUNCATED
3ceffe7839
Signed-off-by: pkv <pkv@obsproject.com>
Stingers -- and especially track matte stingers -- are currently subject
to real time decoding, which can be detrimental in a production
environment where a stinger video may not be able to decode in a timely
fashion.
To remedy this, this change adds an option to fully decode stingers
immediately and cache the decoded video/audio in RAM for playback to
greatly improve stinger performance.
This fixes deprecation warnings since the channels member of
AVCodecContext is marked as deprecated [1], as well as the channels
member of AVFrame [2].
In all instances where a warning appear, a switch to the new API is
done.
[1] lavc: switch to the new channel layout API
FFmpeg/FFmpeg@548aeb9
[2] Bump minor versions after the channel layout changes
FFmpeg/FFmpeg@cdba98bb80
Signed-off-by: pkv <pkv@obsproject.com>
Previous FFmpeg deprecation fix, and optimization attempt causes short
videos to loop badly. Keep deprecation fix, and fix the rest later.
Fixes d528f6cafa
Rec. 2020 is really an SDR spec, but I think HDR10 made it okay to slap
PQ on it, call it an HDR spec. Rec. 2100 came along after and formally
allowed the use of PQ/HLG, so we should use 2100 instead.
