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.
We currently pass a 'buffer_size' option to avformat in bytes.
Unfortunately, avformat/librist.c admits an option with the same name but in milliseconds.
The default values set in the UI (2 MB) go beyond the range admitted in ms (0-30 000)
so avformat issues errors.
This fix disables the option when rist protocol is detected.
Signed-off-by: pkv <pkv@obsproject.com>
AVFormatContext::oformat was made const on April 27, 2021 [1]. If we
respect the constness of AVOutputFormat and do not cast results from
FFmpeg functions to non-const, we cannot modify the results after the
fact. Our choices are either to cast them to non-const (and presumably
have them implicitly casted back to const on later function calls), or
only try to modify the results in versions of FFmpeg where these are not
expected to be const.
Instead of relying on casts, we can set the encoder values in the
ffmpeg_cfg struct, which are later passed to new_stream.
Also modifies deps/media-playback. Removes compiler warnings.
Some avformat functions return const AV(In/Out)putFormat per [1], so
ifdef as needed.
[1]: 56450a0ee4
lavf 59.0.100 avformat.h
avformat: Constify the API wrt AV(In|Out)putFormat
Also constify AVProbeData.
If there is a PTS discontinuity in the playback stream that causes the PTS to
reset, it is likely that new audio frames will come in while there are still
video frames waiting to be dequeued. This will cause the audio frames to be
played while the video frames wait for the PTS to get back up to where they
were before the discontinuity.
With certain audio encoders, gaps can be introduced into the audio
packets, causing the audio duration to be miscalculated because it
calculated audio duration based upon the PTS of the current packet to
the last packet. However, this audio encoder also did not store
timestamps for most of its audio packets, causing PTS values to be
calculated based upon duration values. So those two things combined
caused audio timestamps to go all out of whack when playing back certain
videos with the media source. This is particularly prevalent with WMV
files using Microsoft codecs.
So to fix it, when the duration needs to be calculated, just calculate
the duration based upon the sample count of the audio packet. This fixes
the issue with the video in question that caused problems, and likely
fixes issues in a lot of videos that may have been floating out there
for some time. Basically this is a fix for a potential long-standing
issue.
Closesobsproject/obs-studio#3683
Fixes a bug where playback would completely stop when manually seeking
to the end of the file. Playback should not officially stop until
playback has unpaused.
If seeking occurs too close to the previous time value, it could cause
the playback to delay an abnormal amount of time, or if the time value
is under the previous value, then it would cause an assert. So instead,
reset the next timestamp value to be instant in both cases if a seek
occurs to ensure timely playback.
