- Oct 21, 2020
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Oct 20, 2020
-
-
Tim-Philipp Müller authored
From 59cb678 to a825d27
-
- Oct 14, 2020
-
-
Since the commit https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/22b25b3ea5c, ffmpeg will not clear draning flag for encoder by avcodec_flush_buffers() API by default. Allowed case is only if encoder has AV_CODEC_CAP_ENCODER_FLUSH capability flag. If it's not supported, we should re-open encoding session, otherwise ffmpeg encoder will keep returning AVERROR_EOF Part-of: <gstreamer/gst-libav!104>
-
This is already done in all other codec elements. Part-of: <gstreamer/gst-libav!103>
-
Same behaviour as for avviddec now. FFmpeg will return AVERROR_EOF when it's completely drained but we should not return that here or otherwise upstream will receive EOS and not forward us more data. Part-of: <gstreamer/gst-libav!103>
-
Seungha Yang authored
AVERROR_EOF means that it's fully drained, but it doesn't mean that that end of stream. Part-of: <gstreamer/gst-libav!94>
-
Seungha Yang authored
audiodecoder baseclass implementation is expecting that finish_subframe() is followed by finish_frame() in order clear its internal state related to subframe. Part-of: <gstreamer/gst-libav!94>
-
It might be useful for upstream to know that draining/finishing didn't succeed, and why. Part-of: <gstreamer/gst-libav!94>
-
It might be useful for upstream to know that draining/finishing didn't succeed, and why. Part-of: <gstreamer/gst-libav!94>
-
When sucessfully finishing out frames (or finishing configuration), we must make sure we don't override any failing GstFlowReturn that might have been detected previously. Failure to do this would result in not propagating not-linked, flushing, etc... Part-of: <gstreamer/gst-libav!94>
-
- Sep 28, 2020
-
-
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`. Part-of: <gstreamer/gst-libav!93>
-
- Sep 25, 2020
-
-
Part-of: <gstreamer/gst-libav!92>
-
- Sep 24, 2020
-
-
There are decoders that need to be drained if they work on multi-threads, even if AV_CODEC_CAP_DELAY is not set. Part-of: <gstreamer/gst-libav!91>
-
There are decoders that need to be drained if they work on multi-threads, even if AV_CODEC_CAP_DELAY is not set. Part-of: <gstreamer/gst-libav!91>
-
- Dec 03, 2019
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Nov 29, 2019
-
-
Instead of returning the default return value (GST_FLOW_OK), actually return an error one (res vs ret).
-
- Nov 17, 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>
-
- Oct 29, 2019
-
-
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
-
- Oct 24, 2019
-
-
... 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
-
- Sep 23, 2019
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Sep 10, 2019
-
-
Ross Burton authored
gtk-doc can't generate a type hierarchy when scanning gst-libav, and gtk-doc 1.30 onwards doesn't write a file if there is no type hierarchy (unlike previous releases, which wrote an empty file). This results in the build failing with gtk-doc 1.30 onwards, so remove the type hierarchy section from the documentation as it doesn't serve any purpose. Fixes gstreamer/gst-libav#57
-
- Aug 07, 2019
-
-
Regression from 1e4529ce
-
-
- Aug 06, 2019
-
-
The included libav requires it now. Otherwise the builds fails with: CCLD libgstlibav.la build-i686-w64-mingw32/gst-libs/ext/.libs/libavutil.a(random_seed.o): In function `av_get_random_seed': gst-libav-1.16.0/gst-libs/ext/libav/libavutil/random_seed.c:126: undefined reference to `BCryptOpenAlgorithmProvider@16' gst-libav-1.16.0/gst-libs/ext/libav/libavutil/random_seed.c:129: undefined reference to `BCryptGenRandom@16' gst-libav-1.16.0/gst-libs/ext/libav/libavutil/random_seed.c:130: undefined reference to `BCryptCloseAlgorithmProvider@8' collect2.exe: error: ld returned 1 exit status
-
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().
-
- May 02, 2019
-
-
Tim-Philipp Müller authored
-
- Apr 18, 2019
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Apr 12, 2019
-
-
Sebastian Dröge authored
-
- Apr 10, 2019
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Apr 09, 2019
-
-
Sebastian Dröge authored
See gstreamer/gst-libav#41 (comment 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.
-
- Apr 01, 2019
-
-
Aaron Boxer authored
(this is only used for CEA 708 raw data). another element such as mpegvideoparse may have already added the meta.
-
- Mar 22, 2019
-
-
Mathieu Duponchelle authored
-
- Mar 04, 2019
-
-
Tim-Philipp Müller authored
.. 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. #49
-
Tim-Philipp Müller authored
-
- Feb 26, 2019
-
-
Tim-Philipp Müller authored
-