| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Enable sending NAL units to the decoder without having to first
group them in a frame (an AU).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/66>
|
|
|
|
|
|
|
|
| |
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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/66>
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/135>
|
|
|
|
|
|
|
| |
Although avcodec_align_dimensions2() only copies 4 ints, it expects
a buffer of at least AV_NUM_DATA_POINTERS (8) ints.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/134>
|
| |
|
| |
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/133>
|
|
|
|
|
|
|
|
|
| |
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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/131>
|
|
|
|
|
|
|
| |
This has been unimplemented and non-functional for years
and was deprecated with FFmpeg 4.4.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/126>
|
|
|
|
|
|
|
|
|
|
| |
Direct access to avstream->index_entries was removed
in favour of the newly added avformat_index_get_entry()
and friends.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/85
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/127>
|
|
|
|
|
|
|
| |
Some plugins register an empty long_name field. Check for this
before calling strcmp to avoid a crash.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/114>
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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 https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/92
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/120>
|
|
|
|
|
|
|
|
|
| |
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: https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/80
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/116>
|
|
|
|
|
|
|
| |
Not yet supported in FFmpeg, so we temporarily rely on the parser
setting the correct buffer flags for us.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/112>
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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 https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/223
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/107>
|
|
|
|
|
|
| |
Add simple encoder drain test case
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/100>
|
|
|
|
|
|
| |
Looks like they weren't ported when we switched to meson
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/99>
|
|
|
|
|
|
|
|
| |
input again
This is already done in all other codec elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/97>
|
|
|
|
|
|
|
| |
AVERROR_EOF means that it's fully drained, but it doesn't
mean that that end of stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/90>
|
|
|
|
|
|
|
| |
It might be useful for upstream to know that draining/finishing didn't
succeed, and why.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/90>
|
|
|
|
|
|
|
| |
It might be useful for upstream to know that draining/finishing didn't
succeed, and why.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/90>
|
|
|
|
|
|
| |
This now works with not so recent ffmpeg.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/88>
|
| |
|
| |
|
| |
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/89>
|
| |
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/86>
|
|
|
|
|
|
|
|
| |
This reverts commit d1b20eb6558b5188fe539a2aba3dc15630e703b0.
See https://gitlab.freedesktop.org/gstreamer/gst-ci/-/merge_requests/324
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/85>
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/80>
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/84>
|
|
|
|
|
|
|
| |
We examined the output buffer, instead of the input buffer, for
existence of cc meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/83>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following discussion in
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1396#note_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: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/82>
|
| |
|
| |
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/81>
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/79>
|
| |
|
| |
|
|
|
|
| |
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-libav/-/merge_requests/76>
|
| |
|