GitLab

Part-of: <!142>

Add xwma tested with the media

b8edfb1e970ed7892f35b34a1ef36fee_wma.wav

from this ticket:

http://trac.ffmpeg.org/ticket/9358

Part-of: <!138>

Olivier Crête authored Jan 22, 2020 and Stéphane Cerveau committed Jul 08, 2021

Enable sending NAL units to the decoder without having to first
group them in a frame (an AU).

Part-of: <!66>

Olivier Crête authored Jan 22, 2020 and Stéphane Cerveau committed Jul 07, 2021

When doing subframe decoding, handle_frame will be called multiple
times, so the DECODE_ONLY flag gets re-set when it shouldn't. Instead,
let's create our own flag to track this.

Part-of: <!66>

Part-of: <!135>

Although avcodec_align_dimensions2() only copies 4 ints, it expects
a buffer of at least AV_NUM_DATA_POINTERS (8) ints.

Part-of: <!134>

Part-of: <!133>

Edward Hervey authored Apr 24, 2021 and Edward Hervey committed Apr 24, 2021

Failure to do this would cause the decoders to constantly request a new
bufferpool thinking the height had changed ... whereas it hadn't.

Fixes #95

Part-of: <!131>

Tim-Philipp Müller authored Apr 13, 2021 and GStreamer Marge Bot committed Apr 13, 2021

This has been unimplemented and non-functional for years
and was deprecated with FFmpeg 4.4.

Part-of: <!126>

Direct access to avstream->index_entries was removed
in favour of the newly added avformat_index_get_entry()
and friends.

Fixes #85

Part-of: <!127>

Nicholas Jackson authored Jan 19, 2021 and Nicholas Jackson committed Mar 16, 2021

Some plugins register an empty long_name field.  Check for this
before calling strcmp to avoid a crash.

Part-of: <!114>

Part-of: <!124>

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

Part-of: <!120>

Matthew Waters authored Dec 02, 2020 and GStreamer Marge Bot committed 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: #80
Part-of: <!110>

Matthew Waters authored Jan 28, 2021 and GStreamer Marge Bot committed Feb 17, 2021

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: <!116>

Not yet supported in FFmpeg, so we temporarily rely on the parser
setting the correct buffer flags for us.

Part-of: <!115>

... 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: <!112>

Jan Schmidt authored Dec 14, 2020 and Sebastian Dröge committed Dec 14, 2020

Part-of: <!111>

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 gst-build!223

Part-of: <!109>

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: <!107>

Add simple encoder drain test case

Part-of: <!100>

Edward Hervey authored Oct 01, 2020 and Seungha Yang committed Oct 07, 2020

Looks like they weren't ported when we switched to meson

Part-of: <!100>

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: <!99>

This is already done in all other codec elements.

Part-of: <!97>

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: <!97>

AVERROR_EOF means that it's fully drained, but it doesn't
mean that that end of stream.

Part-of: <!90>

audiodecoder baseclass implementation is expecting that
finish_subframe() is followed by finish_frame() in order clear
its internal state related to subframe.

Part-of: <!90>

It might be useful for upstream to know that draining/finishing didn't
succeed, and why.

Part-of: <!90>

It might be useful for upstream to know that draining/finishing didn't
succeed, and why.

Part-of: <!90>

Edward Hervey authored Sep 09, 2020 and Sebastian Dröge committed Sep 14, 2020

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: <!90>

This now works with not so recent ffmpeg.

Part-of: <!88>

Part-of: <!89>

Part-of: <!86>