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
It's actually a parser but it a) can only work with the ffmpeg GIF
decoder that is deactivated anyway, and b) it currently causes infinite
linking of avdemux_gif elements with a multiqueue in between in
decodebin.
https://bugzilla.gnome.org/show_bug.cgi?id=775516
