- May 31, 2021
-
-
Tim-Philipp Müller authored
-
- Apr 30, 2021
-
-
Doug Nazar authored
Part-of: <gstreamer/gst-libav!133>
-
- Apr 24, 2021
- Apr 13, 2021
-
-
This has been unimplemented and non-functional for years and was deprecated with FFmpeg 4.4. Part-of: <gstreamer/gst-libav!126>
-
Tim-Philipp Müller authored
Direct access to avstream->index_entries was removed in favour of the newly added avformat_index_get_entry() and friends. Fixes gstreamer/gst-libav#85 Part-of: <gstreamer/gst-libav!127>
-
- Mar 16, 2021
-
-
Some plugins register an empty long_name field. Check for this before calling strcmp to avoid a crash. Part-of: <gstreamer/gst-libav!114>
-
- Mar 15, 2021
-
-
Jade Macho authored
Part-of: <gstreamer/gst-libav!124>
-
Sebastian Dröge authored
We only support up to 64 channels in GStreamer with a specific layout so it's safe to assume a NONE layout in this case. Also the arrays of channel positions are allocated everywhere with 64 elements so don't try setting more than 64 to NONE as that will cause stack corruptions and similar memory safety issues. Thanks to Natalie Silvanovich for reporting this issue. Fixes gstreamer/gst-libav#92 Part-of: <gstreamer/gst-libav!120>
-
- Feb 17, 2021
-
-
Otherwise, some h.264 streams (particularly with cropping information) may cause memory corruption after a renegotiation to a smaller size when decoded and then ffmpeg writes past the end of the buffer. Fixes: gstreamer/gst-libav#80 Part-of: <gstreamer/gst-libav!110>
-
Scenario is this: 1. libav receives enough data to want a buffer with get_buffer2() which wants a buffer pool with a certain format, say Y42B but does not negotiate and therefore GstVideoDecoder does not have any output state configured 2. A gap event is received which GstVideoDecoder wants to forward. It needs caps to forward the gap event so attempts to negotiate with some default information which chooses e.g. I420 and overwrites the previously configured bufferpool decided on by get_buffer2() 3. There is a mismatch between what ensure_internal_pool() check for consistency and what decide_allocation() sets when overriding the internal pool with the downstream pool. 4. FFMpeg then requests a Y42B buffer from an I420 pool and predictably crashes writing past the contents of the buffer This is fixed by keeping track of the internal pool states correctly. Part-of: <gstreamer/gst-libav!116>
-
- Feb 03, 2021
-
-
Vivia Nikolaidou authored
Not yet supported in FFmpeg, so we temporarily rely on the parser setting the correct buffer flags for us. Part-of: <!115>
-
- Dec 29, 2020
-
-
Seungha Yang authored
... and call finish_frame() so that baseclass can reset internal status. Otherwise baseclass will keep holding the status for decoding failed frame which will result in outputting buffer with wrong timestamp. Part-of: <gstreamer/gst-libav!112>
-
- Dec 14, 2020
-
-
Part-of: <gstreamer/gst-libav!111>
-
- Nov 04, 2020
-
-
Nirbheek Chauhan authored
This makes it easier to do development with MSVC by making it warn on common issues that GCC/Clang error out for in our CI configuration. Continuation from gstreamer/gst-build!223 Part-of: <gstreamer/gst-libav!109>
-
- Oct 27, 2020
-
-
Arun Raghavan authored
The check seems to be to present to verify that the decoded frame matches the format we expect. The actual check for the layout of the frame was being performed against the context instead. The check fails at least for avdec_aptx_hd, where the AVCodecContext has the sample format set to AV_SAMPLE_FMT_NONE. Part-of: <gstreamer/gst-libav!107>
-
- Oct 07, 2020
-
-
Seungha Yang authored
Add simple encoder drain test case Part-of: <gstreamer/gst-libav!100>
-
Looks like they weren't ported when we switched to meson Part-of: <gstreamer/gst-libav!100>
-
- Oct 06, 2020
-
-
Seungha Yang authored
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!99>
-
- Oct 01, 2020
-
-
Sebastian Dröge authored
This is already done in all other codec elements. Part-of: <gstreamer/gst-libav!97>
-
- Sep 30, 2020
-
-
Sebastian Dröge authored
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!97>
-
- Sep 15, 2020
-
-
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!90>
-
- Sep 14, 2020
-
-
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!90>
-
Sebastian Dröge authored
It might be useful for upstream to know that draining/finishing didn't succeed, and why. Part-of: <gstreamer/gst-libav!90>
-
Sebastian Dröge authored
It might be useful for upstream to know that draining/finishing didn't succeed, and why. Part-of: <gstreamer/gst-libav!90>
-
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!90>
-
- Sep 09, 2020
-
-
Olivier Crête authored
This now works with not so recent ffmpeg. Part-of: <gstreamer/gst-libav!88>
-
- Sep 08, 2020
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Sep 07, 2020
-
-
Tim-Philipp Müller authored
-
Sebastian Dröge authored
Part-of: <!89>
-
- Aug 20, 2020
-
-
Tim-Philipp Müller authored
-
- Aug 04, 2020
-
-
Jordan Petridіs authored
Part-of: <gstreamer/gst-libav!86>
-
- Jul 23, 2020
-
-
Jordan Petridіs authored
This reverts commit d1b20eb6. See gst-ci!324 Part-of: <!85>
-
Part-of: <!80>
-
- Jul 08, 2020
-
-
Tim-Philipp Müller authored
Part-of: <gstreamer/gst-libav!84>
-
- Jul 06, 2020
-
-
Vivia Nikolaidou authored
We examined the output buffer, instead of the input buffer, for existence of cc meta. Part-of: <!83>
-
- Jul 03, 2020
-
-
Following discussion in gst-plugins-bad!1396 (comment 556068) While it is technically possible to store multiple closed caption metas in the same buffer, we don't currently do that anywhere and for H264/MPEG2 both parts have to be stored in the same packet, and also the number of CC bytes you can store per frame is rather limited. This restriction might be relaxed later once we figured out how to do it without breaking things. Part-of: <!82>
-
Tim-Philipp Müller authored
-
- Jul 02, 2020
-
-
Tim-Philipp Müller authored
-
- Jun 30, 2020
-