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
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
