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
We expect it to be a int or uint, however it changed the type to a
int64_t in later versions of ffmpeg. As such it would be passed as a 64
bit value to varargs functions, while the consumer of the arguments
assumes only 32 bits. This causes crashes.
https://bugzilla.gnome.org/show_bug.cgi?id=771092
When switching playback modes, like from TRICKMODE or TRICKMODE_KEY_UNITS
back to regular playback, we need to make sure we set the skip mode
back to the default setting.
While this field would be properly reset when we *have* feedback from
downstream (i.e. diff != G_MAXINT64), it would not be reset during
the initial phase (i.e. when the decoder hasn't pushed a buffer yet,
and therefore the sink hasn't sent back QoS information).
This avoids dropping plenty of frames when going back to regular playback
Several decoders will only be able to report a real latency (has_b_frames)
once they're actually initialized (i.e. when they return their first frame).
Doing it earlier (in set_format) doesn't guarantee that the AVCodecContext
has_b_frames has been properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=766362
Otherwise we will consider them as one frame of raw audio that is still
pending, and shift all timestamps by the amount of time spent with header
buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=765797
Various functions in libavcodec need them, like the format, sample rate, etc.
and just having them in the context is not enough.
This fixes draining for codecs like MP2 that require a fixed frame size and
require libav to pad the last frame if required.
The GObject macros either for GstFFMpegVidDec and GstFFMpegVidEnc can
break the compilation because they are not GTypes, since each av video
elements are registered in runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=764162
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
It has its own allocator that is not necessarily doing the same as malloc and
will then usually crash. E.g. on Windows or when memalign() is available.
In ffmpeg this is the same as FRONT_CENTER, but we distinguish between
FRONT_CENTER and MONO in GStreamer. Add an explicit mapping for this special
case in the translations functions.
https://bugzilla.gnome.org/show_bug.cgi?id=759846
Handling slice_offset in avviddec is resulting in invalid memory read.
Since rv decoders anyways handle slice_offset, removing the same to fix
memory mishandlings
https://bugzilla.gnome.org/show_bug.cgi?id=758726
Error out if system's libav* libraries are not
provided by FFmpeg. Libav-incompatible changes
were introduced to support the latter so we
can no longer support both.
https://bugzilla.gnome.org/show_bug.cgi?id=758183
If downstream does not provide a (usable) pool, we would use our internal
pool. But the internal pool might be configured with a different width/height
because of padding, which then will cause problems if we push buffers from it
directly downstream.
Instead create a new pool if the width/height is different.
This prevents crashes with vaapisink and d3dvideosink for example.
Based on the debugging results and discussions with
Nicolas Dufresne <nicolas.dufresne@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758344
