Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Commit 601c238854 added support for AV_PKT_DATA_NEW_EXTRADATA, but
only for avcC extradata.
This commit adds support for sps/pps extradata as well. This makes
support consistent for passing new extradata consistent with the
types of extradata that can be passed when initializing the decoder.
Signed-off-by: Oliver Woodman <ollywoodman@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
then ff_h264_free_tables() and h264_decode_end() can be removed
in h264_decode_init() if it's failed.
The FF_CODEC_CAP_INIT_CLEANUP flag is need for single thread, For multithread,
it'll be cleanup still by AV_CODEC_CAP_FRAME_THREADS flag if have.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
It represents the relationship between them more naturally and will be
useful in the following commits.
Allows significantly more frames in fate-h264-attachment-631 to be
decoded.
Such errors are not necessarily fatal and decoding might still be
possible, e.g. it happens for MVC streams where we do not handle the
subset SPS thus failing to parse its corresponding PPS.
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to follow, so it is abandoned. Instead, the
same init function is used to init each per-thread context. Where
necessary, AVCodecInternal.is_copy can be used to differentiate between
the first thread and the other ones (e.g. for decoding the extradata
just once).
as well as includes of libavutil/timer.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
set AVFrame decode_error_flags in case h->slice_ctx->er.error_occurred is set
after the call to ff_h264_execute_decode_slices. This allows the user to detect
concealed decoding errors in the call to avcodec_receive_frame
Signed-off-by: Amir Pauker <amir@livelyvideo.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is in preparation for a patch for cbs_h2645. Now the packet's
rbsp_buffer can be owned by an AVBuffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
This error isn't particularly helpful as checking for mixed IDR/non-IDR
NALUs would need to be done at a higher level to actually be accurate.
Removing the error allows an API user to send individual slice NALUs
(i.e. incomplete frames) so they can take advantage of slice
threading. The ticket which this error was added for (#4408) no
longer segfaults after removing this error (as the bug was likely
fixed more properly elsewhere).
AVHWAccel.end_frame can run on a worker thread. The assumption of the
frame threading code is that the worker thread will change the AVFrame
image data, not the AVFrame fields. So the AVFrame fields are not synced
back to the main thread. But this breaks videotoolbox due to its special
requirements (everything else is fine). It actually wants to update
AVFrame fields.
The actual videotoolbox frame is now stored in the dummy AVBufferRef, so
it mimics what happens in non-videotoolbox cases. (Changing the
AVBufferRef contents is a bit like changing the image data.) The
post_process callback copies that reference to the proper AVFrame field.
Based on a patch by wm4.
Signed-off-by: Aman Gupta <aman@tmm1.net>
This provides a generic way to the API user to deal with files that
either lack this SEI, or which have the SEI only in packets not passed
to the decoder (such as the common case of the SEI being in the very
firsat video packet, but decoding is started somewhere in the middle of
the file). Bugs like 840b41b2a6 make this
somewhat of a necessity.
This intentionally uses the version in the SEI instead, if any is found.
This includes a pointer to the associated hwaccel for decoders using
hwaccels - these will be used later to implement the hwaccel setup
without needing a global list.
Also added is a new file listing all hwaccels as external declarations -
this will be used later to generate the hwaccel list at configure time.
This includes a pointer to the associated hwaccel for decoders using
hwaccels - these will be used later to implement the hwaccel setup
without needing a global list.
Also added is a new file listing all hwaccels as external declarations -
this will be used later to generate the hwaccel list at configure time.
This callback will be used by the VideoToolbox H264 hwaccel so that it
can receive SPS and PPS NALUs. VideoToolbox requires PPS changes to be
fed into the decoder session, and for the session to be recreated when
the SPS changes.
Signed-off-by: Aman Gupta <aman@tmm1.net>
The only reason videotoolbox wouldn't produce frames is if the data fed
to it was invalid, so returning AVERROR_INVALIDDATA makes sense here.
Further, it means AVERROR_EXTERNAL can be used in further commits to signal
fatal VideoToolbox errors, letting the user know that they need to fallback to
another decoder.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Do not use the one in the SEI directly as that is reset at certain
points.
Inspired by patches from Michael Niedermayer <michaelni@gmx.at> and
Anton Mitrofanov <BugMaster@narod.ru>.
CC: libav-stable@libav.org
This merges commit 4fded0480f from libav,
originally written by Anton Khirnov and skipped in
fc63d5ceb3.
libavcodec/h264_slice.c | 20 +++++++++++++-------
libavcodec/h264dec.c | 3 +++
libavcodec/h264dec.h | 5 +++++
3 files changed, 21 insertions(+), 7 deletions(-)
The way videotoolbox hooks in as a hwaccel is pretty hacky. The VT decode
API is not invoked until end_frame(), so alloc_frame() returns a dummy
frame with a 1-byte buffer. When end_frame() is eventually called, the
dummy buffer is replaced with the actual decoded data from
VTDecompressionSessionDecodeFrame().
When the VT decoder fails, the frame returned to the h264 decoder from
alloc_frame() remains invalid and should not be used. Before
9747219958, it was accidentally being
returned all the way up to the API user. After that commit, the dummy
frame was unref'd so the user received an error.
However, since that commit, VT hwaccel failures started causing random
segfaults in the h264 decoder. This happened more often on iOS where the
VT implementation is more likely to throw errors on bitstream anomolies.
A recent report of this issue can be see in
http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html
The issue here is that the dummy frame is still referenced internally by the
h264 decoder, as part of the reflist and cur_pic_ptr. Deallocating the
frame causes assertions like this one to trip later on during decoding:
Assertion h->cur_pic_ptr->f->buf[0] failed at src/libavcodec/h264_slice.c:1340
With this commit, we leave the dummy 1-byte frame intact, but avoid returning it
to the user.
This reverts commit 9747219958.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This treats the case of no slices like no frames which it basically is.
The field is added to the context as other nal related fields are also there
and passing the has_slices field per *arguments is ugly and not consistent
Found-by: ubitux
Approved-by: ubitux
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Andreas Rheinhardt
Andreas Rheinhardt
James Almer
Oliver Woodman
Limin Wang
Michael Niedermayer
Anton Khirnov
Mark Thompson
Nicolas Gaullier
Amir Pauker
Andreas Rheinhardt
Josh de Kock
Zhao Zhili
Kieran Kunhya
Rodger Combs
wm4
Aman Gupta
Rafaël Carré
Ronald S. Bultje
Matthieu Bouron
John Stebbins
Diego Biurrun