When thread_type is set to FF_THREAD_FRAME, per the documentation
a latency of one frame per thread is introduced:
<https://ffmpeg.org/ffmpeg-codecs.html>, search for thread_type.
Additionally, we need in that case to calculate the automatic
number of threads ourselves, so as to accurately calculate the
latency.
The thread-type property allows specifying preferred
multithreading methods by user. Note that FF_THREAD_FRAME
may introduce additional latency especially on non-filesrc usecase,
since it introduces a decoding delay of (number of threads) frames.
https://bugzilla.gnome.org/show_bug.cgi?id=797254
This means we can use some newer features and get rid of some
boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
libavutil/mem.h:342:1: error: ‘alloc_size’ attribute ignored on a function returning ‘int’
av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t size);
^~~~~~~~~~~~~
Hopefully fixes build on jenkins.
The included libav requires it now. Otherwise the builds fails with:
CCLD libgstlibav.la
build-i686-w64-mingw32/gst-libs/ext/.libs/libavutil.a(random_seed.o): In function `av_get_random_seed':
gst-libav-1.16.0/gst-libs/ext/libav/libavutil/random_seed.c:126: undefined reference to `BCryptOpenAlgorithmProvider@16'
gst-libav-1.16.0/gst-libs/ext/libav/libavutil/random_seed.c:129: undefined reference to `BCryptGenRandom@16'
gst-libav-1.16.0/gst-libs/ext/libav/libavutil/random_seed.c:130: undefined reference to `BCryptCloseAlgorithmProvider@8'
collect2.exe: error: ld returned 1 exit status
The version of libavutil is printed in the log instead of libavcodec
because avutil_version() returns LIBAVUTIL_VERSION_INT. This can be confusing,
so we should be replace it with avcodec_version().
See https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/41#note_142808
The switch to the new ffmpeg property system changed the type of the
bitrate property from int to int64, which potentially breaks many
existing applications at runtime as properties are usually set via
g_object_set().
As such, override the type to int until GStreamer 2.0.
.. and other formats where ffmpeg gives us multiple
subframes per input frame.
Since we now support non-interleaved audio, we can't
just concat buffers any more. Also, audio metas won't
be combined when buffers are merged, so when we push
out the combined buffer we'll look at the meta describing
only the first subframe and think it covers the whole
frame leading to stutter/gaps in the output.
We could fix this by copying the output data into a new
buffer when we merge buffers, but that's suboptimal, so
let's add some API to GstAudioDecoder to push out subframes
and use that instead.
https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/49
The start time is supposed to be the ts of the first frame.
FFmpeg uses fractions to represent timestamps and the start time may use a
different base than the frame pts. So we may end up having the start
time bigger than the pts because of rounding when converting to gst ts.
See https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/51
for details.
This commit adds a .gitlab-ci.yml file, which uses a feature
to fetch the config from a centralized repository. The intent is
to have all the gstreamer modules use the same configuration.
The configuration is currently hosted at the gst-ci repository
under the gitlab/ci_template.yml path.
Part of https://gitlab.freedesktop.org/gstreamer/gstreamer-project/issues/29
When building with MSVC, if the 3rd operator is a double, the entire
expression always promoted double, and is then cast to int64.
When TRUE, this evaluates to (gint64) (gdouble) (INT64_MAX)
which overflows to INT64_MIN on MSVC, but not on C99 compilers.
This causes us to fail the g_return_if_fail inside g_param_spec_int64
when built with MSVC.
