The discovered frame rate is only available on the AVStream
itself. Updating the temporary context framerate before
building caps from it seems like a pretty non-intrusive approach.

Fixes #75

Part-of: <gstreamer/gst-libav!74>

Documentation for AVCodecContext::time_base:

> decoding: the use of this field for decoding is deprecated.
> Use framerate instead.

Part-of: <gstreamer/gst-libav!74>

Matej authored May 09, 2020 and GStreamer Marge Bot committed May 09, 2020

Move G_BEGIN_DECLS below includes and add missing include

Part-of: <gstreamer/gst-libav!71>

otherwise we get incomplete colorimetry that video-info complains about

Part-of: <gstreamer/gst-libav!70>

Part-of: <!68>

Starting with 1.17, we will not ship a copy of FFmpeg in our release
tarballs, and all the remaining code is LGPL2.

Part-of: <!68>

Without this fix, running the command below will get an error randomly.

Example:
gst-launch-1.0 videotestsrc ! vp9enc ! avmux_ivf ! fakesink

ERROR: pipeline doesn't want to preroll.
0:00:02.388528491 30148 0x5601b424a370 ERROR                  libav :0::
Tag [1]V[0][0] incompatible with output codec id '167' (VP90)

See the change of -base gstreamer/gst-plugins-base!594

Otherwise videotestsrc ! avenc_libx265 ! fakesink
outputs `Unsupported multiview mode - no mapping in libav`

Sebastian Dröge authored Jan 24, 2020 and Sebastian Dröge committed Jan 24, 2020

Otherwise we don't know yet whether we'll have extradata/codec_data, so
can't decide on the stream-format yet.

Haihao Xiang authored Jan 15, 2020 and Víctor Manuel Jáquez Leal committed Jan 24, 2020

Besides vp8, ff_ivf_muxer supports VP9 and AV1

Sebastian Dröge authored Jan 23, 2020 and Sebastian Dröge committed Jan 24, 2020

avcodecmap: Set AAC/H264/H265 stream-format for demuxer/encoder situations if no codec_data is provided

This fixes output of the above formats from demuxers.

Some demuxers make use of it in various ways, for example the HLS
demuxer.

When the `max-threads` property is not specified, GStreamer defaults to
the amount of CPU threads in the system.

The number of threads used in avdec has a direct impact on the latency
of the decoder, which is of as many frames as threads. Therefore, big
numbers of threads can make latency levels that can be problematic in
some applications.

For this reason, ffmpeg emits a warning when more than 16 threads are
requested.

This patch limits the default number of threads to 16. This affects only
computers with more than 16 CPU threads when using avviddec without
setting `max-threads`.

Was never hooked up to meson build it seems, and only ever used
by the uninstalled autotools dev env to locate gst-libav plugins
for use in unit tests in other modules.

Edward Hervey authored Nov 29, 2019 and Edward Hervey committed Nov 29, 2019

Instead of returning the default return value (GST_FLOW_OK), actually
return an error one (res vs ret).

Kevin JOLY authored Nov 04, 2019 and Kevin committed Nov 04, 2019

Some plugins (like libcdio) registers empty long_name field. Calling strncmp on this field leads to a segmentation fault.

Signed-off-by: Kevin Joly <joly.kevin25@gmail.com>

AVBufferRef -> GstFFMpegVideoDecVideoFrame -> GstVideoCodecFrame -> AVBufferRef

Instead of holding additional ref there, set read-only which would not be
reused by ff_reget_buffer()

Fixes: gstreamer/gst-libav#63

... instead of filtering them by hardcoded string compare.

... if ffmpeg would reuse the allocated AVBuffer. Reused AVFrame by
the ffmpeg seems to break our decoding flow since the reused AVFrame
holds the initial opaque data (GstVideoCodecFrame in this case), so
we couldn't trace the our in/out frames.
To enforce get_buffer() call per output frame, hold another reference
to the AVBuffer in order to mark the AVBuffer as not writable.

Fixes: gstreamer/gst-libav#62

... between GStreamer and FFmpeg. Note that FFmpeg follows ISO/IEC 23001-8
defined color{matrix,transfer,primaries} values.

Marc Leeman authored Sep 11, 2019 and Mathieu Duponchelle committed Sep 11, 2019

Do not require the cache generator. This is in line with the other
gstreamer modules

Mathieu Duponchelle authored Aug 13, 2019 and Sebastian Dröge committed Aug 13, 2019

Same approach as x264enc, with the one hour offset

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.

Seungha Yang authored Oct 06, 2018 and Mathieu Duponchelle committed Jul 18, 2019

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

Otherwise we'll leak some memory.

See gst-libav!32

Regression from 1e4529ce

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.

It was never usable as we don't have a parser and we now have 'cdgdec'
in gst-plugins-rs.

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.

Map more transfer functions between Gstreamer and ffmpeg