... 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: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/62
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
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.
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.
This matches all other plugins in the other gstreamer repos. This is
also necessary for generating the correct libtool archive (.la) files
in Cerbero which are needed for static linking on Android and iOS.
In the function gst_ffmpeg_formatid_get_codecids() in the if / else if
construct the special case !strcmp (format_name, "pva") should be
handled before the generic case (plugin->audio_codec !=
AV_CODEC_ID_NONE) || (plugin->video_codec != AV_CODEC_ID_NONE)
This patch fixes the ordering.
I stumbled accorss this issue while adding a new format to
gst_ffmpeg_formatid_get_codecids()
https://bugzilla.gnome.org/show_bug.cgi?id=796738
This removes the internal interleave loop and always negotiates
the native output layout of the libav decoder. Users can use
audioconvert to interleave if necessary.
Special care has been taken to leave the encoder unaffected by
the changes in avcodecmap, since GstAudioEncoder doesn't support
the non-interleaved layout yet.
https://bugzilla.gnome.org/show_bug.cgi?id=705977
We were ignoring these before the port to 4.0, interpreting them
as GST_FLOW_ERROR / GST_ELEMENT_ERROR causes check failures.
We should start using GST_*_DECODER_ERROR in latter commits,
for now simply restore the previous behaviour.
avcodec_align_dimensions2 uses context->pix_fmt to make its
calculations, we thus need to make sure it is adequately set
when calling it.
Fixes:
gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080 \
! avenc_mpeg4 ! avdec_mpeg4 ! xvimagesink
This showed invalid writes under valgrind, then segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=792900
We were previously installing hardcoded properties for all
video encoders, refactor to instead use FFmpeg's AVOption API.
avvidenc still exposes a few properties related to the pass
mechanism: while the AVOption API allows specifying both passes
as flags at the same time, this is not practical in GStreamer's
context, where passes need to be run separately using a stats file.
https://bugzilla.gnome.org/show_bug.cgi?id=792900
The remaining use of CODEC_ are codec flags that has been moved into the
new codec private properties or have been deperated. Will be fixed in
later patches.
https://bugzilla.gnome.org/show_bug.cgi?id=792900
Autotools automatically appends user CPPFLAGS after target
CPPFLAGS. Also, it puts all CPPFLAGS before CFLAGS in final
generated gcc compile command. The internal ffmpeg include
paths need to come before any other external include paths
to ensure we don't accidentally pickup external ffmpeg
headers first (i.e. from user CPPFLAGS include paths). Thus,
move the internal LIBAV include paths to LIBAV_CPPFLAGS so
that they come before any user defined CPPFLAGS.
This allows ffmpeg and gst-ffmpeg to coexist on users system.
https://bugzilla.gnome.org/show_bug.cgi?id=789379
This reverts commit 4284d791bc.
It causes crashes on various h264 and DNXHD/VC3 streams, where the
decoders write to arbitrary memory far after what we've allocated.
As a side effect, left/right green bars goes away when using
xvimagesink. I just think that xv cropping is broken, so this is
probably just hiding a bug.
While all this information is in the .la files, libtool seems to get
confused with ordering in presence of static system libraries. This could
cause missing symbol error at link time. Adding these depenencies explicitly
workaround the issue.
This should help libtool in getting the internal linking right.
Effectively, libtool can sometime get the link order wrong when
presented with a mix of .la and -l arguments. These .la file are
also required by the android build system and were previously
created by cerbero.
The install line was using -t parameter which is not supported on OSX.
Instead, use automake DATA installation mechanism, this way we rely on
automake to generate portable scripts.
In the last iteration, we kept the original method to link the shared
plugin and edited the .a and .la files so satisfy what cerbero needed.
Unfortunately, that required adding .a file into the archive which is
not allowed with iOS ar command for universal builds.
This patch uses standard method to link a static library. One of the
benefit is that it removes some libtool warning about portability.
For the static case, we implement an install hook that installs
FFMPEG internal .a files in the plugin directory (so it does not get
confused with a possible system FFMPEG. This makes the static plugin
usable without depending on cerbero recipe.
Libtool will produce libgstlibav.la and libgstlibav.lai (the installed
version). We need to edit at least the installed version for the final
linking of static application to work.
Some libtool will endup removing the shared build when running a static
build. That had unwanted side effect. Rather then fighting libtool to
get to build each static and shared seperatly, let libtool build with
the LIBAV_DEPS added to LIBADD (list of libav*.a) and finally remove the
extra .a from the archive and fix the .la to what cerbero will expect.
When building plugins with internal FFMPEG, we use different link
flags depending if it is static or shared. As we want to build both
static and dynamic plugins at once, rewrite the rules so we can
pass the right flags.
https://bugzilla.gnome.org/show_bug.cgi?id=779344
