There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids allocations and error checks for these allocations;
e.g. syncing buffers across threads can't fail any more
and needn't be checked. It also gets rid of casts and
indirections.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit is the AVHWAccel analogue of commit
20f972701806be20a77f808db332d9489343bb78: It moves the private fields
of AVHWAccel to a new struct FFHWAccel extending AVHWAccel
in an internal header (namely hwaccel_internal.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In the code path of av_videotoolbox_default_init/init2(),
avctx->internal->hwaccel_priv_data is NULL and passed to
decoder_cb.decompressionOutputRefCon. Then it will be dereferenced
inside videotoolbox_decoder_callback().
Delay videotoolbox_star() until ff_videotoolbox_common_init() to
fix the bug.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The opaque parameter for the callback is set in videotoolbox_start(),
called when the hwaccel is initialized. When frame threading is used,
avctx will be the context corresponding to the frame thread currently
doing the decoding. Using this same codec context in all subsequent
invocations of the decoder callback (even those triggered by a different
frame thread) is unsafe, and broken after
cc867f2c09, since each frame thread now
cleans up its hwaccel state after decoding each frame.
Fix this by passing hwaccel_priv_data as the opaque parameter, which
exists in a single instance forwarded between all frame threads.
The only other use of AVCodecContext in the decoder output callback is
as a logging context. For this purpose, store a logging context in
hwaccel_priv_data.
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes build failures for videotoolbox
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Please reproduced with the following minimal configure command:
./configure --enable-shared --disable-all --enable-avcodec --enable-decoder=h264 --enable-hwaccel=h264_videotoolbox
You'll get below error:
Undefined symbols for architecture x86_64:
"_ff_videotoolbox_vpcc_extradata_create", referenced from:
_videotoolbox_start in videotoolbox.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Reported-by: Cameron Gutman <aicommander@gmail.com>
Tested-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
VideoToolbox internally sets all the colorspace parameters to BT709,
regardless of what the bitstream actually indicates, so we need to
replace that with what we've parsed.
Old system is:
OSX version: 10.11.6
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This was partially fixed by 233cd89, but it made changes to AVFrame fields
from within end_frame, which doesn't work consistently when multithreading
is enabled. This is what the post_process function is for.
Signed-off-by: Aman Gupta <aman@tmm1.net>
vtctx->cached_hw_frames_ctx is unref'd in videotoolbox_uninit,
but videotoolbox_hevc used ff_videotoolbox_uninit which
doesn't unref cache_hw_frames_ctx.
Signed-off-by: Pavel Koshevoy <pkoshevoy@gmail.com>
Instead of assuming id 0 is used, use the same logic as used for PPS,
where all available entries in the list are emitted.
Signed-off-by: Aman Gupta <aman@tmm1.net>
videotoolbox returns an already cropped stream which led to double
cropping. this issue was introduced with the refactor of the cropping
mechanism in commit 07596e4 for h264 and 000fb61 for HEVC.
to fix this we set the cropping of the frame and the output frame to 0.
Tested-by: ponpon
Fixes ticket #7544.
In a normal hwaccel, the AVHWFramesContext sets AVFrame.hw_frames_ctx
when it initializes a new AVFrame in av_hwframe_get_buffer().
But the VT hwaccel doesn't know what hw_frames_ctx to assign when
the AVFrame is first created, because it depends on the format of
the pixbuf that the decoder eventually decides to return. Thus
newly created AVFrames always have a NULL hw_frames_ctx, and the
hwaccel would only assign the ctx once a frame was done decoding.
This worked fine with the H264 decoder, but with the HEVC decoder
the frame's data may be moved to another empty AVFrame. Since the
empty AVFrame never had hw_frames_ctx set, a frame with a NULL
ctx could be returned to the API user.
This patch works around the issue by moving the derived
hw_frames_ctx from the AVFrame to a new VTHWFrame which now holds
both the CVPixelBufferRef and the AVBuffer. The hw_frames_ctx
is only copied to the AVFrame right before it is about to be
returned to the user in videotoolbox_postproc_frame() (since
in the case of VT, the hw_frames_ctx is only there for the API
user anyway).
Fixes playback on macOS and iOS of some hevc videos like
https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
Older iOS devices don't have a hardware HEVC decoder, but the
software decoder offered by VideoToolbox is well-optimized and
performs much better than the ffmpeg decoder.
Signed-off-by: Aman Gupta <aman@tmm1.net>
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>
Previously the codec kept an entire copy of the SPS, and restarted the VT decoder
session whenever it changed. This fixed decoding errors in [1], as
described in 9519983c. On further inspection, that sample features an SPS change
from High/4.0 to High/3.2 while moving from one scene to another.
Yesterday I received [2], which contains minor SPS changes where the
profile and level do not change. These occur frequently and are not associated with
scene changes. After 9519983c, the VT decoder session is recreated unnecessarily when
these are encountered causing visual glitches.
This commit simplifies the state kept in the VTContext to include just the first three
bytes of the SPS, containing the profile and level details. This is populated initially
when the VT decoder session is created, and used to detect changes and force a restart.
This means minor SPS changes are fed directly into the existing decoder, whereas
profile/level changes force the decoder session to be recreated with the new parameters.
After this commit, both samples [1] and [2] playback as expected.
[1] https://s3.amazonaws.com/tmm1/videotoolbox/spschange.ts
[2] https://s3.amazonaws.com/tmm1/videotoolbox/spschange2.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
Andreas Rheinhardt
James Almer
Zhao Zhili
Jun Zhao
Anton Khirnov
rcombs
Martin Storsjö
Limin Wang
Jan Ekström
Steven Liu
Rodger Combs
Akemi
Pavel Koshevoy
fumoboy007
Aman Gupta
Mark Thompson